From jerome.benoit@grenouille.com Fri Apr 5 05:23: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 1C03121F976A for ; Fri, 5 Apr 2013 05:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[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 ZWR1kmC+8BIn for ; Fri, 5 Apr 2013 05:23:02 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5553621F9769 for ; Fri, 5 Apr 2013 05:23:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 4B6147F2B5 for ; Fri, 5 Apr 2013 14:22:59 +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 FapSKXXM9CbZ for ; Fri, 5 Apr 2013 14:22:48 +0200 (CEST) Date: Fri, 5 Apr 2013 14:22:45 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130405142245.47a5d4d2@nemesis.grenouille.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/6prEvbn+yqO1gJsRDKAwhag"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 05 Apr 2013 12:23:03 -0000 --Sig_/6prEvbn+yqO1gJsRDKAwhag Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, 28 Mar 2013 08:17:46 +0000 in <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com>, Romascanu, Dan (Dan) "Romascanu, Dan (Dan)" wrote: > Hi, Hello,=20 > Please note the following incoming liaison statement from IEEE Project P8= 02.16.3 concerning the LMAP activity.=20 >=20 > https://datatracker.ietf.org/liaison/1244/ >=20 > Comments and discussions are welcome.=20 There's no point in a private server to help anonymity. A cryptographic system is enough that can for example one time key pair with a timestamp as a pass-phrase- fire and forget crypto -. The main advantage of such a system is that you do not need to cypher the transmission, the cyphering is done at the payload level, the keys are deleted once the measurement session is done. The key exchange rate could be high (a downside). The server keep the private key of a session to de-cypher. I can dig the design if the LMAP WG is in a hurry but I will do it anyway later. I call this kind of cryptographic system "time based crypto".=20 I really would like the LMAP WG to not throw away the ISP's cheats on a measurement campaign, it 's not an coding issue, it's a design issue of the measurement by itself : if a measurement design can't cheat a DPI, it's just not a good measurement design.=20 Cheers.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/6prEvbn+yqO1gJsRDKAwhag Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFewhUACgkQ+qDLUJ/pFh28XACeLNErobwfA3/4mOxPjo8c0Zrd rMwAoN4nHwxkjJPZV17JooRQBVAqWSn1 =m9UO -----END PGP SIGNATURE----- --Sig_/6prEvbn+yqO1gJsRDKAwhag-- From bs7652@att.com Fri Apr 5 09:02: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 34C8821F982D for ; Fri, 5 Apr 2013 09:02: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 R9Ek7pg1QdLq for ; Fri, 5 Apr 2013 09:02:46 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3D60821F9828 for ; Fri, 5 Apr 2013 09:02:46 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5a5fe515.0.153389.00-494.427962.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 05 Apr 2013 16:02:46 +0000 (UTC) X-MXL-Hash: 515ef5a64c6fc49e-95ce540ef940785343a2720c172e06fdc06a898f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r35G2jXq014277 for ; Fri, 5 Apr 2013 12:02:45 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r35G2Z09014062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Apr 2013 12:02:38 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor) for ; Fri, 5 Apr 2013 17:02:20 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Fri, 5 Apr 2013 12:02:20 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac4rjLnfWpFw/p7tS3i28o1yTrXHQwGjRQCAAAOlBuA= Date: Fri, 5 Apr 2013 16:02:18 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> In-Reply-To: <20130405142245.47a5d4d2@nemesis.grenouille.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.219.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=EL6xJSlC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=E6DqsIzJlZcA:10 a=yAzTK4uSK9IA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=XnCUKPQ8S1gA:10 a=48vgC7mUAAAA:8 a=1XWaLZrsAAAA:8] X-AnalysisOut: [ a=o6fxaMBDBKUHL5ow9ZwA:9 a=CjuIK1q_8ugA:10] Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 05 Apr 2013 16:02:47 -0000 > > Please note the following incoming liaison statement from IEEE Project > P802.16.3 concerning the LMAP activity. > > > > https://datatracker.ietf.org/liaison/1244/ > > > > Comments and discussions are welcome. 1. Private vs. Public definition I'm really unclear on how the liaison authors are defining "Public" and "Pr= ivate". I can think of 4 different ways in which these terms might be defin= ed, and would be curious as to which was actually meant (or whether it's a = 5th definition I hadn't considered). A. Public: owned by the government; Private: owned by a private entity [thi= s is the definition I'm used to, but it doesn't really seem to be the one t= hat is being used, since currently all of the test servers and data collect= ion systems are privately owned, including those used by SamKnows and servi= ce providers] B. Public: Internet facing and no authentication required; Private: not Int= ernet-facing or requiring authentication [doesn't seem to be what's implied= regarding Measurement Servers, but does seem to be implied by the Data Col= lector usage, which really confuses me] C. Public: dedicated for regulatory data measurement/collection; Private: e= verything else [note that employees of regulators who have participated in = this debate have indicated that in order to make the test systems more cost= effective, they don't think it's necessary to dedicate systems -- rather t= he systems used should be able to meet the needs of multiple use cases; the= refore, IMO, this isn't a useful definition] D. Public: used (but not necessarily dedicated) for regulatory data measure= ment/collection; Private: everything else [for example, if a regulator some= where in the world decided they wanted a ping test run against www.google.c= om, that would then be labeled a "public" measurement server; SamKnows serv= ers would be "public"; servers used by ISPs for this purpose (and other pur= poses) would be public; this seems to be closest to what's implied] I'm thinking the words "Public" and "Private" perhaps shouldn't be used, be= cause maybe there isn't a good definition that really conveys what's meant. 2. "Public Data Collectors" First, I think we need to distinguish between the Data Collector (which get= s raw data from the Measurement Agent) and any database/system/server that = is used to make collected data available to people or other systems. The li= aison seems to suggest that these are one and the same. That strikes me as = a very unusual way to architect operation support systems. It certainly isn= 't how I would architect things. Personally, I consider the interfaces that= a ("private") company (ISP or "company that a regulator contracts with to = do measurements") has between their Data Collector and their systems that p= rovide people/systems access to data to be outside the scope of any IETF WG= . Data providing and data storage are very distinct from data collection. W= hat does or does not constitute "private" data and how secure access to the= data-that-is-made-available needs to be is probably best determined at a n= ational level. Who gets access to the data is probably also best determined= at a national level. For an ISP to create a system that allows an end user= to log in and get data collected about their access line (collected for th= e ISP use case, the regulator use case, or explicitly for the end user case= ) is very do-able and doesn't need IETF help. But whether or not to do that= is up to the ISP (unless the regulator/government mandates something). A c= ontracted company could also create a mechanism that gives test participant= s access to their data. For an ISP or contracted company to remove private = elements from data that gets provided to others is easily accomplished. Wha= t data elements to provide, whether to do such data scrubbing, and what dat= a gets scrubbed, is a matter to be discussed at a national level. Therefore= , I see absolutely no reason to discuss "Public" vs. "Private" Data Collect= ors. By Definition A -- unless the government owns the Data Collectors, the= y are all "Private", and what data ultimately gets supplied to others is de= termined by the owner of the data and, for the regulatory use case, the reg= ulator. By Definition B -- there shouldn't be a Data Collector that allows = for its raw, collected data to be accessed without authentication over the = Internet. By Definition C -- it's certainly possible to have certain measur= ement data sent to a regulatory-dedicated Data Collector (and potentially a= lso sent to a non-regulatory-dedicated Data Collector if the data is to be = used for other use cases, as well), but this isn't how I would design thing= s; I would split the data out after it gets to the Data Collector, and not = complicate the MA by making it know which data gets used for what use case.= Definition D doesn't seem to apply, given how the Data Collector is discus= sed in the liaison. Barbara From david.sinicrope@ericsson.com Thu Mar 28 11:57: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 19AE621F8FD5; Thu, 28 Mar 2013 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Ae+cBGe4pUHb; Thu, 28 Mar 2013 11:57:42 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 79AF221F8F05; Thu, 28 Mar 2013 11:57:42 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-3b-515492a5328d Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CC.C9.02411.5A294515; Thu, 28 Mar 2013 19:57:42 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 14:57:41 -0400 From: David Sinicrope To: "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: Marked for action ? - RE: incoming liaison statement from Broadband Forum Thread-Index: Ac4r5VPor3vVk41YSeqEXZtZkmdyvg== Date: Thu, 28 Mar 2013 18:57:40 +0000 Message-ID: <871EB8879748FA458598F0461906289317C52C@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyuXRPiO6ySSGBBv++s1r0PHjHbNF8Xtvi +8UOZgdmjyVLfjJ5fLn8mS2AKYrLJiU1J7MstUjfLoErY+WC42wFc5kr7i1fxtjAeJmpi5GD Q0LARKLzVFoXIyeQKSZx4d56ti5GLg4hgSOMElN/fWSEcJYzSqzZ/pwdpIoNqGHdxj0sILaI gIvEhs37GEFsZgFTie0ndoDVCAvESCyf854NoiZWYsOMbVC2nsTWS1vBalgEVCUWdc0H6+UV 8JZ48P8IK4jNCHTF91NrmCBmikvcejKfCeI6AYkle84zQ9iiEi8f/2OFsJUlljzZzwJRryOx YPcnNghbW2LZwtfMEPMFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiB wX9Mgs1xB+OCT5aHGKU5WJTEeUNdLwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGy+uX97 gOCyT/ss4xrcfI9YVTpl2Ry6bbYl8tB+nfmd7w6EH7aaNvHYye8Z8XPXK1QdODHp0MWiB5V7 J3I9P8mp/zUybeuLiPdi/44U9LzacETMW1jMMnGm7IkZevV7rnTd2H7RpNrAcDJziUdGzI3e sFs/ovqTtC98NSnxjD6ddPcYr1HvKwYlluKMREMt5qLiRACuxYZ+TAIAAA== X-Mailman-Approved-At: Fri, 05 Apr 2013 13:37:31 -0700 Cc: "ops-ads@tools.ietf.org" Subject: [lmap] FW: Marked for action ? - RE: incoming liaison statement from 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: Thu, 28 Mar 2013 18:57:43 -0000 Please note the following incoming liaison statement from the Broadband For= um concerning the LMAP activity. https://datatracker.ietf.org/liaison/1243= /=20 This is the latest of a few liaisons from the Broadband Forum on this activ= ity. If possible a response should be sent by 5/24 to ensure it reaches th= e Broadband Forum by their 2Q2013 meeting. Regards, Dave Sinicrope BBF Liaison to the IETF From jerome.benoit@grenouille.com Sat Apr 6 21:30:52 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 E4C4921F858B for ; Sat, 6 Apr 2013 21:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[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 6LK7o1RE-ydq for ; Sat, 6 Apr 2013 21:30:52 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id B478121F8585 for ; Sat, 6 Apr 2013 21:30:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 8B54E7F80C for ; Sun, 7 Apr 2013 06:30:48 +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 96kp1KvvXtrK for ; Sun, 7 Apr 2013 06:30:38 +0200 (CEST) Date: Sun, 7 Apr 2013 06:30:37 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130407063037.09cd9996@nemesis.grenouille.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/fKLcxt92JH428Uklx.HCAXI"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 07 Apr 2013 04:30:53 -0000 --Sig_/fKLcxt92JH428Uklx.HCAXI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, 5 Apr 2013 16:02:18 +0000 in <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.co= m>, STARK, BARBARA H "STARK, BARBARA H" wrote: > 1. Private vs. Public definition > I'm really unclear on how the liaison authors are defining "Public" and "= Private". I can think of 4 different ways in which these terms might be def= ined, and would be curious as to which was actually meant (or whether it's = a 5th definition I hadn't considered). > A. Public: owned by the government; Private: owned by a private entity [t= his is the definition I'm used to, but it doesn't really seem to be the one= that is being used, since currently all of the test servers and data colle= ction systems are privately owned, including those used by SamKnows and ser= vice providers] > B. Public: Internet facing and no authentication required; Private: not I= nternet-facing or requiring authentication [doesn't seem to be what's impli= ed regarding Measurement Servers, but does seem to be implied by the Data C= ollector usage, which really confuses me] > C. Public: dedicated for regulatory data measurement/collection; Private:= everything else [note that employees of regulators who have participated i= n this debate have indicated that in order to make the test systems more co= st effective, they don't think it's necessary to dedicate systems -- rather= the systems used should be able to meet the needs of multiple use cases; t= herefore, IMO, this isn't a useful definition] > D. Public: used (but not necessarily dedicated) for regulatory data measu= rement/collection; Private: everything else [for example, if a regulator so= mewhere in the world decided they wanted a ping test run against www.google= .com, that would then be labeled a "public" measurement server; SamKnows se= rvers would be "public"; servers used by ISPs for this purpose (and other p= urposes) would be public; this seems to be closest to what's implied] ok, just let's me make all of this crystal clear in term of definition :=20 The measurement results content's level of privacy is what the *user* choose to define as private or public. It's just as simple as that. Default level is complete and total anonymity. The implementation of "complete and total anonymity" is what is what we *NEED* to talk about. Everything else is ... bullshit. =20 >=20 > I'm thinking the words "Public" and "Private" perhaps shouldn't be used, = because maybe there isn't a good definition that really conveys what's mean= t. I'm in total agreement. >=20 > 2. "Public Data Collectors" > First, I think we need to distinguish between the Data Collector (which g= ets raw data from the Measurement Agent) and any database/system/server tha= t is used to make collected data available to people or other systems. The = liaison seems to suggest that these are one and the same. That strikes me a= s a very unusual way to architect operation support systems. It certainly i= sn't how I would architect things. Personally, I consider the interfaces th= at a ("private") company (ISP or "company that a regulator contracts with t= o do measurements") has between their Data Collector and their systems that= provide people/systems access to data to be outside the scope of any IETF = WG. Data providing and data storage are very distinct from data collection.= What does or does not constitute "private" data and how secure access to t= he data-that-is-made-available needs to be is probably best determined at a= national level. Who gets access to the data is probably also best determin= ed at a national=20 > level. For an ISP to create a system that allows an end user to log in a= nd get data collected about their access line (collected for the ISP use ca= se, the regulator use case, or explicitly for the end user case) is very do= -able and doesn't need IETF help. But whether or not to do that is up to th= e ISP (unless the regulator/government mandates something). A contracted co= mpany could also create a mechanism that gives test participants access to = their data. For an ISP or contracted company to remove private elements fro= m data that gets provided to others is easily accomplished. What data eleme= nts to provide, whether to do such data scrubbing, and what data gets scrub= bed, is a matter to be discussed at a national level. Therefore, I see abso= lutely no reason to discuss "Public" vs. "Private" Data Collectors. By Defi= nition A -- unless the government owns the Data Collectors, they are all "P= rivate", and what data ultimately gets supplied to others is determined by = the owner of the=20 > data and, for the regulatory use case, the regulator. By Definition B --= there shouldn't be a Data Collector that allows for its raw, collected dat= a to be accessed without authentication over the Internet. By Definition C = -- it's certainly possible to have certain measurement data sent to a regul= atory-dedicated Data Collector (and potentially also sent to a non-regulato= ry-dedicated Data Collector if the data is to be used for other use cases, = as well), but this isn't how I would design things; I would split the data = out after it gets to the Data Collector, and not complicate the MA by makin= g it know which data gets used for what use case. Definition D doesn't seem= to apply, given how the Data Collector is discussed in the liaison. >=20 > Barbara Well ... you're just missing the point : how do you ensure the anonymity of the measurement results ? the question is *HOW*. Period.=20 The split of the data collector level of privacy is not the right answer. It's just a bandaid on a bad design. The right question is :=20 How do you guarantee a level of privacy AND anonymity of the measurement results in your non-very-centralized design ?=20 One time private or session key is just one of the answer -with overheads-.=20 The job now is to find a really good way to ensure both. I can really help the LMAP WG but please, do use this mailing list of a primary=20 tool to build the design from scratch or zero. Do not thrown dump idea out of the box here of future IETF or IEEE standard without a primary discussion here.=20 The end result will be just like it looks right : please guys or girls, go back to your white board and think deeper.=20 Regards,=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/fKLcxt92JH428Uklx.HCAXI Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFg9m0ACgkQ+qDLUJ/pFh3btgCdHc7L7xAUFCLnccryMLQsnHZG X50Anip6888pCajPwe6RomErWN8r/xyO =ErKW -----END PGP SIGNATURE----- --Sig_/fKLcxt92JH428Uklx.HCAXI-- From dromasca@avaya.com Sun Apr 7 02: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 65DDC21F8D33; Sun, 7 Apr 2013 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.502 X-Spam-Level: X-Spam-Status: No, score=-103.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 1OeP6W8dcnkk; Sun, 7 Apr 2013 02:44:47 -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 B91EE21F8D2A; Sun, 7 Apr 2013 02:44:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHpXMFHGmAcF/2dsb2JhbABEgma/Tn8Wc4IfAQEBAQMBAQEPKDQLDAQCAQgNBAQBAQsUCQcnCxQIAQgBAQQBDQUIGodxAQukVpw/BI1TgRAmCwcGgllhA5xailGBUoE2gXI1 X-IronPort-AV: E=Sophos;i="4.84,760,1355115600"; d="scan'208";a="5923559" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Apr 2013 05:44:46 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Apr 2013 05:42:09 -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.02.0328.009; Sun, 7 Apr 2013 05:44:45 -0400 From: "Romascanu, Dan (Dan)" To: David Sinicrope , "lmap@ietf.org" , "ippm@ietf.org" Thread-Topic: [lmap] FW: Marked for action ? - RE: incoming liaison statement from Broadband Forum Thread-Index: Ac4r5VPor3vVk41YSeqEXZtZkmdyvgHjpEPg Date: Sun, 7 Apr 2013 09:44:44 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0C2F7C@AZ-FFEXMB04.global.avaya.com> References: <871EB8879748FA458598F0461906289317C52C@eusaamb103.ericsson.se> In-Reply-To: <871EB8879748FA458598F0461906289317C52C@eusaamb103.ericsson.se> 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 Cc: "ops-ads@tools.ietf.org" Subject: Re: [lmap] FW: Marked for action ? - RE: incoming liaison statement from 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: Sun, 07 Apr 2013 09:44:48 -0000 Hi David, Thank you for forwarding this.=20 Please note that LMAP is not yet constitute as a working group. We are work= ing towards submitting a charter to the IESG for approval in view of format= ting a WG, but this process will not be completed before 5/24. We are welco= ming mail list contributions that can help in the process of defining the s= cope of the future WG and discussions around these contributions on the mai= l list, but we are not in the situation to answer such contributions by sen= ding back liaison statements.=20 Regards, Dan > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > David Sinicrope > Sent: Thursday, March 28, 2013 8:58 PM > To: lmap@ietf.org; ippm@ietf.org > Cc: ops-ads@tools.ietf.org > Subject: [lmap] FW: Marked for action ? - RE: incoming liaison statement > from Broadband Forum >=20 > Please note the following incoming liaison statement from the Broadband > Forum concerning the LMAP activity. > https://datatracker.ietf.org/liaison/1243/ > This is the latest of a few liaisons from the Broadband Forum on this > activity. If possible a response should be sent by 5/24 to ensure it > reaches the Broadband Forum by their 2Q2013 meeting. > Regards, > Dave Sinicrope > BBF Liaison to the IETF > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From trevor.burbridge@bt.com Mon Apr 8 02:10:41 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 DE3DC21F9349 for ; Mon, 8 Apr 2013 02:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9aZ8ZdsVf0sK for ; Mon, 8 Apr 2013 02:10:40 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4231E21F9346 for ; Mon, 8 Apr 2013 02:10:40 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 8 Apr 2013 10:10:39 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.187]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 8 Apr 2013 10:10:38 +0100 From: To: , Date: Mon, 8 Apr 2013 10:10:37 +0100 Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac4zSLLVDciK7PwuTk6ewdlG0rmd5QA7jFiw Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> In-Reply-To: <20130407063037.09cd9996@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 09:10:42 -0000 I think our visions of the LMAP framework may be rather different. For myself (and I think Barbara) things are fairly simple. _All_ data colle= ction is private. Someone installs Measurement Agents and collects the resu= lts. This communication will be secured. Outside the technical system there= will be an agreement of what data is collected and what can be done with i= t. We certainly don't want to be in the business of a user creating electro= nic use policies for the data. The Measurement Agent will have an identifier that can be linked with a liv= ing subject by the Controller (although the Measurement Agent is unlikely t= o know either the details of this person itself). This has to be the case s= ince the Controller installed/configured this measurement agent in the firs= t place. The framework would allow the Collector to be a party who does not= have this information - practically though the data can be collected by th= e same organisation as the Controller of the Measurement Agents, processed = to whatever standards of blurring/blending/anonymity is required before pas= sing to other parties. Nowhere in our use cases do we seem to have a requirement to have Measureme= nt Agents reporting directly to a publically accessible datastore. Trevor. >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >J=E9r=F4me Benoit >Sent: 07 April 2013 05:31 >To: lmap@ietf.org >Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 > >On Fri, 5 Apr 2013 16:02:18 +0000 in ><2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L >.ITServices.sbc.com>, >STARK, BARBARA H "STARK, BARBARA H" wrote: > >> 1. Private vs. Public definition >> I'm really unclear on how the liaison authors are defining "Public" and >"Private". I can think of 4 different ways in which these terms might be >defined, and would be curious as to which was actually meant (or whether >it's a 5th definition I hadn't considered). >> A. Public: owned by the government; Private: owned by a private entity >> [this is the definition I'm used to, but it doesn't really seem to be >> the one that is being used, since currently all of the test servers >> and data collection systems are privately owned, including those used >> by SamKnows and service providers] B. Public: Internet facing and no >> authentication required; Private: not Internet-facing or requiring >> authentication [doesn't seem to be what's implied regarding >> Measurement Servers, but does seem to be implied by the Data Collector >> usage, which really confuses me] C. Public: dedicated for regulatory >> data measurement/collection; Private: everything else [note that >> employees of regulators who have participated in this debate have >> indicated that in order to make the test systems more cost effective, >> they don't think it's necessary to dedicate systems -- rather the >> systems used should be able to meet the needs of multiple use cases; >> therefore, IMO, this isn't a useful definition] D. Public: used (but >> not necessarily dedicated) for regulatory data measurement/collection; >> Private: everything else [for example, if a regulator somewhere in the >> world decided they wanted a ping test run against www.google.com, that >> would then be labeled a "public" measurement server; SamKnows servers >> would be "public"; servers used by ISPs for this purpose (and other >> purposes) would be public; this seems to be closest to what's implied] > >ok, just let's me make all of this crystal clear in term of definition : > >The measurement results content's level of privacy is what the *user* >choose to define as private or public. It's just as simple as that. >Default level is complete and total anonymity. The implementation of >"complete and total anonymity" is what is what we *NEED* to talk about. >Everything else is ... bullshit. > >> >> I'm thinking the words "Public" and "Private" perhaps shouldn't be used, >because maybe there isn't a good definition that really conveys what's >meant. > >I'm in total agreement. > >> >> 2. "Public Data Collectors" >> First, I think we need to distinguish between the Data Collector >> (which gets raw data from the Measurement Agent) and any >> database/system/server that is used to make collected data available to >people or other systems. The liaison seems to suggest that these are one a= nd >the same. That strikes me as a very unusual way to architect operation >support systems. It certainly isn't how I would architect things. Personal= ly, I >consider the interfaces that a ("private") company (ISP or "company that a >regulator contracts with to do measurements") has between their Data >Collector and their systems that provide people/systems access to data to >be outside the scope of any IETF WG. Data providing and data storage are >very distinct from data collection. What does or does not constitute >"private" data and how secure access to the data-that-is-made-available >needs to be is probably best determined at a national level. Who gets acce= ss >to the data is probably also best determined at a national level. For an = ISP to >create a system that allows an end user to log in and get data collected >about their access line (collected for the ISP use case, the regulator use= case, >or explicitly for the end user case) is very do-able and doesn't need IETF= help. >But whether or not to do that is up to the ISP (unless the >regulator/government mandates something). A contracted company could >also create a mechanism that gives test participants access to their data.= For >an ISP or contracted company to remove private elements from data that >gets provided to others is easily accomplished. What data elements to >provide, whether to do such data scrubbing, and what data gets scrubbed, i= s >a matter to be discussed at a national level. Therefore, I see absolutely = no >reason to discuss "Public" vs. "Private" Data Collectors. By Definition A = -- >unless the government owns the Data Collectors, they are all "Private", an= d >what data ultimately gets supplied to others is determined by the owner of >the data and, for the regulatory use case, the regulator. By Definition B= -- >there shouldn't be a Data Collector that allows for its raw, collected dat= a to >be accessed without authentication over the Internet. By Definition C -- i= t's >certainly possible to have certain measurement data sent to a regulatory- >dedicated Data Collector (and potentially also sent to a non-regulatory- >dedicated Data Collector if the data is to be used for other use cases, as= well), >but this isn't how I would design things; I would split the data out after= it >gets to the Data Collector, and not complicate the MA by making it know >which data gets used for what use case. Definition D doesn't seem to apply= , >given how the Data Collector is discussed in the liaison. >> >> Barbara > > >Well ... you're just missing the point : how do you ensure the anonymity o= f >the measurement results ? the question is *HOW*. Period. > >The split of the data collector level of privacy is not the right answer. = It's just >a bandaid on a bad design. The right question is : > >How do you guarantee a level of privacy AND anonymity of the >measurement results in your non-very-centralized design ? > >One time private or session key is just one of the answer -with overheads-= . > >The job now is to find a really good way to ensure both. I can really help= the >LMAP WG but please, do use this mailing list of a primary tool to build th= e >design from scratch or zero. Do not thrown dump idea out of the box here o= f >future IETF or IEEE standard without a primary discussion here. > >The end result will be just like it looks right : please guys or girls, go= back to >your white board and think deeper. > >Regards, > >-- >J=E9r=F4me Benoit aka fraggle >La M=E9t=E9o du Net - http://grenouille.com >OpenPGP Key ID : 9FE9161D >Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From jerome.benoit@grenouille.com Mon Apr 8 10:33: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 E1E6C21F9133 for ; Mon, 8 Apr 2013 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[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 FPVozVb28Ik0 for ; Mon, 8 Apr 2013 10:33:53 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 05B3121F9079 for ; Mon, 8 Apr 2013 10:33:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id EA2227F60D for ; Mon, 8 Apr 2013 19:33:49 +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 qtAOvP8zGr1p for ; Mon, 8 Apr 2013 19:33:40 +0200 (CEST) Date: Mon, 8 Apr 2013 19:33:39 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Message-ID: <20130408193339.7f91eb3b@nemesis.grenouille.com> In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ne8Ia/SE_vXuLdaQ8+_A2Gn"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 17:33:54 -0000 --Sig_/ne8Ia/SE_vXuLdaQ8+_A2Gn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 8 Apr 2013 10:10:37 +0100 in , trevor.burbridge@bt.com wrote: > I think our visions of the LMAP framework may be rather different. >=20 > For myself (and I think Barbara) things are fairly simple. _All_ data col= lection is private.=20 Why ?=20 If I want to do data mining in order to classify ISP, I do not want to have to ask :=20 * for a permission to access the data;=20 * for a permission from all users that run the measurement agent to avoid some legal issue.=20 The system must ensure technically that the data will stay anonymous and because of that, freely available to anyone that want to dig them. =20 > Someone installs Measurement Agents and collects the results. This commun= ication will be secured. Outside the technical system there will be an agre= ement of what data is collected and what can be done with it. We certainly = don't want to be in the business of a user creating electronic use policies= for the data. It's not a matter of business, it's a matter of ethics : it's the users data, it's not the collectors data and the measurement system must be thoughts with that in mind.=20 >=20 > The Measurement Agent will have an identifier that can be linked with a l= iving subject by the Controller (although the Measurement Agent is unlikely= to know either the details of this person itself). This has to be the case= since the Controller installed/configured this measurement agent in the fi= rst place. The framework would allow the Collector to be a party who does n= ot have this information - practically though the data can be collected by = the same organisation as the Controller of the Measurement Agents, processe= d to whatever standards of blurring/blending/anonymity is required before p= assing to other parties. OK, but you move the pb to a another level in the architecture : Can the measurement agent trust all the data collectors ? Can the user behind the measurement agent (that can perform passive measurement) just blindly throw raw results to a third party data collector runt by people he do not know ?=20 =20 > Nowhere in our use cases do we seem to have a requirement to have Measure= ment Agents reporting directly to a publically accessible datastore. Great, so you design a measurement system that directly express : hey users, trust blindly your private data-store, even if we can capture your passwords, trust all the people running the system ... active or passive measurement, the owner of the data is the end-user and it's just common sense to let's the user choose what he want other people will do with his data and It must be covered not only legally but by design. The measurement system your trying the design if for private interest, the measurement system I will like to see designed is for public interest.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/ne8Ia/SE_vXuLdaQ8+_A2Gn Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFi/3MACgkQ+qDLUJ/pFh0BuACePrdBwzirS4faCEBR0Pf1bj+M 08sAoITKyR5HuQMPRUJujKvjtpIJ1WVU =Heo1 -----END PGP SIGNATURE----- --Sig_/ne8Ia/SE_vXuLdaQ8+_A2Gn-- From bs7652@att.com Mon Apr 8 11:32: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 71A7C21F9234 for ; Mon, 8 Apr 2013 11:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QkFjXSiIW8Zh for ; Mon, 8 Apr 2013 11:32:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9EA21F913E for ; Mon, 8 Apr 2013 11:32:28 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id c3d03615.2aaad5c15940.230404.00-515.649344.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 08 Apr 2013 18:32:28 +0000 (UTC) X-MXL-Hash: 51630d3c6c84492d-ca21e927130db20c581b656f122e120d13642543 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 43d03615.0.230329.00-195.649115.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 08 Apr 2013 18:32:27 +0000 (UTC) X-MXL-Hash: 51630d3b56ae7626-e2e99d89013cf8e6c482368453d783885680b253 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r38IWK9d029459; Mon, 8 Apr 2013 14:32:20 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r38IW7NN029292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Apr 2013 14:32:12 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 8 Apr 2013 19:31:52 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 14:31:52 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= , "lmap@ietf.org" Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 - 2nd look Thread-Index: Ac40h1QW8Oacl+n8QpeUI7XS3ApVrA== Date: Mon, 8 Apr 2013 18:31:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113029B34C@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.42.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=MvvlHRme c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=UrjLvlmdaBAA:10 a=sLgMixYlKFQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=JsvUvUT5AYYA:10 a=-kS8ACNlAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=gEsRDbIwAAAA:8 a=l_ajtRGPAAAA:8 a=KOrOiC1LPUs27bdMdhwA:] X-AnalysisOut: [9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=4dyfk4FV-b8A:10] Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 - 2nd look 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, 08 Apr 2013 18:32:29 -0000 OK, I've taken another look at both the liaison and the IEEE draft at http:= //doc.wirelessman.org/16-12-0682-01.=20 As before, I either don't agree with or don't fully understand what is mean= by Private vs. Public. I'm not sure which. But let me suggest some other l= anguage that I do understand. Back in February (and I think at the IETF meeting in March) there was some = robust discussion around "domain". Elements that are all under the control/= management of a single entity (be that entity a person, an ISP, the person'= s employer, a VoIP application provider supplying VoIP service to the perso= n, etc.) are intra-domain, or all inside the same domain. And everything el= se is external to that domain.=20 An MA is in some entity's domain. Let's say the end user has complete contr= ol over the MA, so it's in the end user's domain. If that MA does a test ag= ainst one of the end user's other home networked devices (under the control= of the end user), then the other endpoint of the test (is this the "Server= " in the IEEE draft?) is in the same domain. If the MA does a test against = some Internet site (not under the control of the end user) then that test e= ndpoint is in a different domain (inter-domain test). If the MA is under the control of an ISP and it does tests with another of = the ISP's MAs, it's intra-domain to the ISP. If the MA is under the control of the employer and it does tests to the emp= loyer's MA, it's intra-domain to the employer. If the MA sends its data to a Data Collector owned by the same entity, that= 's intra-domain. If the MA sends data to someone else's Data Collector, tha= t's inter-domain.=20 In the context of a mobile device, I could easily imagine the wireless prov= ider having a (possibly hidden) MA app to do testing. And for the end user = to have downloaded an app on the same device to do testing under the user's= control. And perhaps the employer allows the end user to access the employ= er's network and has supplied a MA app that the employer can control. Each = MA is in a different domain. Wherever there are inter-domain interfaces and communication, there can be = privacy concerns. For example, an ISP may not want to provide competitors w= ith detailed measurement data (or the ability to run measurements to get de= tailed measurement data) of ISP's internal network (privacy related to MAs = in different domains or collected data provided to other domains). An ISP w= ho collects end user data might be (legally or contractually) required to a= nonymize test data before providing it to others (privacy related to collec= ted data provided to other domains). There are also often concerns about wh= at an ISP might do with data it obtains from measurements run against endpo= ints inside the home network (privacy related to MAs in different domains o= r MAs that reside in a network or device that is controlled by a different = domain). J=E9r=F4me, is it possible for the IEEE term "Private" to be interpreted as= "intra-domain" and "Public" as "inter-domain"? If so, this would clarify a= lot. I sensed that you were somewhat offended by my previous response. If so, I'= m sorry. It was not my intention to offend you or sound condescending. I tr= uly am struggling to understand the IEEE 802.16 draft's use of "Private" an= d "Public". These terms appear to be central to the IEEE draft, and they ar= e central to my lack of understanding. Barbara > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > J=E9r=F4me Benoit > Sent: Friday, April 05, 2013 8:23 AM > To: lmap@ietf.org > Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.= 3 >=20 > On Thu, 28 Mar 2013 08:17:46 +0000 in > <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ- > FFEXMB04.global.avaya.com>, > Romascanu, Dan (Dan) "Romascanu, Dan (Dan)" > wrote: >=20 > > Hi, > Hello, > > Please note the following incoming liaison statement from IEEE Project > P802.16.3 concerning the LMAP activity. > > > > https://datatracker.ietf.org/liaison/1244/ > > > > Comments and discussions are welcome. >=20 > There's no point in a private server to help anonymity. A cryptographic > system is enough that can for example one time key pair with a timestamp = as > a pass-phrase- fire and forget crypto -. The main advantage of such a sys= tem > is that you do not need to cypher the transmission, the cyphering is done= at > the payload level, the keys are deleted once the measurement session is > done. The key exchange rate could be high (a downside). The server keep > the private key of a session to de-cypher. I can dig the design if the LM= AP > WG is in a hurry but I will do it anyway later. I call this kind of crypt= ographic > system "time based crypto". >=20 > I really would like the LMAP WG to not throw away the ISP's cheats on a > measurement campaign, it 's not an coding issue, it's a design issue of t= he > measurement by itself : if a measurement design can't cheat a DPI, it's j= ust > not a good measurement design. >=20 > Cheers. >=20 > -- > J=E9r=F4me Benoit aka fraggle > La M=E9t=E9o du Net - http://grenouille.com > OpenPGP Key ID : 9FE9161D > Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From jerome.benoit@grenouille.com Mon Apr 8 13:48:34 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 CE3F721F9156 for ; Mon, 8 Apr 2013 13:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=0.000, 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 sgpcXhaFqk2I for ; Mon, 8 Apr 2013 13:48:34 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE021F913E for ; Mon, 8 Apr 2013 13:48:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id A18DC7F5EA; Mon, 8 Apr 2013 22:48:32 +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 s0exjVjbi4js; Mon, 8 Apr 2013 22:48:20 +0200 (CEST) Date: Mon, 8 Apr 2013 22:38:24 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: "STARK, BARBARA H" Message-ID: <20130408223824.0b62d809@nemesis.grenouille.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113029B34C@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6113029B34C@GAALPA1MSGUSR9L.ITServices.sbc.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eYga+9kG6X/0K+1slObTHCK"; protocol="application/pgp-signature" Cc: "lmap@ietf.org" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 - 2nd look 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, 08 Apr 2013 20:48:34 -0000 --Sig_/eYga+9kG6X/0K+1slObTHCK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 8 Apr 2013 18:31:51 +0000 in <2D09D61DDFA73D4C884805CC7865E6113029B34C@GAALPA1MSGUSR9L.ITServices.sbc.co= m>, STARK, BARBARA H "STARK, BARBARA H" wrote: > J=E9r=F4me, is it possible for the IEEE term "Private" to be interpreted = as "intra-domain" and "Public" as "inter-domain"? If so, this would clarify= a lot. > I sensed that you were somewhat offended by my previous response. If so, = I'm sorry. It was not my intention to offend you or sound condescending. I = truly am struggling to understand the IEEE 802.16 draft's use of "Private" = and "Public". These terms appear to be central to the IEEE draft, and they = are central to my lack of understanding. Probably. But the IEEE standardization process is not a public process. And I'm not an IEEE's member.=20 My point on the measurement result level of privacy is still an important point. And the current RFCs are not clear about that :=20 * Where will be done the data obfuscation ?=20 * How ?=20 * What will be the default behaviour on privacy issue ?=20 I raise the point on purpose, it's a key feature for people to trust such a system. (Hey, I know that people give most their life away to facebook but they at least choose it).=20 Cheers.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/eYga+9kG6X/0K+1slObTHCK Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFjKsAACgkQ+qDLUJ/pFh3VzwCeMyzZ/ZxLTVRAt3Od1YxE5WDi Z4MAn0NvMTkEpyXXOVadQWx28Vx3t3C+ =jlxH -----END PGP SIGNATURE----- --Sig_/eYga+9kG6X/0K+1slObTHCK-- From trammell@tik.ee.ethz.ch Mon Apr 8 14:41:10 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 7732A21F8FED for ; Mon, 8 Apr 2013 14:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 M9CHqBj7Q+cv for ; Mon, 8 Apr 2013 14:41:09 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 603E621F8F2E for ; Mon, 8 Apr 2013 14:41:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0C382D930D; Mon, 8 Apr 2013 23:41:01 +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 3+9g33w0VovP; Mon, 8 Apr 2013 23:41:00 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 DE60CD9305; Mon, 8 Apr 2013 23:40:59 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <20130408193339.7f91eb3b@nemesis.grenouille.com> Date: Tue, 9 Apr 2013 09:40:56 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= X-Mailer: Apple Mail (2.1503) Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 21:41:10 -0000 hi J=E9r=F4me, all, Apologies for the derail, but this thread has touched on an important = point on anonymity in network measurement. On 9 Apr 2013, at 5:33, J=E9r=F4me Benoit = wrote: > On Mon, 8 Apr 2013 10:10:37 +0100 in > = , > trevor.burbridge@bt.com wrote: >=20 > The system must ensure technically that the data will stay anonymous > and because of that, freely available to anyone that want to dig > them. =20 Depending on the exact schema of the data collected, relying on = technical means to ensure anonymity while still providing for = differentiation of individual nodes is not realistic. The utility of a = given data set for a given question is inherently related to the utility = of the dataset for the "question" of identity, and there is a deep and = unavoidable tradeoff between risk of deanonymization and dataset = utility. Given that the networks being measured (1) have a discernible = and well-known structure and (2) link PII (an address/time tuple) with = that structure, there exist practical attacks against structured-mapping = approaches to data anonymization. Best practices in measurement system design (including discarding = identifying information as soon as possible in the process, i.e. at the = MA or first collector; aggregation of results built into the measurement = agents or mediating collectors; and so on) can mitigate these issues = somewhat. Requiring a measurement system to control and audit access to = measurement specifications and results, limiting access to trusted = actors who can be contractually or legally punished in the case of = abuse, must be part of the solution as well. (It need not be part of a = standard measurement architecture, unless the authentication, = authorization, and auditing must interact across domain boundaries). Open publication of results with anonymous _access_ would require the = _complete_ removal of node- or network-level addressing information, = publication only of aggregated results verified to contain information = from enough individual nodes per data point to ensure anonymity.=20 (Back on topic, I agree that the IEEE choice of "public" and "private" = for terminology apparently meaning "external" and "internal" is = regrettable, and would suggest as part of the LMAP response to this = liaison be that they reconsider this terminological choice, because it = would seem to have the potential for a great deal of confusion.) Best regards, Brian= From Henning.Schulzrinne@fcc.gov Mon Apr 8 15:23:14 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 0ED3621F935B for ; Mon, 8 Apr 2013 15:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XgBFZBrz877m for ; Mon, 8 Apr 2013 15:23:11 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0821F9359 for ; Mon, 8 Apr 2013 15:23:07 -0700 (PDT) Received: from gatekeeper4.fcc.gov (HELO p2pxcas01.fccnet.win.fcc.gov) ([192.104.54.21]) by DC-IP-2.fcc.gov with ESMTP; 08 Apr 2013 18:23:06 -0400 Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas01.fccnet.win.fcc.gov ([fe80::1d27:de47:ad2e:9062%13]) with mapi id 14.01.0438.000; Mon, 8 Apr 2013 18:22:29 -0400 From: Henning Schulzrinne To: 'Brian Trammell' , =?iso-8859-1?Q?J=E9r=F4me_Benoit?= Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac4rjLnfWpFw/p7tS3i28o1yTrXHQwGjRQCAAAOlBuAAUHL8gAA8Ef+AABGReIAACKLjAAAHDRbw Date: Mon, 8 Apr 2013 22:22:28 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> In-Reply-To: <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [165.135.229.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 22:23:14 -0000 I think it's important to distinguish between active data (e.g., ping delay= s) and passive data. Knowing the source (IP address) of pings on a fixed co= nnection doesn't appear to divulge PII. For mobile data, location informati= on is an obvious concern, even with active measurements. This discussion ha= s been had in great detail as part of the mobile Measurement Broadband Amer= ica project; you might find the resulting solutions and trade-offs to be of= interest. -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Monday, April 08, 2013 5:41 PM To: J=E9r=F4me Benoit Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 hi J=E9r=F4me, all, Apologies for the derail, but this thread has touched on an important point= on anonymity in network measurement. On 9 Apr 2013, at 5:33, J=E9r=F4me Benoit wr= ote: > On Mon, 8 Apr 2013 10:10:37 +0100 in > ost.net>, trevor.burbridge@bt.com wrote: >=20 > The system must ensure technically that the data will stay anonymous=20 > and because of that, freely available to anyone that want to dig > them. =20 Depending on the exact schema of the data collected, relying on technical m= eans to ensure anonymity while still providing for differentiation of indiv= idual nodes is not realistic. The utility of a given data set for a given q= uestion is inherently related to the utility of the dataset for the "questi= on" of identity, and there is a deep and unavoidable tradeoff between risk = of deanonymization and dataset utility. Given that the networks being measu= red (1) have a discernible and well-known structure and (2) link PII (an ad= dress/time tuple) with that structure, there exist practical attacks agains= t structured-mapping approaches to data anonymization. Best practices in measurement system design (including discarding identifyi= ng information as soon as possible in the process, i.e. at the MA or first = collector; aggregation of results built into the measurement agents or medi= ating collectors; and so on) can mitigate these issues somewhat. Requiring = a measurement system to control and audit access to measurement specificati= ons and results, limiting access to trusted actors who can be contractually= or legally punished in the case of abuse, must be part of the solution as = well. (It need not be part of a standard measurement architecture, unless t= he authentication, authorization, and auditing must interact across domain = boundaries). Open publication of results with anonymous _access_ would require the _comp= lete_ removal of node- or network-level addressing information, publication= only of aggregated results verified to contain information from enough ind= ividual nodes per data point to ensure anonymity.=20 (Back on topic, I agree that the IEEE choice of "public" and "private" for = terminology apparently meaning "external" and "internal" is regrettable, an= d would suggest as part of the LMAP response to this liaison be that they r= econsider this terminological choice, because it would seem to have the pot= ential for a great deal of confusion.) Best regards, Brian _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Mon Apr 8 15:32:28 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 DD0E221F8F6C for ; Mon, 8 Apr 2013 15:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 WJdYK-Drkemg for ; Mon, 8 Apr 2013 15:32:28 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id C768721F8F2C for ; Mon, 8 Apr 2013 15:32:27 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id b7543615.2aaaf824c940.368212.00-520.1032385.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 08 Apr 2013 22:32:27 +0000 (UTC) X-MXL-Hash: 5163457b12bd3e65-1fbebfd9c0e26813a603293af8668ddce6ede365 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 37543615.0.368179.00-485.1032297.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 08 Apr 2013 22:32:26 +0000 (UTC) X-MXL-Hash: 5163457a020d8bb0-a7ae3a121178a55e744c35c7e6781d8d4fc3be83 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r38MWIVm014557; Mon, 8 Apr 2013 18:32:19 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r38MWDwo014522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Apr 2013 18:32:14 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 8 Apr 2013 23:32:02 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Mon, 8 Apr 2013 18:32:02 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= , "lmap@ietf.org" Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac4rjLnfWpFw/p7tS3i28o1yTrXHQwGjRQCAAAOlBuAAUHL8gAA8Ef+AABGReIAAAeYvIA== Date: Mon, 8 Apr 2013 22:32:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> In-Reply-To: <20130408193339.7f91eb3b@nemesis.grenouille.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.42.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=EMaxJSlC c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=UrjLvlmdaBAA:10 a=yAzTK4uSK9IA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=XnCUKPQ8S1gA:10 a=bZv4yfjMO0CN5ytaZNcA:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=WBJfq21xNWaL4fkh:21 a=RJITlLCTyS5Gh554:21] Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 22:32:29 -0000 > > I think our visions of the LMAP framework may be rather different. > > > > For myself (and I think Barbara) things are fairly simple. _All_ data c= ollection > is private. >=20 > Why ? > If I want to do data mining in order to classify ISP, I do not want to ha= ve to ask > : >=20 > * for a permission to access the data; > * for a permission from all users that run the measurement agent to > avoid some legal issue. Case 1: MA and Data Collector managed by ISP. The ISP will be bound b= y national privacy laws. Any data that the ISP is required, by law, to make= available to others, it will. Who gets access and whether they have to ask= permission (from the regulatory agency) to access the legally-mandated dat= a is something that needs to be determined at a national level. Requiring s= omeone who wants access to the legally-mandated data to ask permission from= end users is unrealistic. In this case (where the ISP collects the data), = the ISP can be expected to get that end user permission. Sharing of any oth= er (not covered by legal mandates) data is at the discretion of the ISP, so= long as the ISP abides by laws, and legally binding customer agreements. I= t's also a good idea to take cultural norms and opinions of privacy advocat= es into account. For this case, I consider the interface between the MA and= the Data Collector to be "in scope" of an lmap architecture. All other int= erfaces to the Data Collector are "out of scope" (again, IMO). The tests an= d test endpoints will meet nationally-determined legal requirements. The re= gulatory agency may decide to require tests recommended by IETF, or some ot= her org. Case 2: MA managed by ISP, Data Collector managed by regulatorily-identifie= d entity. The ISP will make sure the MA only provides the mandated data. Al= l else is as above. Case 3: MA and Data Collector managed by regulatorily-identified entity. Wh= atever the regulator decides is what happens. If the regulator mandates tha= t the ISP provide test endpoints, then that's what will occur. If the regul= ator has this other entity provide test endpoints, then that's what will ha= ppen. Case 4: MA managed by the end user. This is appropriate for an end user col= lecting their own measurement data, but I would recommend against trusting = such data for any regulatory purpose. What data the end user collects and w= ho they send it to is up to them. The test endpoints they test against is u= p to them and/or whoever provided them with the MA. Summary: For regulatory-mandated data collection, the regulator makes the r= ules. Hopefully they do this together with ISPs and interested parties and = make sure that end user privacy is taken into account. For all other data, = whoever collects it gets to say what happens to it (while abiding by all ap= plicable laws). > The system must ensure technically that the data will stay anonymous and > because of that, freely available to anyone that want to dig > them. Whoever has access to data must obey applicable laws concerning that = data. Whether there will exist any set of "freely available" data is a matt= er of national policy. If national policy requires that access to all colle= cted data be restricted, then there will be no "freely available" data. If = there is no regulatory requirement for any data to be made available, then = those who have data have the ability to decide whether, to whom, what, and = how to make data available to others, within legal bounds and customer agre= ements. An "lmap architecture" will not know what the applicable laws are; = therefore the "system" is *not* required technically to ensure data anonymi= ty and availability. That is the responsibility of the entities who have th= e data. > > Someone installs Measurement Agents and collects the results. This > communication will be secured. Outside the technical system there will be= an > agreement of what data is collected and what can be done with it. We > certainly don't want to be in the business of a user creating electronic = use > policies for the data. >=20 > It's not a matter of business, it's a matter of ethics : it's the users d= ata, it's not > the collectors data and the measurement system must be thoughts with that > in mind. No, it absolutely is the collector's data. Once someone has the data,= the only thing that guides them are laws. Ethics guide laws. Different nat= ions have different standards of ethics. I agree that it's not a matter of = business. But the only thing protecting the user, once the data has left th= e user's premises, are laws. > > The Measurement Agent will have an identifier that can be linked with a > living subject by the Controller (although the Measurement Agent is unlik= ely > to know either the details of this person itself). This has to be the cas= e since > the Controller installed/configured this measurement agent in the first p= lace. > The framework would allow the Collector to be a party who does not have > this information - practically though the data can be collected by the sa= me > organisation as the Controller of the Measurement Agents, processed to > whatever standards of blurring/blending/anonymity is required before > passing to other parties. >=20 > OK, but you move the pb to a another level in the architecture : Can the > measurement agent trust all the data collectors ? > Can the user behind the measurement agent (that can perform passive > measurement) just blindly throw raw results to a third party data collect= or > run by people he do not know ? That is for the user to decide, before agreeing to have that MA (that= sends data to whatever Data Collector) in his/her home network or device. = But once the user has agreed to have that MA, everything else is outside th= e user's control. The only control the user has is whether or not to allow = the MA to be there. > > Nowhere in our use cases do we seem to have a requirement to have > Measurement Agents reporting directly to a publically accessible datastor= e. >=20 > Great, so you design a measurement system that directly express : hey > users, trust blindly your private data-store, even if we can capture your > passwords, trust all the people running the system ... active or passive > measurement, the owner of the data is the end-user and it's just common > sense to let's the user choose what he want other people will do with his > data and It must be covered not only legally but by design. No, it's only the user's data if it's the user's MA and the user's Da= ta Collector. Once the data has left the user's hands, someone else has pos= session of it, and only laws are really able to govern what happens to it. = If a user doesn't feel they can trust whoever receives the data, then they = won't agree to participate. Which should be their right. But once they've a= greed, they've agreed. Unless they revoke their agreement. It's a binary co= ndition that doesn't require a complex technical solution to manage. > The measurement system your trying the design if for private interest, th= e > measurement system I will like to see designed is for public interest. No, the architecture that I am working towards is an architecture tha= t I believe it is reasonable to expect ISPs to be willing to implement and = deploy. If someone wants to create an architecture that is only useful if a= n ISP implements/deploys it, but which no ISP can reasonably be expected to= willingly agree to, then I have no interest in such an architecture. If so= meone wants to create an architecture that doesn't rely on the ISP doing an= ything, at all, that's fine with me, too. That's a "don't care" for me.=20 Barbara From trammell@tik.ee.ethz.ch Mon Apr 8 15:50: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 102FF21F8523 for ; Mon, 8 Apr 2013 15:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 f4NdTFNfwuXh for ; Mon, 8 Apr 2013 15:50:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 24AF221F877A for ; Mon, 8 Apr 2013 15:50:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B49EDD930C; Tue, 9 Apr 2013 00:50:26 +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 fJzzTFt5rrzQ; Tue, 9 Apr 2013 00:50:26 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 F05BAD9305; Tue, 9 Apr 2013 00:50:24 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: Date: Tue, 9 Apr 2013 10:50:18 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <4F565317-0F0A-421D-B7D8-A6756A8EB249@tik.ee.ethz.ch> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1503) Cc: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= , "lmap@ietf.org" Subject: [lmap] on anonymity and active measurements Re: incoming liaison statement from IEEE Project P802.16.3 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, 08 Apr 2013 22:50:31 -0000 Hi, Henning, all, This is a good point: passively observed data is _far_ more sensitive to = these sorts of concerns.=20 However, since active measurement traffic on (fixed) broadband links = necessarily shares a bottleneck link with user traffic*, information = about the volume and timing of that user traffic may be inferred from = the delay and bandwidth numbers derivable from measurement traffic. In = cases in which the measurement system suspends active measurements = during periods of user-generated cross traffic, you get less = information, but the details of the measurement schedules themselves may = leak information about user activity periods and (very rough estimates = of) volume. Unlike such inference attacks on anonymized passive measurement data, I = haven't actually looked into this in any detail. But it seems like = information in the timing patterns could at _least_ serve to sort users = into "interactive-dominated" versus "bulk-dominated" (i.e. P2P) bins. = Though, indeed, that's almost certainly not enough information to break = address anonymization. It's still not safe to assume that _just_ because it's not user traffic = that there's no risk. Published data still needs to be evaluated for its = utility to determining user identity and activity, though on thinking = about it I'm much less pessimistic about the prospect of a reasonable = tradeoff existing in the active measurement case. :) Best regards, Brian On 9 Apr 2013, at 10:22, Henning Schulzrinne = wrote: > I think it's important to distinguish between active data (e.g., ping = delays) and passive data. Knowing the source (IP address) of pings on a = fixed connection doesn't appear to divulge PII. For mobile data, = location information is an obvious concern, even with active = measurements. This discussion has been had in great detail as part of = the mobile Measurement Broadband America project; you might find the = resulting solutions and trade-offs to be of interest. >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of Brian Trammell > Sent: Monday, April 08, 2013 5:41 PM > To: J=E9r=F4me Benoit > Cc: lmap@ietf.org > Subject: Re: [lmap] incoming liaison statement from IEEE Project = P802.16.3 >=20 > hi J=E9r=F4me, all, >=20 > Apologies for the derail, but this thread has touched on an important = point on anonymity in network measurement. >=20 > On 9 Apr 2013, at 5:33, J=E9r=F4me Benoit = wrote: >=20 >> On Mon, 8 Apr 2013 10:10:37 +0100 in >> = > ost.net>, trevor.burbridge@bt.com wrote: >>=20 >> The system must ensure technically that the data will stay anonymous=20= >> and because of that, freely available to anyone that want to dig >> them. =20 >=20 > Depending on the exact schema of the data collected, relying on = technical means to ensure anonymity while still providing for = differentiation of individual nodes is not realistic. The utility of a = given data set for a given question is inherently related to the utility = of the dataset for the "question" of identity, and there is a deep and = unavoidable tradeoff between risk of deanonymization and dataset = utility. Given that the networks being measured (1) have a discernible = and well-known structure and (2) link PII (an address/time tuple) with = that structure, there exist practical attacks against structured-mapping = approaches to data anonymization. >=20 > Best practices in measurement system design (including discarding = identifying information as soon as possible in the process, i.e. at the = MA or first collector; aggregation of results built into the measurement = agents or mediating collectors; and so on) can mitigate these issues = somewhat. Requiring a measurement system to control and audit access to = measurement specifications and results, limiting access to trusted = actors who can be contractually or legally punished in the case of = abuse, must be part of the solution as well. (It need not be part of a = standard measurement architecture, unless the authentication, = authorization, and auditing must interact across domain boundaries). >=20 > Open publication of results with anonymous _access_ would require the = _complete_ removal of node- or network-level addressing information, = publication only of aggregated results verified to contain information = from enough individual nodes per data point to ensure anonymity.=20 >=20 > (Back on topic, I agree that the IEEE choice of "public" and "private" = for terminology apparently meaning "external" and "internal" is = regrettable, and would suggest as part of the LMAP response to this = liaison be that they reconsider this terminological choice, because it = would seem to have the potential for a great deal of confusion.) >=20 > Best regards, >=20 > Brian > _______________________________________________ > 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 Michael.K.Bugenhagen@centurylink.com Mon Apr 8 23:01: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 B2E8321F8B25 for ; Mon, 8 Apr 2013 23:01:08 -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 QB2SDQC+vwaS for ; Mon, 8 Apr 2013 23:01:07 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 283C221F8AD8 for ; Mon, 8 Apr 2013 23:01:01 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3960Jw8024500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 00:00:20 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 985591E004F; Tue, 9 Apr 2013 01:00:14 -0500 (CDT) Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 62AF41E003F; Tue, 9 Apr 2013 01:00:14 -0500 (CDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r3960DtB029705; Tue, 9 Apr 2013 00:00:13 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r3960DDO029669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 00:00:13 -0600 (MDT) 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; Tue, 9 Apr 2013 01:00:13 -0500 From: "Bugenhagen, Michael K" To: "'Brian Trammell'" , Henning Schulzrinne Thread-Topic: [lmap] on anonymity and active measurements Re: incoming liaison statement from IEEE Project P802.16.3 Thread-Index: AQHONKt78jXy9oLlkU6cQLQFLXJhUJjNX01A Date: Tue, 9 Apr 2013 06:00:13 +0000 Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> <4F565317-0F0A-421D-B7D8-A6756A8EB249@tik.ee.ethz.ch> In-Reply-To: <4F565317-0F0A-421D-B7D8-A6756A8EB249@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.7] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: =?iso-8859-1?Q?J=E9r=F4me_Benoit?= , "lmap@ietf.org" Subject: Re: [lmap] on anonymity and active measurements Re: incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 06:01:08 -0000 Brian, Henning, As Brian mentioned - If the test framework is "open and flexible," and cont= ains a probe placed within a "home network LAN" can expose a great deal mor= e information than the performance of the Access Service itself. 1) What type of information is accessible (just about all of it depending u= pon where the probe is placed)=20 2) Who's information is it (the customer - aka yours and mine) =20 We have to take these into the "how to preserve the rights of the individ= ual" bucket as part of the solution IMHO. =20 My suggestion here is to avoid trying to solve a legal problem in a technic= al standard, and try to find a technical solution to enable the customer to= control what happens to their data, vs. assuming it will be made public an= d trying to solve that. Otherwise we may be doomed to solve the problems associated with outer real= ms of data security, privacy rules, and defining what exactly is anonymity.= =20 Like - How long can someone beyond the customer themselves "hold" data th= at contains private information ? - What are the precautions for securing data, are there reporting respons= ibilities if exposed ? - Who makes the rules on what's considered private, who gets access to th= at and why =20 .... Regards, Mike =20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Bri= an Trammell Sent: Monday, April 08, 2013 5:50 PM To: Henning Schulzrinne Cc: J=E9r=F4me Benoit; lmap@ietf.org Subject: [lmap] on anonymity and active measurements Re: incoming liaison s= tatement from IEEE Project P802.16.3 Hi, Henning, all, This is a good point: passively observed data is _far_ more sensitive to th= ese sorts of concerns.=20 However, since active measurement traffic on (fixed) broadband links necess= arily shares a bottleneck link with user traffic*, information about the vo= lume and timing of that user traffic may be inferred from the delay and ban= dwidth numbers derivable from measurement traffic. In cases in which the me= asurement system suspends active measurements during periods of user-genera= ted cross traffic, you get less information, but the details of the measure= ment schedules themselves may leak information about user activity periods = and (very rough estimates of) volume. Unlike such inference attacks on anonymized passive measurement data, I hav= en't actually looked into this in any detail. But it seems like information= in the timing patterns could at _least_ serve to sort users into "interact= ive-dominated" versus "bulk-dominated" (i.e. P2P) bins. Though, indeed, tha= t's almost certainly not enough information to break address anonymization. It's still not safe to assume that _just_ because it's not user traffic tha= t there's no risk. Published data still needs to be evaluated for its utili= ty to determining user identity and activity, though on thinking about it I= 'm much less pessimistic about the prospect of a reasonable tradeoff existi= ng in the active measurement case. :) Best regards, Brian On 9 Apr 2013, at 10:22, Henning Schulzrinne = wrote: > I think it's important to distinguish between active data (e.g., ping del= ays) and passive data. Knowing the source (IP address) of pings on a fixed = connection doesn't appear to divulge PII. For mobile data, location informa= tion is an obvious concern, even with active measurements. This discussion = has been had in great detail as part of the mobile Measurement Broadband Am= erica project; you might find the resulting solutions and trade-offs to be = of interest. >=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf=20 > Of Brian Trammell > Sent: Monday, April 08, 2013 5:41 PM > To: J=E9r=F4me Benoit > Cc: lmap@ietf.org > Subject: Re: [lmap] incoming liaison statement from IEEE Project=20 > P802.16.3 >=20 > hi J=E9r=F4me, all, >=20 > Apologies for the derail, but this thread has touched on an important poi= nt on anonymity in network measurement. >=20 > On 9 Apr 2013, at 5:33, J=E9r=F4me Benoit = wrote: >=20 >> On Mon, 8 Apr 2013 10:10:37 +0100 in >> > h ost.net>, trevor.burbridge@bt.com wrote: >>=20 >> The system must ensure technically that the data will stay anonymous=20 >> and because of that, freely available to anyone that want to dig >> them. =20 >=20 > Depending on the exact schema of the data collected, relying on technical= means to ensure anonymity while still providing for differentiation of ind= ividual nodes is not realistic. The utility of a given data set for a given= question is inherently related to the utility of the dataset for the "ques= tion" of identity, and there is a deep and unavoidable tradeoff between ris= k of deanonymization and dataset utility. Given that the networks being mea= sured (1) have a discernible and well-known structure and (2) link PII (an = address/time tuple) with that structure, there exist practical attacks agai= nst structured-mapping approaches to data anonymization. >=20 > Best practices in measurement system design (including discarding identif= ying information as soon as possible in the process, i.e. at the MA or firs= t collector; aggregation of results built into the measurement agents or me= diating collectors; and so on) can mitigate these issues somewhat. Requirin= g a measurement system to control and audit access to measurement specifica= tions and results, limiting access to trusted actors who can be contractual= ly or legally punished in the case of abuse, must be part of the solution a= s well. (It need not be part of a standard measurement architecture, unless= the authentication, authorization, and auditing must interact across domai= n boundaries). >=20 > Open publication of results with anonymous _access_ would require the _co= mplete_ removal of node- or network-level addressing information, publicati= on only of aggregated results verified to contain information from enough i= ndividual nodes per data point to ensure anonymity.=20 >=20 > (Back on topic, I agree that the IEEE choice of "public" and "private"=20 > for terminology apparently meaning "external" and "internal" is=20 > regrettable, and would suggest as part of the LMAP response to this=20 > liaison be that they reconsider this terminological choice, because it=20 > would seem to have the potential for a great deal of confusion.) >=20 > Best regards, >=20 > Brian > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From trevor.burbridge@bt.com Tue Apr 9 01:37: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 A5FAC21F9021 for ; Tue, 9 Apr 2013 01:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 iqIpitgr-kKz for ; Tue, 9 Apr 2013 01:37:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id B8D5E21F8F24 for ; Tue, 9 Apr 2013 01:37:48 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 9 Apr 2013 09:37:41 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.187]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Tue, 9 Apr 2013 09:37:41 +0100 From: To: , Date: Tue, 9 Apr 2013 09:37:40 +0100 Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac40fz8QENBdjLuTTVe1yA4WHILNUAAfMkBg Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> In-Reply-To: <20130408193339.7f91eb3b@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 08:37:50 -0000 The use cases we have require the identity of the individual and/or line. F= or a regulator they need to link this to ISP and product, location, market,= line length, marketed speed and other attributes. This information will no= t be publically available to any measurement agent. If there is a problem w= ith the measurement device they need to contact individuals involved. An ISP operating a measurement platform needs the line identifier to be abl= e to diagnose and resolve network problems. We don't currently have primary= use cases which would drive deployment of the measurement devices and woul= d require anonymised data. If there is a secondary use (e.g. by a party who= does not operate the measurement framework) then the first party can apply= anonymisation etc. Trevor. >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >J=E9r=F4me Benoit >Sent: 08 April 2013 18:34 >To: lmap@ietf.org >Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 > >On Mon, 8 Apr 2013 10:10:37 +0100 in >UKRD.domain1.systemhost.net>, >trevor.burbridge@bt.com wrote: > >> I think our visions of the LMAP framework may be rather different. >> >> For myself (and I think Barbara) things are fairly simple. _All_ data >collection is private. > >Why ? >If I want to do data mining in order to classify ISP, I do not want to hav= e to >ask : > >* for a permission to access the data; >* for a permission from all users that run the measurement agent to > avoid some legal issue. > >The system must ensure technically that the data will stay anonymous and >because of that, freely available to anyone that want to dig >them. > >> Someone installs Measurement Agents and collects the results. This >communication will be secured. Outside the technical system there will be = an >agreement of what data is collected and what can be done with it. We >certainly don't want to be in the business of a user creating electronic u= se >policies for the data. > >It's not a matter of business, it's a matter of ethics : it's the users da= ta, it's >not the collectors data and the measurement system must be thoughts with >that in mind. > >> >> The Measurement Agent will have an identifier that can be linked with a >living subject by the Controller (although the Measurement Agent is unlike= ly >to know either the details of this person itself). This has to be the case= since >the Controller installed/configured this measurement agent in the first pl= ace. >The framework would allow the Collector to be a party who does not have >this information - practically though the data can be collected by the sam= e >organisation as the Controller of the Measurement Agents, processed to >whatever standards of blurring/blending/anonymity is required before >passing to other parties. > >OK, but you move the pb to a another level in the architecture : Can the >measurement agent trust all the data collectors ? >Can the user behind the measurement agent (that can perform passive >measurement) just blindly throw raw results to a third party data collecto= r >runt by people he do not know ? > >> Nowhere in our use cases do we seem to have a requirement to have >Measurement Agents reporting directly to a publically accessible datastore= . > >Great, so you design a measurement system that directly express : hey >users, trust blindly your private data-store, even if we can capture your >passwords, trust all the people running the system ... active or passive >measurement, the owner of the data is the end-user and it's just common >sense to let's the user choose what he want other people will do with his >data and It must be covered not only legally but by design. > >The measurement system your trying the design if for private interest, the >measurement system I will like to see designed is for public interest. > >-- >J=E9r=F4me Benoit aka fraggle >La M=E9t=E9o du Net - http://grenouille.com >OpenPGP Key ID : 9FE9161D >Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From jerome.benoit@grenouille.com Tue Apr 9 07:37:34 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 D0F0B21F935E for ; Tue, 9 Apr 2013 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[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 FkZCHAf1-PyW for ; Tue, 9 Apr 2013 07:37:33 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4721F9359 for ; Tue, 9 Apr 2013 07:37:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 476757F704; Tue, 9 Apr 2013 16:37:27 +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 0bpLFVThiumA; Tue, 9 Apr 2013 16:37:18 +0200 (CEST) Date: Tue, 9 Apr 2013 16:37:12 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: "STARK, BARBARA H" Message-ID: <20130409163712.50a63452@nemesis.grenouille.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/EBlCUPi3EOnTsc+uf1/CRrr"; protocol="application/pgp-signature" Cc: "lmap@ietf.org" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 14:37:34 -0000 --Sig_/EBlCUPi3EOnTsc+uf1/CRrr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, 8 Apr 2013 22:32:02 +0000 in <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.co= m>, STARK, BARBARA H "STARK, BARBARA H" wrote: > > > * for a permission to access the data; > > * for a permission from all users that run the measurement agent to > > avoid some legal issue. >=20 > Case 1: MA and Data Collector managed by ISP. The ISP will be bound= by national privacy laws. Any data that the ISP is required, by law, to ma= ke available to others, it will. Who gets access and whether they have to a= sk permission (from the regulatory agency) to access the legally-mandated d= ata is something that needs to be determined at a national level. Requiring= someone who wants access to the legally-mandated data to ask permission fr= om end users is unrealistic. In this case (where the ISP collects the data)= , the ISP can be expected to get that end user permission. Sharing of any o= ther (not covered by legal mandates) data is at the discretion of the ISP, = so long as the ISP abides by laws, and legally binding customer agreements.= It's also a good idea to take cultural norms and opinions of privacy advoc= ates into account. For this case, I consider the interface between the MA a= nd the Data Collector to be "in scope" of an lmap architecture. All other i= nterfaces to the=20 > Data Collector are "out of scope" (again, IMO). The tests and test endpo= ints will meet nationally-determined legal requirements. The regulatory age= ncy may decide to require tests recommended by IETF, or some other org. > >=20 > Case 2: MA managed by ISP, Data Collector managed by regulatorily-identif= ied entity. The ISP will make sure the MA only provides the mandated data. = All else is as above. >=20 > Case 3: MA and Data Collector managed by regulatorily-identified entity. = Whatever the regulator decides is what happens. If the regulator mandates t= hat the ISP provide test endpoints, then that's what will occur. If the reg= ulator has this other entity provide test endpoints, then that's what will = happen. >=20 > Case 4: MA managed by the end user. This is appropriate for an end user c= ollecting their own measurement data, but I would recommend against trustin= g such data for any regulatory purpose. What data the end user collects and= who they send it to is up to them. The test endpoints they test against is= up to them and/or whoever provided them with the MA. Case 5 : MA run by end user; landmarks run by ISP, end-users (the MA embed landmark functionalities), non-profit organisation, who knows; data collectors run a non-profit organisation, ISP, national agency that regulate "communication", who knows; data mining done by ISP, non-profit organization, etc. =20 Internet is designed as an end to end open commutated network and the use case LMAP you describe do not fellow at least the same policy. It's rather a bad idea that will just end to people's trust in the LMAP results. =20 > Summary: For regulatory-mandated data collection, the regulator makes the= rules. Hopefully they do this together with ISPs and interested parties an= d make sure that end user privacy is taken into account. For all other data= , whoever collects it gets to say what happens to it (while abiding by all = applicable laws). I do not care about the rules made by people I can't get in touch with, I c= are about=20 the level of privacy, the level of trust *people* will give to the LMAP and the technical side of these problematics to implement it in the LMAP. =20 >=20 > > The system must ensure technically that the data will stay anonymous and > > because of that, freely available to anyone that want to dig > > them. >=20 > Whoever has access to data must obey applicable laws concerning tha= t data. Whether there will exist any set of "freely available" data is a ma= tter of national policy. If national policy requires that access to all col= lected data be restricted, then there will be no "freely available" data. I= f there is no regulatory requirement for any data to be made available, the= n those who have data have the ability to decide whether, to whom, what, an= d how to make data available to others, within legal bounds and customer ag= reements. An "lmap architecture" will not know what the applicable laws are= ; therefore the "system" is *not* required technically to ensure data anony= mity and availability. That is the responsibility of the entities who have = the data. I strongly disagree with your opinions here : The whole point of the LMAP is to offer to the people a measurement system that they can *TRUST*.=20 You're just building the opposite : measurement done with opacity, measurement results collected and "stolen" from the people, mining that can't be verified by anyone by default.=20 That kind of measurement system is so away from the Internet way of designing protocols that you will just kill the baby before he grows up. =20 > > It's not a matter of business, it's a matter of ethics : it's the users= data, it's not > > the collectors data and the measurement system must be thoughts with th= at > > in mind. > No, it absolutely is the collector's data. Once someone has the dat= a, the only thing that guides them are laws. Ethics guide laws. Different n= ations have different standards of ethics. I agree that it's not a matter o= f business. But the only thing protecting the user, once the data has left = the user's premises, are laws. I'm an engineer and most the people here probably so. Laws are for lawyers.=20 If you're engineering an LMAP to do not offer the minimum privacy requirement to enforce people trust in the system with measurements' :=20 * transparency;=20 * openness;=20 * privacy;=20 * neutrality.=20 Well, ... you're just missing the point of an LMAP made by the people and for the people that will last and last and last and last.=20 > > > The Measurement Agent will have an identifier that can be linked with= a > > living subject by the Controller (although the Measurement Agent is unl= ikely > > to know either the details of this person itself). This has to be the c= ase since > > the Controller installed/configured this measurement agent in the first= place. > > The framework would allow the Collector to be a party who does not have > > this information - practically though the data can be collected by the = same > > organisation as the Controller of the Measurement Agents, processed to > > whatever standards of blurring/blending/anonymity is required before > > passing to other parties. > >=20 > > OK, but you move the pb to a another level in the architecture : Can the > > measurement agent trust all the data collectors ? > > Can the user behind the measurement agent (that can perform passive > > measurement) just blindly throw raw results to a third party data colle= ctor > > run by people he do not know ? >=20 > That is for the user to decide, before agreeing to have that MA (th= at sends data to whatever Data Collector) in his/her home network or device= . But once the user has agreed to have that MA, everything else is outside = the user's control. The only control the user has is whether or not to allo= w the MA to be there. I propose a design where people have control over their data. You must really have a good argument to throw the idea away. So far, you've not raised a single good argument against it : the legalese is out of the scope of an engineering decision that can ensure a good level of privacy in the measurement system in regard to the very high level of private raw datas that will go in a datastore for passive measurement. =20 >=20 > > > Nowhere in our use cases do we seem to have a requirement to have > > Measurement Agents reporting directly to a publically accessible datast= ore. > >=20 > > Great, so you design a measurement system that directly express : hey > > users, trust blindly your private data-store, even if we can capture yo= ur > > passwords, trust all the people running the system ... active or passive > > measurement, the owner of the data is the end-user and it's just common > > sense to let's the user choose what he want other people will do with h= is > > data and It must be covered not only legally but by design. > No, it's only the user's data if it's the user's MA and the user's = Data Collector. Once the data has left the user's hands, someone else has p= ossession of it, and only laws are really able to govern what happens to it= . If a user doesn't feel they can trust whoever receives the data, then the= y won't agree to participate. Which should be their right. But once they've= agreed, they've agreed. Unless they revoke their agreement. It's a binary = condition that doesn't require a complex technical solution to manage. Sure : let's me make you understand one basic condition of user participati= on in such a system : no single user will give to anyone a raw packets capture without strong technical guarantee that the third party will not be able to associate the capture to the user (and even with technical guarantee, user will still be hesitating on giving away raw packets capture). So either the future WG acknowledge this very simple fact, either all passive measurement that need mining on raw packets capture will just never happen is the real world.=20 > > The measurement system your trying the design if for private interest, = the > > measurement system I will like to see designed is for public interest. >=20 > No, the architecture that I am working towards is an architecture t= hat I believe it is reasonable to expect ISPs to be willing to implement an= d deploy. If someone wants to create an architecture that is only useful if= an ISP implements/deploys it, but which no ISP can reasonably be expected = to willingly agree to, then I have no interest in such an architecture. If = someone wants to create an architecture that doesn't rely on the ISP doing = anything, at all, that's fine with me, too. That's a "don't care" for me.=20 See Case 5 Regards, --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/EBlCUPi3EOnTsc+uf1/CRrr Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFkJ5kACgkQ+qDLUJ/pFh3FvACfcwY0HHgt+Bzv+NlYvogFTWS7 ptkAnRH3zHrnEElt6/Jk34W//1dxvQvV =rb4K -----END PGP SIGNATURE----- --Sig_/EBlCUPi3EOnTsc+uf1/CRrr-- From trevor.burbridge@bt.com Tue Apr 9 08:08: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 2A76C21F9349 for ; Tue, 9 Apr 2013 08:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 xZWIDXvun26U for ; Tue, 9 Apr 2013 08:08:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 705AE21F9370 for ; Tue, 9 Apr 2013 08:08:36 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 9 Apr 2013 16:08:35 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.187]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 9 Apr 2013 16:08:35 +0100 From: To: , Date: Tue, 9 Apr 2013 16:08:33 +0100 Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac41L8hJEdgIPIrQThaeW1x9NYutxQAAwkwA Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> In-Reply-To: <20130409163712.50a63452@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 15:08:40 -0000 >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >J=E9r=F4me Benoit >Sent: 09 April 2013 15:37 >To: STARK, BARBARA H >Cc: lmap@ietf.org >Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 ... >Case 5 : MA run by end user; landmarks run by ISP, end-users (the MA >embed landmark functionalities), non-profit organisation, who knows; data >collectors run a non-profit organisation, ISP, national agency that regula= te >"communication", who knows; data mining done by ISP, non-profit >organization, etc. If you have a use case that you clearly think needs to be accommodated in t= he design of the LMAP framework, then write it up. Then we can have the dis= cussion of whether this use case can be done with a certain design. "who-kn= ows" is not good enough - we can't design a system to requirements that may= or may not exist. In my opinion this use case needs to be for the benefit = of someone who might actually pay for a measurement framework - i.e. there = needs to be a deployment motivation. At the end of the day if these additio= nal use cases push the design to be too complex, costly, late or not fit fo= r certain other use cases then it may never get deployed. Trevor. From jerome.benoit@grenouille.com Tue Apr 9 08:14:18 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 D683521F9452 for ; Tue, 9 Apr 2013 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[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 BriqHG3wwrDY for ; Tue, 9 Apr 2013 08:14:18 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id EE5A021F9402 for ; Tue, 9 Apr 2013 08:14:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id D65887F231 for ; Tue, 9 Apr 2013 17:14:16 +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 jdGTjnn_4koy for ; Tue, 9 Apr 2013 17:14:05 +0200 (CEST) Date: Tue, 9 Apr 2013 17:14:05 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130409171405.0f0ba593@nemesis.grenouille.com> In-Reply-To: <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/eR.a5Kkq5MP_od7SUlarF.P"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 15:14:19 -0000 --Sig_/eR.a5Kkq5MP_od7SUlarF.P Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 9 Apr 2013 09:40:56 +1200 in <10997E44-5F53-4E1D-A34C-7E49BC0A7510@tik.ee.ethz.ch>, Brian Trammell Brian Trammell wrote: > hi J=E9r=F4me, all, >=20 > Apologies for the derail, but this thread has touched on an important poi= nt on anonymity in network measurement. I hope so :) =20 >=20 > On 9 Apr 2013, at 5:33, J=E9r=F4me Benoit = wrote: >=20 > > On Mon, 8 Apr 2013 10:10:37 +0100 in > > , > > trevor.burbridge@bt.com wrote: > >=20 > > The system must ensure technically that the data will stay anonymous > > and because of that, freely available to anyone that want to dig > > them. =20 >=20 > Depending on the exact schema of the data collected, relying on technical= means to ensure anonymity while still providing for differentiation of ind= ividual nodes is not realistic. The utility of a given data set for a given= question is inherently related to the utility of the dataset for the "ques= tion" of identity, and there is a deep and unavoidable tradeoff between ris= k of deanonymization and dataset utility. Given that the networks being mea= sured (1) have a discernible and well-known structure and (2) link PII (an = address/time tuple) with that structure, there exist practical attacks agai= nst structured-mapping approaches to data anonymization. The trade-off on anonymity is probably unavoidable (but I must still think about it some more) but it must exist in the design. So far,=20 the RFCs do not enforce a policy on it. =20 =20 > Best practices in measurement system design (including discarding identif= ying information as soon as possible in the process, i.e. at the MA or firs= t collector; aggregation of results built into the measurement agents or me= diating collectors; and so on) can mitigate these issues somewhat. Requirin= g a measurement system to control and audit access to measurement specifica= tions and results, limiting access to trusted actors who can be contractual= ly or legally punished in the case of abuse, must be part of the solution a= s well. I agree. So time to put this BCPs in the RFC ? All the technical details will go in further RFCs but pretty please state that this issue on privacy and anonymity will be take into account.=20 > (It need not be part of a standard measurement architecture, unless > the authentication, authorization, and auditing must interact across > domain boundaries). I disagree :) It's not that hard to design a cryptographic system inside the LMAP that can trade-off between the crypto load in the system and the level of privacy. --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/eR.a5Kkq5MP_od7SUlarF.P Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFkMD0ACgkQ+qDLUJ/pFh10rQCg8E7rad/tE1u4tJADreAqj8Kr QiUAoMJ9ymsr4fHNfvZjB4tq3x8GHxFx =9r3Z -----END PGP SIGNATURE----- --Sig_/eR.a5Kkq5MP_od7SUlarF.P-- From hannes.tschofenig@gmx.net Tue Apr 9 08:22:35 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 6E8BC21F947C for ; Tue, 9 Apr 2013 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 f6wyOxXO6d3f for ; Tue, 9 Apr 2013 08:22:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDFE21F9423 for ; Tue, 9 Apr 2013 08:22:34 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0McCWP-1U7mfy0eNL-00JYkQ for ; Tue, 09 Apr 2013 17:22:29 +0200 Received: (qmail invoked by alias); 09 Apr 2013 15:22:28 -0000 Received: from 199-119-118-18.i95.net (EHLO [192.168.0.136]) [199.119.118.18] by mail.gmx.net (mp024) with SMTP; 09 Apr 2013 17:22:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18dP9Ryo9YdSygBcQlHJOuHuZmjRAppQzRl6u7fXG KNVeRGJhWlG5fZ From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Apr 2013 18:22:26 +0300 Message-Id: To: Benoit Claise , Dan Romascanu , Al Morton Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , lmap@ietf.org Subject: [lmap] Status of the Chartering? 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, 09 Apr 2013 15:22:35 -0000 Hi Dan, Hi Al, Hi Benoit,=20 after the successful BOF in Orlando I was wondering what the status of = the WG chartering discussion is.=20 Any chance to give me (and the group) a brief heads-up?=20 Ciao Hannes From bclaise@cisco.com Tue Apr 9 08:36:18 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 B07E821F9724 for ; Tue, 9 Apr 2013 08:36:18 -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 utQ8hS9bF5Fs for ; Tue, 9 Apr 2013 08:36:18 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E7AEF21F937A for ; Tue, 9 Apr 2013 08:36:17 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39FaBMe026873; Tue, 9 Apr 2013 17:36:11 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r39FZTeP024088; Tue, 9 Apr 2013 17:35:44 +0200 (CEST) Message-ID: <516434F3.8020807@cisco.com> Date: Tue, 09 Apr 2013 17:34:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Romascanu , Al Morton , lmap@ietf.org Subject: Re: [lmap] Status of the Chartering? 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, 09 Apr 2013 15:36:18 -0000 Hi Hannes, Working on this today. Expect an email tomorrow. Regards, Benoit > Hi Dan, Hi Al, Hi Benoit, > > after the successful BOF in Orlando I was wondering what the status of the WG chartering discussion is. > Any chance to give me (and the group) a brief heads-up? > > Ciao > Hannes > > > From jerome.benoit@grenouille.com Tue Apr 9 08:49:18 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 7354521F97D5 for ; Tue, 9 Apr 2013 08:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=1.300, 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 qX9-RLWtn+Ao for ; Tue, 9 Apr 2013 08:49:17 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8767821F97B1 for ; Tue, 9 Apr 2013 08:49:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id A0A4E7F23B for ; Tue, 9 Apr 2013 17:49:15 +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 2QVL3paf5mZf for ; Tue, 9 Apr 2013 17:49:06 +0200 (CEST) Date: Tue, 9 Apr 2013 17:49:04 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: lmap@ietf.org Message-ID: <20130409174904.1fcea33e@nemesis.grenouille.com> In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/R.Ucx=38v_wGEWB3nUp/yqp"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 15:49:18 -0000 --Sig_/R.Ucx=38v_wGEWB3nUp/yqp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 9 Apr 2013 16:08:33 +0100 in , trevor.burbridge@bt.com wrote: > > >Case 5 : MA run by end user; landmarks run by ISP, end-users (the MA > >embed landmark functionalities), non-profit organisation, who knows; data > >collectors run a non-profit organisation, ISP, national agency that regu= late > >"communication", who knows; data mining done by ISP, non-profit > >organization, etc. >=20 > If you have a use case that you clearly think needs to be accommodated in= the design of the LMAP framework, then write it up. Then we can have the d= iscussion of whether this use case can be done with a certain design. "who-= knows" is not good enough - we can't design a system to requirements that m= ay or may not exist. In my opinion this use case needs to be for the benefi= t of someone who might actually pay for a measurement framework - i.e. ther= e needs to be a deployment motivation. At the end of the day if these addit= ional use cases push the design to be too complex, costly, late or not fit = for certain other use cases then it may never get deployed. The non-profit organisation I participate as a volunteer have landmarks inside the ISP backbone, outside the ISP backbone runt by volunteers, peering association, hosting entreprise. The MA are run on end-user computer. The MA is designed and implemented to send data to different data collector because ISP, researchers, advanced end-user want the data. The MA is responsible of the data obfuscation (the new one, not the old one). It's as simple as it is : the use case do already exist and the implementation is on it's way to reflect the use case.=20 / Data Collector MA- Data Collector =20 \ Data Collector - is a connector, default is a REST protocol but the code is modular.=20 Why not do data collector synchronization ?=20 Because we want the MA user to choose to whom he want to send the data.=20 Why we choose to anonymize the data ? Because the personal user data are belonging to the user and not to anyone else.=20 Where we choose to anonymize ?=20 The MA. It's in the hand of the user with good default values. =20 How ?=20 Under discussion. Results are expressed in JSON syntax. JSONSEC extension (like XMLSEC) is under evaluation, spec to be written as well as other way to anonymize the data : discard one octet of IP addresses, discard fields in datagram, constant hash where possible for certain measurement that do not the know the content if the content is different, etc.=20 Cheers. =20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/R.Ucx=38v_wGEWB3nUp/yqp Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFkOHAACgkQ+qDLUJ/pFh0DYgCfQ5xvBIVSSAiDsCIrGK2rkiG8 AB8AnRhhzcL/JNIxGKnYJj6029OVtMH+ =AHc5 -----END PGP SIGNATURE----- --Sig_/R.Ucx=38v_wGEWB3nUp/yqp-- From trevor.burbridge@bt.com Tue Apr 9 09:04: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 91A7521F8F39 for ; Tue, 9 Apr 2013 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, 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 K3aMQQJcuIF6 for ; Tue, 9 Apr 2013 09:04:31 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF4C21F8EEB for ; Tue, 9 Apr 2013 09:04:31 -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.297.1; Tue, 9 Apr 2013 17:04:29 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.187]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Tue, 9 Apr 2013 17:04:29 +0100 From: To: , Date: Tue, 9 Apr 2013 17:04:29 +0100 Thread-Topic: [lmap] incoming liaison statement from IEEE Project P802.16.3 Thread-Index: Ac41Oc4G2Ijw1QwAQnCSTUlB3WKSkwAAWnaA Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> <20130409174904.1fcea33e@nemesis.grenouille.com> In-Reply-To: <20130409174904.1fcea33e@nemesis.grenouille.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 16:04:32 -0000 I don't see why this isn't covered by the envisaged framework - user owns t= he controller and MA, schedules their own tests and specifies the collector= s of the data for the various tests as part of the test configuration. The = result report will include a random UUID for example (necessary to correlat= e multiple reports from the same probe). In your case we would not perform = MA authentication I guess. If the user wants to send these results to the c= ollector via a proxy or TOR network or similar to hide their IP address thi= s would be possible. Trevor. Trevor Burbridge Network Infrastructure & Innovation | BT Innovate & Design Tel: 01473 645115 Fax: 01473 640929 This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.=20 British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000=20 >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >J=E9r=F4me Benoit >Sent: 09 April 2013 16:49 >To: lmap@ietf.org >Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 > >On Tue, 9 Apr 2013 16:08:33 +0100 in >UKRD.domain1.systemhost.net>, >trevor.burbridge@bt.com wrote: > >> >> >Case 5 : MA run by end user; landmarks run by ISP, end-users (the MA >> >embed landmark functionalities), non-profit organisation, who knows; >> >data collectors run a non-profit organisation, ISP, national agency >> >that regulate "communication", who knows; data mining done by ISP, >> >non-profit organization, etc. >> >> If you have a use case that you clearly think needs to be accommodated i= n >the design of the LMAP framework, then write it up. Then we can have the >discussion of whether this use case can be done with a certain design. "wh= o- >knows" is not good enough - we can't design a system to requirements that >may or may not exist. In my opinion this use case needs to be for the bene= fit >of someone who might actually pay for a measurement framework - i.e. >there needs to be a deployment motivation. At the end of the day if these >additional use cases push the design to be too complex, costly, late or no= t fit >for certain other use cases then it may never get deployed. > > >The non-profit organisation I participate as a volunteer have landmarks >inside the ISP backbone, outside the ISP backbone runt by volunteers, >peering association, hosting entreprise. The MA are run on end-user >computer. The MA is designed and implemented to send data to different >data collector because ISP, researchers, advanced end-user want the data. >The MA is responsible of the data obfuscation (the new one, not the old >one). It's as simple as it is : the use case do already exist and the >implementation is on it's way to reflect the use case. > > / Data Collector >MA- Data Collector > \ Data Collector > > > - is a connector, default is a REST protocol but the code is modular. > >Why not do data collector synchronization ? >Because we want the MA user to choose to whom he want to send the data. > >Why we choose to anonymize the data ? >Because the personal user data are belonging to the user and not to anyone >else. > >Where we choose to anonymize ? >The MA. It's in the hand of the user with good default values. > >How ? >Under discussion. Results are expressed in JSON syntax. JSONSEC extension >(like XMLSEC) is under evaluation, spec to be written as well as other way= to >anonymize the data : discard one octet of IP addresses, discard fields in >datagram, constant hash where possible for certain measurement that do >not the know the content if the content is different, etc. > >Cheers. > >-- >J=E9r=F4me Benoit aka fraggle >La M=E9t=E9o du Net - http://grenouille.com >OpenPGP Key ID : 9FE9161D >Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D From jerome.benoit@grenouille.com Tue Apr 9 10:33:56 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 7767C21F944A for ; Tue, 9 Apr 2013 10:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[AWL=0.650, 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 zdvJaUkcVAiH for ; Tue, 9 Apr 2013 10:33:55 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCB321F942B for ; Tue, 9 Apr 2013 10:33:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 8C1607F633 for ; Tue, 9 Apr 2013 19:33:54 +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 wAO1M7igJjvs for ; Tue, 9 Apr 2013 19:33:44 +0200 (CEST) Date: Tue, 9 Apr 2013 19:33:42 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Message-ID: <20130409193342.7d7f80a0@nemesis.grenouille.com> In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> <20130409174904.1fcea33e@nemesis.grenouille.com> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/1d2v.oth62KbitcL=VgPXDT"; protocol="application/pgp-signature" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 17:33:56 -0000 --Sig_/1d2v.oth62KbitcL=VgPXDT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 9 Apr 2013 17:04:29 +0100 in , trevor.burbridge@bt.com wrote: > I don't see why this isn't covered by the envisaged framework - user owns= the controller and MA, schedules their own tests and specifies the collect= ors of the data for the various tests as part of the test configuration. Th= e result report will include a random UUID for example (necessary to correl= ate multiple reports from the same probe). The level of privacy of measurement data or meta-data is non stated anywhere in the RFCs, not even taken into account. And it's not too late to define different level of privacy in the RFCs > In your case we would not perform MA authentication I guess. If the user = wants to send these results to the collector via a proxy or TOR network or = similar to hide their IP address this would be possible. I will but with the measurement agent coordinator, not with the data collector as long as a level of privacy is defined on measurement results with an corresponding implementation of the level of privacy. It can be a measurement based policy or a global policy. Measurement are either user-defined or coordinated.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/1d2v.oth62KbitcL=VgPXDT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFkUPYACgkQ+qDLUJ/pFh3F9gCg2rmfve1xeZqRJ3L5NQq2N3xw Ym4An2LqfTi5wtRPjxnh4BiaLxZD4sKR =Hf48 -----END PGP SIGNATURE----- --Sig_/1d2v.oth62KbitcL=VgPXDT-- From j.schoenwaelder@jacobs-university.de Tue Apr 9 11:49: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 5FC4121F944B for ; Tue, 9 Apr 2013 11:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=1.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 5mL7X9v98JDW for ; Tue, 9 Apr 2013 11:49:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ABEFD21F9446 for ; Tue, 9 Apr 2013 11:49:04 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA39620BDB; Tue, 9 Apr 2013 20:49:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id USL8BSc-8Xzh; Tue, 9 Apr 2013 20:49:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7954A209D7; Tue, 9 Apr 2013 20:49:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9F451258D2C9; Tue, 9 Apr 2013 20:49:08 +0200 (CEST) Date: Tue, 9 Apr 2013 20:49:07 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?B?Suly9G1l?= Benoit Message-ID: <20130409184907.GA866@elstar.local> Mail-Followup-To: =?iso-8859-1?B?Suly9G1l?= Benoit , lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> <20130409174904.1fcea33e@nemesis.grenouille.com> <20130409193342.7d7f80a0@nemesis.grenouille.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130409193342.7d7f80a0@nemesis.grenouille.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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: Tue, 09 Apr 2013 18:49:05 -0000 On Tue, Apr 09, 2013 at 07:33:42PM +0200, Jérôme Benoit wrote: > > The level of privacy of measurement data or meta-data is non stated > anywhere in the RFCs, not even taken into account. And it's not too > late to define different level of privacy in the RFCs > So please, write an I-D discussing the privacy of measurement data and meta-data and how it can be protected. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jerome.benoit@grenouille.com Tue Apr 9 13:24:52 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 9D2B221F9853 for ; Tue, 9 Apr 2013 13:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=0.433, 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 gbwsmHWmqj8u for ; Tue, 9 Apr 2013 13:24:36 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C321F9850 for ; Tue, 9 Apr 2013 13:24:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 7EB397F5DD; Tue, 9 Apr 2013 22:24:34 +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 hjfqv5JXirlU; Tue, 9 Apr 2013 22:24:25 +0200 (CEST) Date: Tue, 9 Apr 2013 22:24:24 +0200 From: =?ISO-8859-1?B?Suly9G1l?= Benoit To: Juergen Schoenwaelder Message-ID: <20130409222424.6fb47090@nemesis.grenouille.com> In-Reply-To: <20130409184907.GA866@elstar.local> References: <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> <20130409174904.1fcea33e@nemesis.grenouille.com> <20130409193342.7d7f80a0@nemesis.grenouille.com> <20130409184907.GA866@elstar.local> Organization: Grenouille.com X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/wFjc1kqaJX4x2eICuAZ/LgW"; protocol="application/pgp-signature" Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 20:24:52 -0000 --Sig_/wFjc1kqaJX4x2eICuAZ/LgW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 9 Apr 2013 20:49:07 +0200 in <20130409184907.GA866@elstar.local>, Juergen Schoenwaelder Juergen Schoenwaelder wrote: > =20 > So please, write an I-D discussing the privacy of measurement data > and meta-data and how it can be protected. >=20 Can it wait for a week ?=20 I'm travelling right now and should be able to write only something at the end of the next week.=20 --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --Sig_/wFjc1kqaJX4x2eICuAZ/LgW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEUEARECAAYFAlFkePgACgkQ+qDLUJ/pFh1R0gCgrMMf3YyVN1xNQ8VcP8LK00uJ fk8AljkfNYNQvx1wgwL6pbE/WX0jg70= =pF5b -----END PGP SIGNATURE----- --Sig_/wFjc1kqaJX4x2eICuAZ/LgW-- From hannes.tschofenig@gmx.net Tue Apr 9 13:31: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 2477B21F9816 for ; Tue, 9 Apr 2013 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 8-razMfyvSnE for ; Tue, 9 Apr 2013 13:31:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD09221F981C for ; Tue, 9 Apr 2013 13:31:09 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M38kj-1Uh3id2mjn-00sz1m for ; Tue, 09 Apr 2013 22:31:00 +0200 Received: (qmail invoked by alias); 09 Apr 2013 20:30:58 -0000 Received: from 199-119-118-18.i95.net (EHLO [10.0.1.136]) [199.119.118.18] by mail.gmx.net (mp029) with SMTP; 09 Apr 2013 22:30:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+AInh6yT2AzvnF4XJ0STqLs8oqSZfG/+nUEszW3s Mn6PxICOwigo90 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> Date: Tue, 9 Apr 2013 23:30:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ops-ads@tools.ietf.org" , Hannes Tschofenig , Roger Marks , "ippm@ietf.org" , "lmap@ietf.org" Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 09 Apr 2013 20:31:12 -0000 Hi Dan,=20 thanks for sending the liaison around. I read through it and I have a = few remarks.=20 It might be useful to highlight that the IETF#86 discussion was a BOF = and the purpose of the BOF is not to work out the solution but rather to = discuss whether a working group should be formed. As such, it is quite = naturual that not all design aspects have been discussed during that = meeting.=20 With regard to the questions: Question 1: "we wonder if the LMAP discussions have considered the use = of both public and private Measurement Servers Protocol work, as it is usually done in the IETF, does not imply that a = specific entity runs the server. As such, any work that comes out of a = (yet-to-be-created) LMAP working group will most likely be run by public = and privacy entities. I would in general say that there is a distinction = between the protocol aspects and the deployment aspect. Who runs a = specific service is a deployment question and not necessarily a protocol = design question.=20 "Private" in this context is a also a bit confusing because it does not = necessarily mean that private only refers to a server run by the same = entity that runs the client, particularly if the client is located on = the end device (under the control of the end user). Question 2: "=46rom our perspective, privacy is a core issue and helped = to motivate our architecture at the most basic level." Security and privacy are certainly dealt with in IETF protocols although = I have to say that the range of what an acceptable level of privacy and = security protection constitutes varies quite significantly between = different participants. Even the understanding of what privacy and = security is varies quite a lot. I am sure the IEEE in the meanwhile has = noticed that as well with their experience in WEP. There are two = documents that are worthwhile to look at to make sure that we actually = talk the same language:=20 For security have a look at RFC 3552 (see = http://tools.ietf.org/html/rfc3552) and for privacy take a look at = http://tools.ietf.org/html/draft-iab-privacy-considerations-07.=20 In Section 7 of the privacy document you can find a couple of questions = that are, of course, also applicable to the LMAP work, namely:=20 - Data Minimization - User Participation - Security - General Have a look at this document since there are not too many documents = around that give privacy guidelines for people working in a standards = developing context.=20 One of the most important parts in this work is certainly the user = participation, which typically is easier to accomplish when the = architecture allows the end user to actually give consent to the data = collection selectively and also allows the end user to revoke their = consent at any time. In general, such consent is more difficult to = provide when the functionality is provided purely network internally, = i.e., when the user does not have any new software running on their end = devices. Luckily the measurements are most meaningful when they are = truely end-to-end tests rather than testing a sub-set of the end-to-end = communication path (which had been earlier in other measurement = projects).=20 Another important point is certainly what information is collected and = provided to third parties. Anonymizing data might be a possibility but = truely anonymized data are less meaningful. A future working group will = have to certainly look at the trade-offs between the different = identifiers involved.=20 Ciao Hannes PS: I may not know enough about the IEEE but the statement "our project = is targeted directly at mobile users (independent of air interface = technology)" raised some questions for me. I believe the IEEE could best = provide their expertise when they work on radio related technology.=20 On Mar 28, 2013, at 10:17 AM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > Please note the following incoming liaison statement from IEEE Project = P802.16.3 concerning the LMAP activity.=20 >=20 > https://datatracker.ietf.org/liaison/1244/ >=20 > Comments and discussions are welcome.=20 >=20 > Regards, >=20 > Dan >=20 >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Tue Apr 9 14:15:34 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 59F5621F9935 for ; Tue, 9 Apr 2013 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 dP6ZR6W+jJ8K for ; Tue, 9 Apr 2013 14:15:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCD821F9919 for ; Tue, 9 Apr 2013 14:15:33 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C58D920BFE; Tue, 9 Apr 2013 23:15:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id INfmN_YkF-aI; Tue, 9 Apr 2013 23:15:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D4A420C48; Tue, 9 Apr 2013 23:15:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C15E258DAC1; Tue, 9 Apr 2013 23:15:34 +0200 (CEST) Date: Tue, 9 Apr 2013 23:15:34 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?B?Suly9G1l?= Benoit Message-ID: <20130409211534.GA3578@elstar.local> Mail-Followup-To: =?iso-8859-1?B?Suly9G1l?= Benoit , lmap@ietf.org References: <20130408193339.7f91eb3b@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029B560@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130409163712.50a63452@nemesis.grenouille.com> <20130409174904.1fcea33e@nemesis.grenouille.com> <20130409193342.7d7f80a0@nemesis.grenouille.com> <20130409184907.GA866@elstar.local> <20130409222424.6fb47090@nemesis.grenouille.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130409222424.6fb47090@nemesis.grenouille.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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: Tue, 09 Apr 2013 21:15:34 -0000 On Tue, Apr 09, 2013 at 10:24:24PM +0200, Jérôme Benoit wrote: > On Tue, 9 Apr 2013 20:49:07 +0200 in > <20130409184907.GA866@elstar.local>, Juergen Schoenwaelder Juergen > Schoenwaelder wrote: > > > > > So please, write an I-D discussing the privacy of measurement data > > and meta-data and how it can be protected. > > > > Can it wait for a week ? > I'm travelling right now and should be able to write only something at > the end of the next week. > There is no working group yet, there are no milestones yet, so take all the time you need. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Wed Apr 10 09:27:00 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 1570821F86C2 for ; Wed, 10 Apr 2013 09:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 iGMq0P2Meve1 for ; Wed, 10 Apr 2013 09:26:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6421F8696 for ; Wed, 10 Apr 2013 09:26:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3AGQtCW022158 for ; Wed, 10 Apr 2013 18:26:55 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3AGQS53020727; Wed, 10 Apr 2013 18:26:39 +0200 (CEST) Message-ID: <51659264.1090005@cisco.com> Date: Wed, 10 Apr 2013 18:25:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "lmap@ietf.org" References: <5165447D.3090501@cisco.com> In-Reply-To: <5165447D.3090501@cisco.com> X-Forwarded-Message-Id: <5165447D.3090501@cisco.com> Content-Type: multipart/alternative; boundary="------------040305080008050400030103" Cc: me Subject: [lmap] LMAP: situation after the BoF 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, 10 Apr 2013 16:27:00 -0000 This is a multi-part message in MIME format. --------------040305080008050400030103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear LMAP participants, Thanks again for a successful BoF, with two great chairs. Sorry for the delay in getting back to you. Here is my high level analysis of the situation. From RFC 5434: The goal of the BOF is to demonstrate that the community has agreement that: - (1) there is a problem that needs solving, and the IETF is the right group to attempt solving it. - (2) there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.). - (3) the scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what it won't) and what its actual deliverables will be. - (4) there is agreement that the specific deliverables (i.e., proposed documents) are the right set. - (5) it is believed that the WG has a reasonable probability of having success (i.e., in completing the deliverables in its charter in a timely fashion). We passed (1) and (2). For example, I'm pleased that there are operator participation in LMAP. Now, we have to finalize (3) ... before working on the charter text (4). *Question 1. Use cases* Do we agree that we want to focus on the Internet Service Provider and the End User Network Diagnostics use cases for now? As a phase 2, we could focus on the 3rd party use case: multi-provider, regulator, over the top Question: in the End User Network Diagnostics use case, I'm unclear if the user initiated measurement is included? *Question 2: IPv4/IPv6* Do we agree that we need support both IPv6 and IPv4? Note: The issue of NAT traversal complicates IPv4 *Question 3: Active and passive measurements* Do we agree that both active and passive measurements are in scope? *Question 4: Measurement Agent device type* A branch office router, a home router, a dual home router, a laptop, a tablet, a mobile device, ...? The discussion started on the list with an email sent on March 7th, with the "[lmap] Which devices does LMAP target?" subject. This needs more discussion. The requirements will be different based on the device type (ex: router versus tablet versus mobile). On my mobile, for which I pay per transmitted bytes, I don't want to pay for those measurements. This comes back to the question of voluntary based measurements or not? *Question 5: **Gaming the system* Do we agree that, from a technical point of view, there is nothing we can do to prevent gaming the system? So we're left with the assumption that people will behave. *Question 6: Liaisons* We agree not to speak about liaisons during the BoF. However, if we create this WG, then this will become an important topic. Which liaisons have we received so far, and which SDO should we liaise to? Next steps: Discuss the questions in this email on the LMAP mailing list. For clarity, one question per email thread. Then, we could start working on the charter text. In parallel, the WG could spend some time on - Security: As mentioned by Dan on the mailing list some months ago, the security requirement aspects should be expanded. Security considerations related to the protocol (control and reporting), and to the collected data (anonymization? geolocation? etc...) - Terminology: In my experience of dealing with new WGs, a necessary task on which the community spends a lot of time is the terminology definition. The sooner you start on this, the better. What is a metric, a test, a test report, a measurement agent, a controller, a metric, a report, etc... What does a test or test report include, etc... During the various discussions, I've seen some confusions between a test and a metric. Regards, Benoit (OPS AD) --------------040305080008050400030103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear LMAP participants,

Thanks again for a successful BoF, with two great chairs.
Sorry for the delay in getting back to you.
Here is my high level analysis of the situation.

From RFC 5434:
   The goal of the
   BOF is to demonstrate that the community has agreement that:

      - (1) there is a problem that needs solving, and the IETF is the right
        group to attempt solving it.

      - (2) there is a critical mass of participants willing to work on the
        problem (e.g., write drafts, review drafts, etc.).

      - (3) the scope of the problem is well defined and understood, that
        is, people generally understand what the WG will work on (and
        what it won't) and what its actual deliverables will be.

      - (4) there is agreement that the specific deliverables (i.e.,
        proposed documents) are the right set.

      - (5) it is believed that the WG has a reasonable probability of
        having success (i.e., in completing the deliverables in its
        charter in a timely fashion).
We passed (1) and (2). For example, I'm pleased that there are operator participation in LMAP.
Now, we have to finalize (3) ... before working on the charter text (4).

Question 1. Use cases
Do we agree that we want to focus on the Internet Service Provider and the End User Network Diagnostics use cases for now? As a phase 2, we could focus on the 3rd party use case: multi-provider, regulator, over the top
Question: in the End User Network Diagnostics use case, I'm unclear if the user initiated measurement is included?

Question 2: IPv4/IPv6
Do we agree that we need support both IPv6 and IPv4?
Note: The issue of NAT traversal complicates IPv4

Question 3: Active and passive measurements
Do we agree that both active and passive measurements are in scope?

Question 4: Measurement Agent device type
A branch office router, a home router, a dual home router, a laptop, a tablet, a mobile device, ...?
The discussion started on the list with an email sent on March 7th, with the "[lmap] Which devices does LMAP target?" subject. This needs more discussion.
The requirements will be different based on the device type (ex: router versus tablet versus mobile). 
On my mobile, for which I pay per transmitted bytes, I don't want to pay for those measurements. This comes back to the question of voluntary based measurements or not?

Question 5: Gaming the system
Do we agree that, from a technical point of view, there is nothing we can do to prevent gaming the system? So we're left with the assumption that people will behave.

Question 6: Liaisons
We agree not to speak about liaisons during the BoF. However, if we create this WG, then this will become an important topic. Which liaisons have we received so far, and which SDO should we liaise to?


Next steps: Discuss the questions in this email on the LMAP mailing list. For clarity, one question per email thread. Then, we could start working on the charter text.


In parallel, the WG could spend some time on
- Security: As mentioned by Dan on the mailing list some months ago, the security requirement aspects should be expanded. Security considerations related to the protocol (control and reporting), and to the collected data (anonymization? geolocation? etc...)
- Terminology: In my experience of dealing with new WGs, a necessary task on which the community spends a lot of time is the terminology definition. The sooner you start on this, the better. What is a metric, a  test, a test report, a measurement agent, a controller, a metric, a report, etc... What does a test or test report include, etc... During the various discussions, I've seen some confusions between a test and a metric.

Regards, Benoit (OPS AD)








--------------040305080008050400030103-- From jerome.benoit@grenouille.com Wed Apr 10 12:54: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 30ECF21F92CD for ; Wed, 10 Apr 2013 12:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=0.325, 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 9ztU7Bdx89sH for ; Wed, 10 Apr 2013 12:54:47 -0700 (PDT) Received: from laposte.grenouille.com (ns37873.ovh.net [91.121.8.57]) by ietfa.amsl.com (Postfix) with ESMTP id 403B921F92E8 for ; Wed, 10 Apr 2013 12:54:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.grenouille.com (Postfix) with ESMTP id 961317F5E7; Wed, 10 Apr 2013 21:54:45 +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 AS8Iqu3aAW87; Wed, 10 Apr 2013 21:54:35 +0200 (CEST) Date: Wed, 10 Apr 2013 21:54:34 +0200 From: =?iso-8859-1?B?Suly9G1l?= Benoit To: trevor.burbridge@bt.com Message-ID: <20130410195434.GA6782@nemesis.grenouille.com> References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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, 10 Apr 2013 19:54:48 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le Tue, Apr 09, 2013 at 09:37:40AM +0100, trevor.burbridge@bt.com a =E9crit: > The use cases we have require the identity of the individual and/or line.= For a regulator they need to link this to ISP and product, location, marke= t, line length, marketed speed and other attributes. This information will = not be publically available to any measurement agent. If there is a problem= with the measurement device they need to contact individuals involved. The user have the measurement agent and have the information that will permit to access the link caracteristics, it's measurement meta-data.=20 "wild" measurement agent or "wild" measurement are not a pb. They are a problem if you deliberatly choose to not include them by design.=20 > An ISP operating a measurement platform needs the line identifier to be a= ble to diagnose and resolve network problems. We don't currently have prima= ry use cases which would drive deployment of the measurement devices and wo= uld require anonymised data. If there is a secondary use (e.g. by a party w= ho does not operate the measurement framework) then the first party can app= ly anonymisation etc. ISPs operate the whole measurement system that will permit to evaluate them= selves=20 with no mechanisms that will permit to ensure the neutrality of the measurement system ... I hope you're kidding ? If not, such a measurement system where judge are also the party is just a big joke that will cost money to the people and where people will be able to participate, review, trust ... fantastic ! No ? ++ --=20 J=E9r=F4me Benoit aka fraggle La M=E9t=E9o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iEYEARECAAYFAlFlw3oACgkQ+qDLUJ/pFh33EQCg1JK7e5Mb9DWR2Gn2TQkBYiT1 xN8AnRomVc5WP8h2LGyZC/xDl26HO3P7 =3/oG -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From j.schoenwaelder@jacobs-university.de Wed Apr 10 13:36: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 1BEF121F937B for ; Wed, 10 Apr 2013 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 nRtTZXqrYuAD for ; Wed, 10 Apr 2013 13:36:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 579BA21F92EF for ; Wed, 10 Apr 2013 13:36:36 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB42F20BE3; Wed, 10 Apr 2013 22:36:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yGPVhFS4eSYf; Wed, 10 Apr 2013 22:36:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42CF020BE1; Wed, 10 Apr 2013 22:36:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1561D2590D5C; Wed, 10 Apr 2013 22:36:39 +0200 (CEST) Date: Wed, 10 Apr 2013 22:36:39 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?B?Suly9G1l?= Benoit Message-ID: <20130410203639.GA7131@elstar.local> Mail-Followup-To: =?iso-8859-1?B?Suly9G1l?= Benoit , trevor.burbridge@bt.com, lmap@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA0BB87E@AZ-FFEXMB04.global.avaya.com> <20130405142245.47a5d4d2@nemesis.grenouille.com> <2D09D61DDFA73D4C884805CC7865E6113029AA43@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130407063037.09cd9996@nemesis.grenouille.com> <20130408193339.7f91eb3b@nemesis.grenouille.com> <20130410195434.GA6782@nemesis.grenouille.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130410195434.GA6782@nemesis.grenouille.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: trevor.burbridge@bt.com, lmap@ietf.org Subject: Re: [lmap] incoming liaison statement from IEEE Project P802.16.3 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: Wed, 10 Apr 2013 20:36:37 -0000 On Wed, Apr 10, 2013 at 09:54:34PM +0200, Jérôme Benoit wrote: > > ISPs operate the whole measurement system that will permit to > evaluate themselves with no mechanisms that will permit to ensure > the neutrality of the measurement system ... I hope you're kidding ? > If not, such a measurement system where judge are also the party is > just a big joke that will cost money to the people and where people > will be able to participate, review, trust ... fantastic ! No ? There are multiple use cases with different motivations and different goals and we should not mess them up. The ISP use case has a rather detailed description: http://tools.ietf.org/html/draft-linsner-lmap-use-cases-02 Perhaps it helps if we discuss concrete parts of the text in this draft so that we can improve the document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Thu Apr 11 10:58: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 9B31F21F882A for ; Thu, 11 Apr 2013 10:58:30 -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 GL85v7LRwRxC for ; Thu, 11 Apr 2013 10:58:29 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id EB12621F890F for ; Thu, 11 Apr 2013 10:58:27 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 4c9f6615.71a9a940.211054.00-510.593258.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 11 Apr 2013 17:58:28 +0000 (UTC) X-MXL-Hash: 5166f9c466b928d0-1430611859a74515c97e7e7f801b0b30fd2b8a51 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 2c9f6615.0.211044.00-371.593200.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 11 Apr 2013 17:58:27 +0000 (UTC) X-MXL-Hash: 5166f9c31021c20c-312dfce737af6eefd7df3f851c3867a45c3ed4d6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BHwQDo000340; Thu, 11 Apr 2013 13:58:26 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BHwLLx032749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 13:58:23 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 11 Apr 2013 18:58:07 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 13:58:07 -0400 From: "STARK, BARBARA H" To: Benoit Claise , "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation:Q6-Liaisons Thread-Index: Ac423hw1gwcdOmN1SwiWBIDhn0nbBg== Date: Thu, 11 Apr 2013 17:58:06 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A3D00@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=IZ0wrxWa c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=sI65eFyke9oA:10 a=QoHQE9LVNRgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=d7lUWxnNak8A:10 a=9aHd_bYHHPsU36G7OF4A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=LvkC6_PNHwrgyAfr:21 a=WRvfdq2_IXoNrcER:21] Subject: Re: [lmap] LMAP: situation:Q6-Liaisons 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, 11 Apr 2013 17:58:31 -0000 > Question 6: Liaisons > We agree not to speak about liaisons during the BoF. However, if we creat= e this WG, then this will become an important topic. Which liaisons have we= received so far, and which SDO should we liaise to? Starting with this last question... I'm aware of liaisons from BBF and IEEE 802.16. Nothing in either of these = liaisons strikes me as being worth the time and effort of creating a respon= se. As someone who has sent a number of liaison's IETF's way in the past (from = BBF), and who wrote most of the recent BBF liaison to IETF that's related t= o the lmap topic, my personal views on liaisons in the context of IETF is t= hat for "please provide an opinion" or "FYI" topics, expecting a response l= iaison from IETF is generally unrealistic and unnecessary. It is unnecessary in the vast majority of cases because it's incredibly eas= y for the other-org-liaison-writing individuals to participate directly in = IETF discussions of that liaison. No travel necessary. They can choose to j= ust monitor the discussion, or actively drive the discussion (including dir= ectly answering questions that IETF participants may have regarding the lia= ison). I've found that being active in the IETF discussion provides by far = the best results. Since the IETF discussion is open for all to read, other-= org-participants can directly glean what they need from that discussion, an= d don't need for IETF participants to spend precious time crafting consensu= s language of a response. It's unrealistic because it's unnecessary. The openly available list discus= sion can provide the other org what they need. I consider the crafting of a= formal response to the other org to be a waste of my time (as an individua= l IETF participant), if everything they need can be gotten from the discuss= ion list. I don't like for my time to be wasted, and I don't want to waste = the time of the other IETF participants. I'm here (on this list). I know ho= w easy it is to be here -- usually. [Exception: If discussion gets hostile,= with insults and/or profanity, then it's not easy; it's also not worth it = to me to bother with the IETF in that case -- which then becomes the feedba= ck I take to the other org.] If the other org wants IETF to actively work on something, then other org (= or other org companies) needs to supply individuals in IETF to help do that= . If the other org wants comments on a something or answers to questions, the= n the other org (or other org companies) needs to supply individuals in IET= F to help guide that discussion, and who will directly monitor the comments= on the list. Anyway, that's my opinion on the topic of liaisons to/from IETF. I intend to try to get some discussion going soon around some of the questi= ons in the recent liaison from BBF. I see that as an action item for me, as= a person who wrote much of that liaison. As it relates to BBF liaisons, I,= personally, have no intention of unnecessarily wasting the time of other I= ETF participants by trying to throw a liaison over the wall at IETF and unr= ealistically expecting something meaningful to come back. I would encourage this behavior to be expected of orgs other than BBF, as w= ell. Barbara From bs7652@att.com Thu Apr 11 13:17:28 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 4704C21F86D8 for ; Thu, 11 Apr 2013 13:17:28 -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 sCrGseb96cqv for ; Thu, 11 Apr 2013 13:17:27 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 76EDA21F86B9 for ; Thu, 11 Apr 2013 13:17:27 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 75a17615.2aaae602f940.315388.00-545.883554.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 11 Apr 2013 20:17:27 +0000 (UTC) X-MXL-Hash: 51671a576c6d23c6-f0cb6fe99d29880cf489b60036713ee912ca0902 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 65a17615.0.315381.00-324.883530.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 11 Apr 2013 20:17:26 +0000 (UTC) X-MXL-Hash: 51671a565d5d2b50-0e541f055de1392899639845c883ea0ec990f08e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKHPQl020735; Thu, 11 Apr 2013 16:17:26 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKHFTJ020589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 16:17:22 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 11 Apr 2013 21:17:10 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 16:17:10 -0400 From: "STARK, BARBARA H" To: Benoit Claise , "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Q2-IPv4/6 Thread-Index: Ac428Yr1H+M8hTSqTbaARdm3naUpMQ== Date: Thu, 11 Apr 2013 20:17:09 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=GZega3rL c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=sI65eFyke9oA:10 a=qNQGxiPioDQA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=JyxaEFMyhO4A:10 a=oUBLCU7p7K9lJi0jwCIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 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, 11 Apr 2013 20:17:28 -0000 > Question 2: IPv4/IPv6 > Do we agree that we need support both IPv6 and IPv4? > Note: The issue of NAT traversal complicates IPv4 As for the measurements/tests: We should expect the lmap architecture to al= low for tests that run across both/either IP protocol version. I'm definite= ly aware of there being interest in tests run over both protocols if the en= d user's network is enabled for both. Especially tests around latency. I co= nsider lmap as mostly being about control/management/configuration of tests= , MAs, and the physical devices/elements containing these. I do not envisio= n lmap being about trying to control intermediate transport elements to ena= ble tests to run through them. If a test intended to be run over IPv4 can't= traverse a NAT, then that test has no business being run, IMO. But there a= re lots of tests that can and do traverse NAT without problem. As for the protocols that might be used by various management/control/data = collection protocols: Unless there is to be a brand new protocol, any exist= ing protocol should already have definitions for how to run it over IPv4 or= IPv6. If it doesn't, I don't envision lmap trying to solve that problem. I= 'm hoping there won't be any brand new management protocols. Barbara From bs7652@att.com Thu Apr 11 13:19: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 9740D21F8630 for ; Thu, 11 Apr 2013 13:19:02 -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 nGz0+pECoHdM for ; Thu, 11 Apr 2013 13:19:02 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7421F869A for ; Thu, 11 Apr 2013 13:19:01 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5ba17615.0.316212.00-314.885884.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 11 Apr 2013 20:19:01 +0000 (UTC) X-MXL-Hash: 51671ab5465c93fe-226e636879dba0460630d744f07d867bbba7a3d3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKJ1BL022137 for ; Thu, 11 Apr 2013 16:19:01 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKItpN022093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 16:18:55 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi133.aldc.att.com (RSA Interceptor) for ; Thu, 11 Apr 2013 21:18:33 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 16:18:33 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Q3-Passive/Active measurements Thread-Index: Ac428bycfJYM0O5WRoyVVp9j2EejEw== Date: Thu, 11 Apr 2013 20:18:32 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=GZega3rL c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=sI65eFyke9oA:10 a=RuQxb3iqqxIA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=7BvG4fMYFx8A:10 a=LEBIqWXRLsGndbSqpyEA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active 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: Thu, 11 Apr 2013 20:19:02 -0000 > Question 3: Active and passive measurements > Do we agree that both active and passive measurements are in scope? I certainly agree. If we do a BCP around privacy of end-user data, I think = it's very important to include passive measurement data in that discussion.= It may be that passive measurements aren't appropriate for data that gets = publicly shared. In which case that question should be tackled head on. But= passive measurements are absolutely ok for end users to collect inside the= ir own home network, and it's standard practice for ISP's to collect passiv= e measurements inside their network elements. Passive measurements are very= important tools where the data is not intended to be shared with others. Barbara From bs7652@att.com Thu Apr 11 13:23:17 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 2392121F8F06 for ; Thu, 11 Apr 2013 13:23:17 -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 qrXKr3cEPhDD for ; Thu, 11 Apr 2013 13:23:16 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31221F8F4E for ; Thu, 11 Apr 2013 13:23:16 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1bb17615.0.289214.00-367.814135.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 11 Apr 2013 20:23:16 +0000 (UTC) X-MXL-Hash: 51671bb44a9d1159-8dd60e72c32ddd46ba2db6a4209cd588eb4c9ee1 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKNDwC025486 for ; Thu, 11 Apr 2013 16:23:13 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BKN5Tc025371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 16:23:10 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor) for ; Thu, 11 Apr 2013 21:22:56 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 16:22:56 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/Ww== Date: Thu, 11 Apr 2013 20:22:55 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=IZ0wrxWa c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=sI65eFyke9oA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=x4slEs57N2oes9pt9fcA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=VaY-UkBMh9mAxvL6:21 a=jAV8dn4FDCwI8ejU:21] Subject: Re: [lmap] LMAP: situation: Q1-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: Thu, 11 Apr 2013 20:23:17 -0000 > Question 1. Use cases > Do we agree that we want to focus on the Internet Service Provider and th= e End User Network Diagnostics use cases for now? As a phase 2, we could fo= cus on the 3rd party use case: multi-provider, regulator, over the top > Question: in the End User Network Diagnostics use case, I'm unclear if th= e user initiated measurement is included? Here is my opinion on what I would suggest considering as in scope: 1.a) The Access Provider / ISP use case relative to collecting metrics for = ensuring the health of their own network. (or what is recommended for an IS= P in the context of their internal measurement collection needs) 1.b) The Access Provider / ISP use case relative to meeting potential regul= atory requests. (or what is recommended for an ISP who wants to support mea= surement collection for regulatory consumption). Note that this may involve= recommendations for how an ISP provides service attributes to an end-user-= network-located MA not under the ISP's control, or how an ISP provides othe= r entities with access to the ISP's test endpoints, or how the ISP's end-us= er-network-located MAs may interact with test endpoints provided by others.= I see some limited set of inter-domain discussion as being relevant to thi= s usage. For this usage, I'd like to discuss the full set of scenarios for = supporting regulatory requests where *something* is requested of the ISP. N= ot just the case where the ISP supplies the MA and tests against endpoints = in the ISP network. 1.c) The Access Provider / ISP use case relative to supporting the end use= r's diagnostics needs (or what is recommended for an ISP who wants to provi= de an end user with tools for helping with end user network diagnostics). A= s with 1.b), I see this as not just being about the case where the ISP supp= lies the MA and test endpoints, but also about supporting inter-domain meas= urements between end-user- or 3rd-party-managed and ISP-managed devices, as= well as potentially supplying the end user with service attribute informat= ion. I think this usage should include user-initiated measurements. Note that in the inter-domain interactions I mention above, I'm only sugges= ting inter-domain running of measurements and unidirectional providing of s= ervice attributes to a device inside the end user's network. These inter-do= main interactions do not involve inter-domain management, control, or confi= guration -- which I would prefer to avoid. It sounds like there may be additional interest in providing recommendation= s for end-user-controlled MAs that have the ability to send collected data = to non-end-user-controlled Data Collectors. It may or may not be possible f= or the end user to specify the Data Collector? [Or perhaps the recommendati= ons would only apply to an MA that does allow the end user to specify the D= ata Collector?] I'm a bit fuzzy on this one. It may instead be useful to ju= st create a generic BCP for an MA that sends data to a Data Collector under= someone else's control. Or even more generically, a BCP about which data e= lements may be considered end-user-identifiable/private info for considerat= ion when one entity (e.g., the end user, or the ISP) supplies collected dat= a to another entity (inter-domain data transfer). It might be useful if suc= h a BCP included discussion as to how the release of that information to ot= hers could be used to invade an end user's privacy, to better understand wh= y the information is recommended to be private. While I have seen statements proclaiming the value of 3rd party measurement= systems (and, BTW, I agree that such systems are valuable) I don't recall = having seen requests for helping to architect such systems. People who have= put such systems together seem to be quite happy with their systems. Howev= er, they may benefit from ippm recommendations and efforts. They may also b= enefit from mappings of ippm registry elements into certain IETF protocol m= odels (such as SNMP MIBs, netconf data model, or ipfix data model). They ma= y benefit from something that allows the ISP to provide Servcie Attributes = to MAs inside the end user network. And they may benefit from privacy recom= mendations. Given the above scope, I could envision potentially having the following de= liverables: 1. ISP lmap Architecture that includes (1) intra-domain interfaces between = an MA and other MAs (test endpoints) and operational support systems that m= anage/control/configure those MAs and the physical devices/elements that co= ntain the MA, and (2) inter-domain interfaces for (a) requesting resources = on ISP test endpoints, (b) ISP MA requesting resources on others' test endp= oints, and (c) ISP providing service attribute info to an MA inside an end = user's network. 2. Mechanism for intra- and inter-domain requesting of test endpoint resour= ces 3. Mechanism for providing service attribute info 4. BCP on end-user identifiable data elements with discussion of threats to= privacy and recommendations for maintaining privacy 5. Data models / MIBs for various IETF protocols, based on the ippm registr= y. Personally, I would be willing to participate in and contribute to 1-4 abov= e. I have no objection to 5, and think it would probably be useful to those= who use such protocols. Barbara From trammell@tik.ee.ethz.ch Thu Apr 11 14:46: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 ACC6A21F87D5 for ; Thu, 11 Apr 2013 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fSs1yBSfOznU for ; Thu, 11 Apr 2013 14:46:43 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 08CA021F86C3 for ; Thu, 11 Apr 2013 14:46:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2DF52D930B; Thu, 11 Apr 2013 23:46:42 +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 Z2Nvh4TJDT-Y; Thu, 11 Apr 2013 23:46:41 +0200 (MEST) Received: from wifi-172-24-50-56.uoa-wifi.auckland.ac.nz (wireless-nat-2.auckland.ac.nz [130.216.30.113]) (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 8FB49D930A; Thu, 11 Apr 2013 23:46:40 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 12 Apr 2013 09:46:36 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch> References: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 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, 11 Apr 2013 21:46:43 -0000 Hi, Barbara, all, +1. Indeed, as various messy NAT-for-transition setups see wider = deployment, some tests may involve the testing of connectivity and = application-layer response time to various points in the v4 and v6 = Internet from both v4 and v6 local addresses. The parameters for these = tests will therefore be (1) necessarily complicated by the NAT they're = trying to measure and (2) necessarily involve the specification of both = address families. Best regards, Brian On 12 Apr 2013, at 8:17, "STARK, BARBARA H" wrote: >> Question 2: IPv4/IPv6 >> Do we agree that we need support both IPv6 and IPv4? >> Note: The issue of NAT traversal complicates IPv4 >=20 > As for the measurements/tests: We should expect the lmap architecture = to allow for tests that run across both/either IP protocol version. I'm = definitely aware of there being interest in tests run over both = protocols if the end user's network is enabled for both. Especially = tests around latency. I consider lmap as mostly being about = control/management/configuration of tests, MAs, and the physical = devices/elements containing these. I do not envision lmap being about = trying to control intermediate transport elements to enable tests to run = through them. If a test intended to be run over IPv4 can't traverse a = NAT, then that test has no business being run, IMO. But there are lots = of tests that can and do traverse NAT without problem. >=20 > As for the protocols that might be used by various = management/control/data collection protocols: Unless there is to be a = brand new protocol, any existing protocol should already have = definitions for how to run it over IPv4 or IPv6. If it doesn't, I don't = envision lmap trying to solve that problem. I'm hoping there won't be = any brand new management protocols. > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Thu Apr 11 14:47: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 614D321F855F for ; Thu, 11 Apr 2013 14:47:24 -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=[AWL=0.000, 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 xFloRvduaq77 for ; Thu, 11 Apr 2013 14:47:23 -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 9C5CC21F855C for ; Thu, 11 Apr 2013 14:47:22 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 6C1AF1209D5 for ; Thu, 11 Apr 2013 17:47:40 -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 65661E3AE5; Thu, 11 Apr 2013 17:38:49 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 11 Apr 2013 17:47:22 -0400 From: "MORTON JR., ALFRED C (AL)" To: "STARK, BARBARA H" , "lmap@ietf.org" Date: Thu, 11 Apr 2013 17:47:20 -0400 Thread-Topic: [lmap] LMAP: situation: Q3-Passive/Active measurements Thread-Index: Ac428bycfJYM0O5WRoyVVp9j2EejEwAByVkg Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active 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: Thu, 11 Apr 2013 21:47:24 -0000 Barbara's response leads to another point stemming from discussion earlier this week: "neutrality" of measurements. Subscribers already trust their ISPs with the unencrypted contents of their packets, and an ISP would have few subscribers if it gave private information away. A similar code of conduct extends to measurements and published results, and the potential to loose subscribers for ethical transgressions is=20 equally great. Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > STARK, BARBARA H > Sent: Thursday, April 11, 2013 4:19 PM > To: lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements >=20 > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information= . >=20 > > Question 3: Active and passive measurements > > Do we agree that both active and passive measurements are in scope? >=20 > I certainly agree. If we do a BCP around privacy of end-user data, I thin= k > it's very important to include passive measurement data in that > discussion. It may be that passive measurements aren't appropriate for > data that gets publicly shared. In which case that question should be > tackled head on. But passive measurements are absolutely ok for end users > to collect inside their own home network, and it's standard practice for > ISP's to collect passive measurements inside their network elements. > Passive measurements are very important tools where the data is not > intended to be shared with others. > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Thu Apr 11 14:51: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 983B821F871C for ; Thu, 11 Apr 2013 14:51:08 -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 KTXGvSf73zPJ for ; Thu, 11 Apr 2013 14:51:08 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id AEE4421F859B for ; Thu, 11 Apr 2013 14:51:07 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b4037615.0.340435.00-370.956952.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 11 Apr 2013 21:51:07 +0000 (UTC) X-MXL-Hash: 5167304b6f4b5f7f-8a85bd6ccbdf4179d3d58242073fe3d17d8d1368 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BLp763004028 for ; Thu, 11 Apr 2013 17:51:07 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3BLp1uR003987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 17:51:01 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 11 Apr 2013 22:50:42 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Thu, 11 Apr 2013 17:50:41 -0400 From: "STARK, BARBARA H" To: "lmap@ietf.org" Thread-Topic: [lmap] LMAP: situation: Q5-Gaming the system Thread-Index: Ac42/pwAT+Ce3sOSSoaw+MRXukMaeA== Date: Thu, 11 Apr 2013 21:50:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A3E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.31.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=LdKLHEji c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=sI65eFyke9oA:10 a=DO2g4GJtzoMA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SkJVqnjb8FgA:10 a=hU0b6IfWkx6XDLzRPh8A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=c7uT_H-nuQixX8pF:21 a=P6tjuSP9Bk8nqqQq:21] Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system 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, 11 Apr 2013 21:51:08 -0000 > Question 5: Gaming the system > Do we agree that, from a technical point of view, there is nothing we can= do to prevent gaming the system? So we're left with the assumption that pe= ople will behave. I do not believe there is nothing we can do. I just think there are infinit= e ways to game the system and none of them are worth spending my time on. I= believe that the costs of defining and deploying technical solutions to pr= event gaming are greater than the risks/costs of doing nothing. In my prior= ity list of things to do and ways to spend my time, I just don't see a lot = of value in spending time on that topic. I would characterize gaming as intentionally (and perhaps maliciously) inse= rting inaccuracy into the overall system or process. There are many, many w= ays to accomplish this in the context of lmap: an ISP could apply QoS to te= st traffic; an ISP could manipulate collected data prior to providing it to= others; a 3rd party could manipulate collected data prior to providing it = to others (to try to make an ISP look bad/good); a 3rd party could program = their MA to manipulate data before sending it to the data collector; an ISP= could provide inaccurate service attributes to use for comparison; a 3rd p= arty could program all MAs to run measurements at the same time against an = ISP measurement endpoint in an attempt to degrade performance of all tests = against that endpoint; the end user hacks the MA to make it report bad perf= ormance data (because they hate their ISP); etc.=20 But to decide to spend effort guarding against any particular way to game t= he system, I believe that the incentive for doing that particular method of= gaming must outweigh the probability of getting caught together with the c= osts of getting caught. For me, I don't perceive any of the ways of gaming = as providing a sufficiently high incentive. At least not at this time. A la= rge part of why I believe this is that (1) I'm not aware of any evidence of= gaming occurring, and (2) there doesn't seem to have been massive negative= /positive repercussions (lots of ISP switching, massive consumer outcry upo= n viewing results, fines for perceived poor performance, etc.) from broadba= nd measurements conducted to date. If there were greater incentive to some = party (e.g., "we'll offer free service for 10 years to the person who has c= urrent service from our competitor and will apply this hack to the MA in th= eir home, to make our competitor look bad"), then I think it would be time = to consider addressing that way of gaming. Of course, it's also possible to inadvertently (not intentionally and not m= aliciously) insert inaccuracy. There has been evidence of that. For example= , some users took their 3rd party MA over to a friend or relative's house t= o let it run measurements, not realizing that the MA had been associated (s= ervice attributes) with the broadband service of the original person. If th= e original person had a 20Mbps service, and the friend had a 6Mbps service,= then the result interpretation would show that the measurement service was= performing very poorly against the 20Mpbs benchmark. Because there is evid= ence of this problem, there are people asking for solutions to this problem= (how to better associate the service attributes with the MA and the measur= ed data). Inaccuracy has also been introduced by misinterpreting measuremen= t data. Some of this misinterpretation can be fixed by better characterizat= ion of service attributes, and some can be dealt with by doing different te= sts which can be interpreted in the desired way (which is why there's some = focus on figuring out the "right" tests to do). In other words, methods for= inserting inaccuracies that are known to occur are higher priority to solv= e technically than inaccuracy insertion methods for which there is no evide= nce (and low incentive). Barbara From trammell@tik.ee.ethz.ch Thu Apr 11 14:54: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 30C4721F871C for ; Thu, 11 Apr 2013 14:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QKe+xtHe+4JP for ; Thu, 11 Apr 2013 14:53:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 2E00821F86F7 for ; Thu, 11 Apr 2013 14:53:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0CC9BD930B; Thu, 11 Apr 2013 23:53:55 +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 FXt7K9T0exem; Thu, 11 Apr 2013 23:53:54 +0200 (MEST) Received: from wifi-172-24-50-56.uoa-wifi.auckland.ac.nz (wireless-nat-2.auckland.ac.nz [130.216.30.113]) (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 89001D930A; Thu, 11 Apr 2013 23:53:53 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: Date: Fri, 12 Apr 2013 09:53:49 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D65E908-932A-405E-85FB-9641B17FE4AE@tik.ee.ethz.ch> References: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "MORTON JR., ALFRED C (AL)" X-Mailer: Apple Mail (2.1503) Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active 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: Thu, 11 Apr 2013 21:54:02 -0000 hi, Al, Barbara, all, +1 on all points in this thread. Both passive and active measurements = are clearly in scope. I think one thing that this discussion (and the thread preceding if = following from the IEEE "public"/"private" terminological confusion) = indicates is that a statement on end-user privacy may be in scope, as = well, if only to state in initial documents that certain measurements = must not be published. Best regards,=20 Brian On 12 Apr 2013, at 9:47, "MORTON JR., ALFRED C (AL)" = wrote: > Barbara's response leads to another point stemming from discussion > earlier this week: "neutrality" of measurements. Subscribers already > trust their ISPs with the unencrypted contents of their packets, and > an ISP would have few subscribers if it gave private information away. > A similar code of conduct extends to measurements and published = results, > and the potential to loose subscribers for ethical transgressions is=20= > equally great. >=20 > Al >=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> STARK, BARBARA H >> Sent: Thursday, April 11, 2013 4:19 PM >> To: lmap@ietf.org >> Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements >>=20 >> *** Security Advisory: This Message Originated Outside of AT&T ***. >> Reference http://cso.att.com/EmailSecurity/IDSP.html for more = information. >>=20 >>> Question 3: Active and passive measurements >>> Do we agree that both active and passive measurements are in scope? >>=20 >> I certainly agree. If we do a BCP around privacy of end-user data, I = think >> it's very important to include passive measurement data in that >> discussion. It may be that passive measurements aren't appropriate = for >> data that gets publicly shared. In which case that question should be >> tackled head on. But passive measurements are absolutely ok for end = users >> to collect inside their own home network, and it's standard practice = for >> ISP's to collect passive measurements inside their network elements. >> Passive measurements are very important tools where the data is not >> intended to be shared with others. >> Barbara >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Thu Apr 11 17:01: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 8420D21F88DB for ; Thu, 11 Apr 2013 17:01:31 -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=[AWL=0.000, 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 P5EKtRoD9ht1 for ; Thu, 11 Apr 2013 17:01:30 -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 503EC21F87D5 for ; Thu, 11 Apr 2013 17:01:30 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 511E71209BC; Thu, 11 Apr 2013 20:01:48 -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 DB74BE373A; Thu, 11 Apr 2013 19:52:56 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 11 Apr 2013 20:01:29 -0400 From: "MORTON JR., ALFRED C (AL)" To: Brian Trammell , "STARK, BARBARA H" Date: Thu, 11 Apr 2013 20:01:28 -0400 Thread-Topic: [lmap] LMAP: situation: Q2-IPv4/6 Thread-Index: Ac42/hYTYGE5mTBtRmmv2sy6n4nKogADuOOg Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch> In-Reply-To: <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Benoit Claise , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 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, 12 Apr 2013 00:01:31 -0000 Some of the complexity brought to a network near you by NAT has been embraced in the reference path draft, and this is=20 one of the areas we expanded in the 01 version: http://tools.ietf.org/html/draft-morton-ippm-lmap-path-01 Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Thursday, April 11, 2013 5:47 PM > To: STARK, BARBARA H > Cc: Benoit Claise; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 >=20 > Hi, Barbara, all, >=20 > +1. Indeed, as various messy NAT-for-transition setups see wider > deployment, some tests may involve the testing of connectivity and > application-layer response time to various points in the v4 and v6 > Internet from both v4 and v6 local addresses. The parameters for these > tests will therefore be (1) necessarily complicated by the NAT they're > trying to measure and (2) necessarily involve the specification of both > address families. >=20 > Best regards, >=20 > Brian >=20 > On 12 Apr 2013, at 8:17, "STARK, BARBARA H" wrote: >=20 > >> Question 2: IPv4/IPv6 > >> Do we agree that we need support both IPv6 and IPv4? > >> Note: The issue of NAT traversal complicates IPv4 > > > > As for the measurements/tests: We should expect the lmap architecture t= o > allow for tests that run across both/either IP protocol version. I'm > definitely aware of there being interest in tests run over both protocols > if the end user's network is enabled for both. Especially tests around > latency. I consider lmap as mostly being about > control/management/configuration of tests, MAs, and the physical > devices/elements containing these. I do not envision lmap being about > trying to control intermediate transport elements to enable tests to run > through them. If a test intended to be run over IPv4 can't traverse a NAT= , > then that test has no business being run, IMO. But there are lots of test= s > that can and do traverse NAT without problem. > > > > As for the protocols that might be used by various > management/control/data collection protocols: Unless there is to be a > brand new protocol, any existing protocol should already have definitions > for how to run it over IPv4 or IPv6. If it doesn't, I don't envision lmap > trying to solve that problem. I'm hoping there won't be any brand new > management protocols. > > Barbara > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Fri Apr 12 01:21: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 D293021F85EB for ; Fri, 12 Apr 2013 01:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zwKw318jBxBS for ; Fri, 12 Apr 2013 01:21:28 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5221F8733 for ; Fri, 12 Apr 2013 01:21:27 -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.297.1; Fri, 12 Apr 2013 09:21:21 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 12 Apr 2013 09:19:43 +0100 From: To: Date: Fri, 12 Apr 2013 09:17:22 +0100 Thread-Topic: New Version Notification for draft-eardley-lmap-terminology-00.txt Thread-Index: Ac43VfWbjNV5Ti2wT5Wy/hlRvELpjAAADLGD Message-ID: <9510D26531EF184D9017DF24659BB87F3456559C83@EMV65-UKRD.domain1.systemhost.net> References: <20130412081553.28582.99058.idtracker@ietfa.amsl.com> In-Reply-To: <20130412081553.28582.99058.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] FW: New Version Notification for draft-eardley-lmap-terminology-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: Fri, 12 Apr 2013 08:21:29 -0000 Hi, we just submitted an I-D which tries to define some lmap terminology - prop= osals for discussion http://tools.ietf.org/html/draft-eardley-lmap-terminology best wishes phil ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: 12 April 2013 09:15 To: Eardley,PL,Philip,TUB8 R Cc: marcelo@it.uc3m.es; Eardley,PL,Philip,TUB8 R; Burbridge,T,Trevor,TUB8 R= ; acmorton@att.com Subject: New Version Notification for draft-eardley-lmap-terminology-00.txt A new version of I-D, draft-eardley-lmap-terminology-00.txt has been successfully submitted by Philip Eardley and posted to the IETF repository. Filename: draft-eardley-lmap-terminology Revision: 00 Title: Terminology for Large-Scale Measurement of Broadband Perfo= rmance (LMAP) Platforms Creation date: 2013-04-12 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-eardley-lmap-ter= minology-00.txt Status: http://datatracker.ietf.org/doc/draft-eardley-lmap-termino= logy Htmlized: http://tools.ietf.org/html/draft-eardley-lmap-terminology-= 00 Abstract: This documents defines terminology for Large Scale Measurement Platforms. The IETF Secretariat= From philip.eardley@bt.com Fri Apr 12 06:06:18 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 86DBF21F8842 for ; Fri, 12 Apr 2013 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 lIlIyvEmNIye for ; Fri, 12 Apr 2013 06:06:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50C21F875A for ; Fri, 12 Apr 2013 06:06:17 -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.297.1; Fri, 12 Apr 2013 14:06:16 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 12 Apr 2013 14:06:16 +0100 From: To: , , Date: Fri, 12 Apr 2013 14:02:21 +0100 Thread-Topic: [lmap] LMAP: situation:Q6-Liaisons Thread-Index: Ac423hw1gwcdOmN1SwiWBIDhn0nbBgAn9tFf Message-ID: <9510D26531EF184D9017DF24659BB87F3456559C91@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3D00@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3D00@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP: situation:Q6-Liaisons 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, 12 Apr 2013 13:06:18 -0000 agree that it's best if individuals involved in BBF & IEEE are prepared to = join the lmap discussions. i know that's happening with BBF people, great. i'm not sure whether IEEE people are involved? from a politeness perspective, do BBF &/or IEEE expect a reply? not sure wh= at the normal process is. if they're happy not to get a reply then i'm happ= y if we don't! best wishes phil ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of STARK, BAR= BARA H [bs7652@att.com] Sent: 11 April 2013 18:58 To: Benoit Claise; lmap@ietf.org Subject: Re: [lmap] LMAP: situation:Q6-Liaisons > Question 6: Liaisons > We agree not to speak about liaisons during the BoF. However, if we creat= e this WG, then this will become an important topic. Which liaisons have we= received so far, and which SDO should we liaise to? Starting with this last question... I'm aware of liaisons from BBF and IEEE 802.16. Nothing in either of these = liaisons strikes me as being worth the time and effort of creating a respon= se. As someone who has sent a number of liaison's IETF's way in the past (from = BBF), and who wrote most of the recent BBF liaison to IETF that's related t= o the lmap topic, my personal views on liaisons in the context of IETF is t= hat for "please provide an opinion" or "FYI" topics, expecting a response l= iaison from IETF is generally unrealistic and unnecessary. It is unnecessary in the vast majority of cases because it's incredibly eas= y for the other-org-liaison-writing individuals to participate directly in = IETF discussions of that liaison. No travel necessary. They can choose to j= ust monitor the discussion, or actively drive the discussion (including dir= ectly answering questions that IETF participants may have regarding the lia= ison). I've found that being active in the IETF discussion provides by far = the best results. Since the IETF discussion is open for all to read, other-= org-participants can directly glean what they need from that discussion, an= d don't need for IETF participants to spend precious time crafting consensu= s language of a response. It's unrealistic because it's unnecessary. The openly available list discus= sion can provide the other org what they need. I consider the crafting of a= formal response to the other org to be a waste of my time (as an individua= l IETF participant), if everything they need can be gotten from the discuss= ion list. I don't like for my time to be wasted, and I don't want to waste = the time of the other IETF participants. I'm here (on this list). I know ho= w easy it is to be here -- usually. [Exception: If discussion gets hostile,= with insults and/or profanity, then it's not easy; it's also not worth it = to me to bother with the IETF in that case -- which then becomes the feedba= ck I take to the other org.] If the other org wants IETF to actively work on something, then other org (= or other org companies) needs to supply individuals in IETF to help do that= . If the other org wants comments on a something or answers to questions, the= n the other org (or other org companies) needs to supply individuals in IET= F to help guide that discussion, and who will directly monitor the comments= on the list. Anyway, that's my opinion on the topic of liaisons to/from IETF. I intend to try to get some discussion going soon around some of the questi= ons in the recent liaison from BBF. I see that as an action item for me, as= a person who wrote much of that liaison. As it relates to BBF liaisons, I,= personally, have no intention of unnecessarily wasting the time of other I= ETF participants by trying to throw a liaison over the wall at IETF and unr= ealistically expecting something meaningful to come back. I would encourage this behavior to be expected of orgs other than BBF, as w= ell. Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From philip.eardley@bt.com Fri Apr 12 06:14: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 92AA621F86E6 for ; Fri, 12 Apr 2013 06:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 6t24M2If5sKe for ; Fri, 12 Apr 2013 06:14:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6022121F86AE for ; Fri, 12 Apr 2013 06:14:40 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 12 Apr 2013 14:14:39 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Fri, 12 Apr 2013 14:14:39 +0100 From: To: , , Date: Fri, 12 Apr 2013 14:14:39 +0100 Thread-Topic: [lmap] LMAP: situation: Q2-IPv4/6 Thread-Index: Ac42/hYTYGE5mTBtRmmv2sy6n4nKogADuOOgABxxa60= Message-ID: <9510D26531EF184D9017DF24659BB87F3456559C92@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bclaise@cisco.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 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, 12 Apr 2013 13:14:48 -0000 agree with the comments as regards teh control protocol, the measurement agent may be behind a NAT = (or even two? for MA on CPE inside the home network).=20 so the control protocol needs to cope with this - which might partly involv= e an initialisation function ('Management Server' in the Broadband forum's = liaison) that tells the MA where a collector is. in my mind it's an open qu= estion whetehr lmap defines an initialisation function or leaves this to BB= F. ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of MORTON JR.= , ALFRED C (AL) [acmorton@att.com] Sent: 12 April 2013 01:01 To: Brian Trammell; STARK, BARBARA H Cc: Benoit Claise; lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 Some of the complexity brought to a network near you by NAT has been embraced in the reference path draft, and this is one of the areas we expanded in the 01 version: http://tools.ietf.org/html/draft-morton-ippm-lmap-path-01 Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Thursday, April 11, 2013 5:47 PM > To: STARK, BARBARA H > Cc: Benoit Claise; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 > > Hi, Barbara, all, > > +1. Indeed, as various messy NAT-for-transition setups see wider > deployment, some tests may involve the testing of connectivity and > application-layer response time to various points in the v4 and v6 > Internet from both v4 and v6 local addresses. The parameters for these > tests will therefore be (1) necessarily complicated by the NAT they're > trying to measure and (2) necessarily involve the specification of both > address families. > > Best regards, > > Brian > > On 12 Apr 2013, at 8:17, "STARK, BARBARA H" wrote: > > >> Question 2: IPv4/IPv6 > >> Do we agree that we need support both IPv6 and IPv4? > >> Note: The issue of NAT traversal complicates IPv4 > > > > As for the measurements/tests: We should expect the lmap architecture t= o > allow for tests that run across both/either IP protocol version. I'm > definitely aware of there being interest in tests run over both protocols > if the end user's network is enabled for both. Especially tests around > latency. I consider lmap as mostly being about > control/management/configuration of tests, MAs, and the physical > devices/elements containing these. I do not envision lmap being about > trying to control intermediate transport elements to enable tests to run > through them. If a test intended to be run over IPv4 can't traverse a NAT= , > then that test has no business being run, IMO. But there are lots of test= s > that can and do traverse NAT without problem. > > > > As for the protocols that might be used by various > management/control/data collection protocols: Unless there is to be a > brand new protocol, any existing protocol should already have definitions > for how to run it over IPv4 or IPv6. If it doesn't, I don't envision lmap > trying to solve that problem. I'm hoping there won't be any brand new > management protocols. > > Barbara > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From philip.eardley@bt.com Fri Apr 12 06:20:52 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 CB0EA21F8A7E for ; Fri, 12 Apr 2013 06:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 9Xz8hlGFrdfe for ; Fri, 12 Apr 2013 06:20:52 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id A866521F8696 for ; Fri, 12 Apr 2013 06:20:51 -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.297.1; Fri, 12 Apr 2013 14:20:50 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 12 Apr 2013 14:20:50 +0100 From: To: , Date: Fri, 12 Apr 2013 14:16:25 +0100 Thread-Topic: [lmap] LMAP: situation: Q3-Passive/Active measurements Thread-Index: Ac42/xnptLM/mlx9RvKZDc4dN/3hIgAgNUou Message-ID: <9510D26531EF184D9017DF24659BB87F3456559C93@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> , <1D65E908-932A-405E-85FB-9641B17FE4AE@tik.ee.ethz.ch> In-Reply-To: <1D65E908-932A-405E-85FB-9641B17FE4AE@tik.ee.ethz.ch> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active 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, 12 Apr 2013 13:20:53 -0000 agree with all this. analysis of privacy would be worthwhile i think. active measurements also r= aise privacy concerns - and the report may do as well if it includes info b= eyond just the measurement results (eg about the subscriber) am quite interested in helping to study privacy issues ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of Brian Tram= mell [trammell@tik.ee.ethz.ch] Sent: 11 April 2013 22:53 To: MORTON JR., ALFRED C (AL) Cc: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements hi, Al, Barbara, all, +1 on all points in this thread. Both passive and active measurements are c= learly in scope. I think one thing that this discussion (and the thread preceding if followi= ng from the IEEE "public"/"private" terminological confusion) indicates is = that a statement on end-user privacy may be in scope, as well, if only to s= tate in initial documents that certain measurements must not be published. Best regards, Brian On 12 Apr 2013, at 9:47, "MORTON JR., ALFRED C (AL)" wro= te: > Barbara's response leads to another point stemming from discussion > earlier this week: "neutrality" of measurements. Subscribers already > trust their ISPs with the unencrypted contents of their packets, and > an ISP would have few subscribers if it gave private information away. > A similar code of conduct extends to measurements and published results, > and the potential to loose subscribers for ethical transgressions is > equally great. > > Al > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >> STARK, BARBARA H >> Sent: Thursday, April 11, 2013 4:19 PM >> To: lmap@ietf.org >> Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements >> >> *** Security Advisory: This Message Originated Outside of AT&T ***. >> Reference http://cso.att.com/EmailSecurity/IDSP.html for more informatio= n. >> >>> Question 3: Active and passive measurements >>> Do we agree that both active and passive measurements are in scope? >> >> I certainly agree. If we do a BCP around privacy of end-user data, I thi= nk >> it's very important to include passive measurement data in that >> discussion. It may be that passive measurements aren't appropriate for >> data that gets publicly shared. In which case that question should be >> tackled head on. But passive measurements are absolutely ok for end user= s >> to collect inside their own home network, and it's standard practice for >> ISP's to collect passive measurements inside their network elements. >> Passive measurements are very important tools where the data is not >> intended to be shared with others. >> Barbara >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From philip.eardley@bt.com Fri Apr 12 06:38: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 2212921F8721 for ; Fri, 12 Apr 2013 06:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Jby8KPJsbJHd for ; Fri, 12 Apr 2013 06:38:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 11DA421F86B7 for ; Fri, 12 Apr 2013 06:38:12 -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.279.1; Fri, 12 Apr 2013 14:38:10 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 12 Apr 2013 14:38:10 +0100 From: To: , Date: Fri, 12 Apr 2013 14:38:11 +0100 Thread-Topic: [lmap] LMAP: situation: Q5-Gaming the system Thread-Index: Ac42/pwAT+Ce3sOSSoaw+MRXukMaeAAg2mhp Message-ID: <9510D26531EF184D9017DF24659BB87F3456559C94@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system 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, 12 Apr 2013 13:38:13 -0000 agree with Barbara's analysis. any party in-line can manipulate traffic =3D the ISP and end user, and som= etimes other parties. it seems to me that it's impossible to prevent the de= termined gamer doing this. one could devise tests to try and spot that some= party was trying to game the system - i don't have the expertise to do tha= t - would be interesting to see tests /results from others, but I don't th= ink it's a job for the WG. best wishes phil ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of STARK, BAR= BARA H [bs7652@att.com] Sent: 11 April 2013 22:50 To: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system > Question 5: Gaming the system > Do we agree that, from a technical point of view, there is nothing we can= do to prevent gaming the system? So we're left with the assumption that pe= ople will behave. I do not believe there is nothing we can do. I just think there are infinit= e ways to game the system and none of them are worth spending my time on. I= believe that the costs of defining and deploying technical solutions to pr= event gaming are greater than the risks/costs of doing nothing. In my prior= ity list of things to do and ways to spend my time, I just don't see a lot = of value in spending time on that topic. I would characterize gaming as intentionally (and perhaps maliciously) inse= rting inaccuracy into the overall system or process. There are many, many w= ays to accomplish this in the context of lmap: an ISP could apply QoS to te= st traffic; an ISP could manipulate collected data prior to providing it to= others; a 3rd party could manipulate collected data prior to providing it = to others (to try to make an ISP look bad/good); a 3rd party could program = their MA to manipulate data before sending it to the data collector; an ISP= could provide inaccurate service attributes to use for comparison; a 3rd p= arty could program all MAs to run measurements at the same time against an = ISP measurement endpoint in an attempt to degrade performance of all tests = against that endpoint; the end user hacks the MA to make it report bad perf= ormance data (because they hate their ISP); etc. But to decide to spend effort guarding against any particular way to game t= he system, I believe that the incentive for doing that particular method of= gaming must outweigh the probability of getting caught together with the c= osts of getting caught. For me, I don't perceive any of the ways of gaming = as providing a sufficiently high incentive. At least not at this time. A la= rge part of why I believe this is that (1) I'm not aware of any evidence of= gaming occurring, and (2) there doesn't seem to have been massive negative= /positive repercussions (lots of ISP switching, massive consumer outcry upo= n viewing results, fines for perceived poor performance, etc.) from broadba= nd measurements conducted to date. If there were greater incentive to some = party (e.g., "we'll offer free service for 10 years to the person who has c= urrent service from our competitor and will apply this hack to the MA in th= eir home, to make our competitor look bad"), then I think it would be time = to consider add ressing that way of gaming. Of course, it's also possible to inadvertently (not intentionally and not m= aliciously) insert inaccuracy. There has been evidence of that. For example= , some users took their 3rd party MA over to a friend or relative's house t= o let it run measurements, not realizing that the MA had been associated (s= ervice attributes) with the broadband service of the original person. If th= e original person had a 20Mbps service, and the friend had a 6Mbps service,= then the result interpretation would show that the measurement service was= performing very poorly against the 20Mpbs benchmark. Because there is evid= ence of this problem, there are people asking for solutions to this problem= (how to better associate the service attributes with the MA and the measur= ed data). Inaccuracy has also been introduced by misinterpreting measuremen= t data. Some of this misinterpretation can be fixed by better characterizat= ion of service attributes, and some can be dealt with by doing different te= sts which can b e interpreted in the desired way (which is why there's some focus on figur= ing out the "right" tests to do). In other words, methods for inserting ina= ccuracies that are known to occur are higher priority to solve technically = than inaccuracy insertion methods for which there is no evidence (and low i= ncentive). Barbara _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From j.schoenwaelder@jacobs-university.de Fri Apr 12 07:59:18 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 8DEE321F8B2B for ; Fri, 12 Apr 2013 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=0.250, 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 2lUbsWaQbBDQ for ; Fri, 12 Apr 2013 07:59:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BC79121F8B07 for ; Fri, 12 Apr 2013 07:59:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FDE620C00; Fri, 12 Apr 2013 16:59:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KKniz8lhHv_k; Fri, 12 Apr 2013 16:59:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0646520BFE; Fri, 12 Apr 2013 16:59:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 42B16259E1BB; Fri, 12 Apr 2013 16:59:22 +0200 (CEST) Date: Fri, 12 Apr 2013 16:59:22 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130412145922.GA15943@elstar.local> Mail-Followup-To: philip.eardley@bt.com, acmorton@att.com, trammell@tik.ee.ethz.ch, bs7652@att.com, bclaise@cisco.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3456559C92@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F3456559C92@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bclaise@cisco.com, bs7652@att.com, lmap@ietf.org, acmorton@att.com, trammell@tik.ee.ethz.ch Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 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: Fri, 12 Apr 2013 14:59:18 -0000 On Fri, Apr 12, 2013 at 02:14:39PM +0100, philip.eardley@bt.com wrote: > as regards teh control protocol, the measurement agent may be behind > a NAT (or even two? for MA on CPE inside the home network). so the > control protocol needs to cope with this - which might partly > involve an initialisation function ('Management Server' in the > Broadband forum's liaison) that tells the MA where a collector > is. in my mind it's an open question whetehr lmap defines an > initialisation function or leaves this to BBF. I assume there will likely be different bootstrapping mechanisms since networks and scenarios differ a lot. It is important that lmap clearly defines what information a bootstrapping mechanism needs to provide. /js -- 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 Fri Apr 12 08:03: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 7B5F021F88B9 for ; Fri, 12 Apr 2013 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=0.219, 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 dN0gofqKJHA3 for ; Fri, 12 Apr 2013 08:03:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BE21C21F8842 for ; Fri, 12 Apr 2013 08:03:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EE6A20BFE; Fri, 12 Apr 2013 17:03:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FSvadxzBLXE9; Fri, 12 Apr 2013 17:03: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 BF1CE20BFA; Fri, 12 Apr 2013 17:03:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 26483259E265; Fri, 12 Apr 2013 17:03:14 +0200 (CEST) Date: Fri, 12 Apr 2013 17:03:14 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130412150314.GB15943@elstar.local> Mail-Followup-To: philip.eardley@bt.com, bs7652@att.com, bclaise@cisco.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611302A3D00@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F3456559C91@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F3456559C91@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bclaise@cisco.com, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation:Q6-Liaisons 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: Fri, 12 Apr 2013 15:03:09 -0000 On Fri, Apr 12, 2013 at 02:02:21PM +0100, philip.eardley@bt.com wrote: > > from a politeness perspective, do BBF &/or IEEE expect a reply? not > sure what the normal process is. if they're happy not to get a reply > then i'm happy if we don't! I am not a liason person and as such I naively assume that we (a) need to wait until we know for sure whether there is going to be a WG effort in the IETF and (b) at that point in time it might be useful to send a polite response stating that there now is a WG and that the IETF in particular invites people to participate in the open process or to at least monitor it as they see fit. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From acmorton@att.com Fri Apr 12 08:06: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 DBED921F8C1A for ; Fri, 12 Apr 2013 08:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 aKIsEAK4mV0d for ; Fri, 12 Apr 2013 08:06:16 -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 A803821F8C00 for ; Fri, 12 Apr 2013 08:06:15 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 8E47B120537; Fri, 12 Apr 2013 11:06:34 -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 9587AE3737; Fri, 12 Apr 2013 10:57:40 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 12 Apr 2013 11:06:14 -0400 From: "MORTON JR., ALFRED C (AL)" To: "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Date: Fri, 12 Apr 2013 11:06:13 -0400 Thread-Topic: [lmap] LMAP: situation: Q5-Gaming the system Thread-Index: Ac42/pwAT+Ce3sOSSoaw+MRXukMaeAAg2mhpAAM9iPA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F3456559C94@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3456559C94@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system 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, 12 Apr 2013 15:06:17 -0000 I want to make the cross-thread linkage between my Q3 comment and Q5 thread= explicit: > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: Thursday, April 11, 2013 5:47 PM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements >=20 >=20 > Barbara's response=20 +++ to Q3 +++ > leads to another point stemming from discussion > earlier this week: "neutrality" of measurements. Subscribers already > trust their ISPs with the unencrypted contents of their packets, and > an ISP would have few subscribers if it gave private information away. > A similar code of conduct extends to measurements and published results, > and the potential to loose subscribers for ethical transgressions is > equally great. >=20 > Al > > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: Friday, April 12, 2013 9:38 AM > To: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system >=20 > agree with Barbara's analysis. >=20 > any party in-line can manipulate traffic =3D the ISP and end user, and > sometimes other parties. it seems to me that it's impossible to prevent > the determined gamer doing this. one could devise tests to try and spot > that some party was trying to game the system - i don't have the expertis= e > to do that - would be interesting to see tests /results from others, but > I don't think it's a job for the WG. >=20 > best wishes > phil >=20 > ________________________________________ > From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of STARK, > BARBARA H [bs7652@att.com] > Sent: 11 April 2013 22:50 > To: lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system >=20 > > Question 5: Gaming the system > > Do we agree that, from a technical point of view, there is nothing we > can do to prevent gaming the system? So we're left with the assumption > that people will behave. >=20 > I do not believe there is nothing we can do. I just think there are > infinite ways to game the system and none of them are worth spending my > time on. I believe that the costs of defining and deploying technical > solutions to prevent gaming are greater than the risks/costs of doing > nothing. In my priority list of things to do and ways to spend my time, I > just don't see a lot of value in spending time on that topic. >=20 > I would characterize gaming as intentionally (and perhaps maliciously) > inserting inaccuracy into the overall system or process. There are many, > many ways to accomplish this in the context of lmap: an ISP could apply > QoS to test traffic; an ISP could manipulate collected data prior to > providing it to others; a 3rd party could manipulate collected data prior > to providing it to others (to try to make an ISP look bad/good); a 3rd > party could program their MA to manipulate data before sending it to the > data collector; an ISP could provide inaccurate service attributes to use > for comparison; a 3rd party could program all MAs to run measurements at > the same time against an ISP measurement endpoint in an attempt to degrad= e > performance of all tests against that endpoint; the end user hacks the MA > to make it report bad performance data (because they hate their ISP); > etc. >=20 > But to decide to spend effort guarding against any particular way to game > the system, I believe that the incentive for doing that particular method > of gaming must outweigh the probability of getting caught together with > the costs of getting caught. For me, I don't perceive any of the ways of > gaming as providing a sufficiently high incentive. At least not at this > time. A large part of why I believe this is that (1) I'm not aware of any > evidence of gaming occurring, and (2) there doesn't seem to have been > massive negative/positive repercussions (lots of ISP switching, massive > consumer outcry upon viewing results, fines for perceived poor > performance, etc.) from broadband measurements conducted to date. If ther= e > were greater incentive to some party (e.g., "we'll offer free service for > 10 years to the person who has current service from our competitor and > will apply this hack to the MA in their home, to make our competitor look > bad"), then I think it would be time to consider add > ressing that way of gaming. >=20 > Of course, it's also possible to inadvertently (not intentionally and not > maliciously) insert inaccuracy. There has been evidence of that. For > example, some users took their 3rd party MA over to a friend or relative'= s > house to let it run measurements, not realizing that the MA had been > associated (service attributes) with the broadband service of the origina= l > person. If the original person had a 20Mbps service, and the friend had a > 6Mbps service, then the result interpretation would show that the > measurement service was performing very poorly against the 20Mpbs > benchmark. Because there is evidence of this problem, there are people > asking for solutions to this problem (how to better associate the service > attributes with the MA and the measured data). Inaccuracy has also been > introduced by misinterpreting measurement data. Some of this > misinterpretation can be fixed by better characterization of service > attributes, and some can be dealt with by doing different tests which can > b > e interpreted in the desired way (which is why there's some focus on > figuring out the "right" tests to do). In other words, methods for > inserting inaccuracies that are known to occur are higher priority to > solve technically than inaccuracy insertion methods for which there is no > evidence (and low incentive). > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From shane@castlepoint.net Fri Apr 12 08:49: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 0BDEE21F8DFC for ; Fri, 12 Apr 2013 08:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 upR98P0OFzQF for ; Fri, 12 Apr 2013 08:49:47 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6EED921F8D23 for ; Fri, 12 Apr 2013 08:49:45 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id A3519300078 for ; Fri, 12 Apr 2013 15:49:44 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 1F38D300028; Fri, 12 Apr 2013 09:49:44 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 12 Apr 2013 09:49:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Apr 12 09:49:44 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 51682d1842075359941943 X-DSPAM-Factors: 27, case+#+#+regulator, 0.40000, 2013+at, 0.40000, ISP+#+service, 0.40000, End+#+Network, 0.40000, End+#+Network, 0.40000, Mime-Version*Mail+6.3, 0.40000, to+#+#+#+or, 0.40000, to+#+#+#+an, 0.40000, to+#+#+#+to, 0.40000, to+#+#+#+to, 0.40000, Question+in, 0.40000, 1+#+#+#+that, 0.40000, multi+#+#+#+the, 0.40000, for+#+IETF, 0.40000, devices+#+#+#+the, 0.40000, it+#+probably, 0.40000, and+#+#+#+the, 0.40000, physical+#+#+that, 0.40000, use+#+#+#+As, 0.40000, 2+#+#+#+wondering, 0.40000, that+are, 0.40000, that+are, 0.40000, protocols+#+#+#+over, 0.40000, c+#+providing, 0.40000, case+#+#+#+the, 0.40000, be+helpful, 0.40000, think+that, 0.40000 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Fri, 12 Apr 2013 15:49:48 -0000 Barbara, Thanks for your note. I have some questions for clarification, below. On Apr 11, 2013, at 2:22 PM, "STARK, BARBARA H" wrote: >> Question 1. Use cases >> Do we agree that we want to focus on the Internet Service Provider = and the End User Network Diagnostics use cases for now? As a phase 2, we = could focus on the 3rd party use case: multi-provider, regulator, over = the top >> Question: in the End User Network Diagnostics use case, I'm unclear = if the user initiated measurement is included? [--snip--] > Given the above scope, I could envision potentially having the = following deliverables: > 1. ISP lmap Architecture that includes (1) intra-domain interfaces = between an MA and other MAs (test endpoints) and operational support = systems that manage/control/configure those MAs and the physical = devices/elements that contain the MA, and (2) inter-domain interfaces = for (a) requesting resources on ISP test endpoints, (b) ISP MA = requesting resources on others' test endpoints, and (c) ISP providing = service attribute info to an MA inside an end user's network. > 2. Mechanism for intra- and inter-domain requesting of test endpoint = resources WRT #1 and #2, above, I am wondering if you could clarify your use of = the word "inter-domain"? More specifically, I think it would be helpful = if you could characterize inter-domain in the context of: a) "Control/Signaling Protocols", i.e.: those protocols that are used = to communication from, say, a Measurement Controller to a Measurement = Agent to start/stop one or more tests, Measurement Agent to Measurement = Data Collector to communicate results of tests, etc. b) "Measurement Protocols" and the parts of the network over which they = will operate, i.e.: those (IPPM) protocols that are run over-the-wire = from Measurement Agent to Measurement Server to measure things like: = bandwidth, latency, packet loss, jitter, etc. FWIW, I think that (b) is more about what part, or parts, of the network = are intended to be measured, whereas (a) is more about how the various = 'entities' (MA, MS, MC, etc.) within the LMAP Architecture communicate = with one another to accomplish the tasks to requesting a test, starting = a test, uploading of measurement results, etc. Thanks, -shane > 3. Mechanism for providing service attribute info > 4. BCP on end-user identifiable data elements with discussion of = threats to privacy and recommendations for maintaining privacy > 5. Data models / MIBs for various IETF protocols, based on the ippm = registry. >=20 > Personally, I would be willing to participate in and contribute to 1-4 = above. I have no objection to 5, and think it would probably be useful = to those who use such protocols. > Barbara > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap >=20 From bs7652@att.com Fri Apr 12 11:47: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 4E21421F8EA5 for ; Fri, 12 Apr 2013 11:47:02 -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=[AWL=0.000, 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 c1Ix61q7o7yd for ; Fri, 12 Apr 2013 11:47:01 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id C63C021F8E9E for ; Fri, 12 Apr 2013 11:47:00 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 4a658615.7910e940.241997.00-560.672723.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 12 Apr 2013 18:47:00 +0000 (UTC) X-MXL-Hash: 516856a46db99c6e-08c4c7c4199b34960b20590c5001980af3b8efbc Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 3a658615.0.241990.00-319.672699.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 12 Apr 2013 18:47:00 +0000 (UTC) X-MXL-Hash: 516856a434927cfc-d817f2f315b428e1e5655072dde120df8106494a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3CIkxj3023841; Fri, 12 Apr 2013 14:46:59 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3CIkl5k023580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Apr 2013 14:46:51 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 12 Apr 2013 19:46:37 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 14:46:37 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87A= Date: Fri, 12 Apr 2013 18:46:36 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> In-Reply-To: <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.42.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=f7b/8pOM c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=VfjGxOmUvtUA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=h1y25UJVS0Ap2zxTMgsA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=5x5H8evbm7-qDwti:21 a=8Ij5EmQLyfSBl2Gh:21] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Fri, 12 Apr 2013 18:47:02 -0000 > > Given the above scope, I could envision potentially having the followin= g > deliverables: > > 1. ISP lmap Architecture that includes (1) intra-domain interfaces betw= een > an MA and other MAs (test endpoints) and operational support systems that > manage/control/configure those MAs and the physical devices/elements > that contain the MA, and (2) inter-domain interfaces for (a) requesting > resources on ISP test endpoints, (b) ISP MA requesting resources on other= s' > test endpoints, and (c) ISP providing service attribute info to an MA ins= ide an > end user's network. > > 2. Mechanism for intra- and inter-domain requesting of test endpoint > > resources >=20 > WRT #1 and #2, above, I am wondering if you could clarify your use of the > word "inter-domain"? More specifically, I think it would be helpful if y= ou > could characterize inter-domain in the context of: > a) "Control/Signaling Protocols", i.e.: those protocols that are used to > communication from, say, a Measurement Controller to a Measurement > Agent to start/stop one or more tests, Measurement Agent to > Measurement Data Collector to communicate results of tests, etc. > b) "Measurement Protocols" and the parts of the network over which they > will operate, i.e.: those (IPPM) protocols that are run over-the-wire fro= m > Measurement Agent to Measurement Server to measure things like: > bandwidth, latency, packet loss, jitter, etc. >=20 >=20 > FWIW, I think that (b) is more about what part, or parts, of the network = are > intended to be measured, whereas (a) is more about how the various > 'entities' (MA, MS, MC, etc.) within the LMAP Architecture communicate > with one another to accomplish the tasks to requesting a test, starting a= test, > uploading of measurement results, etc. Hi Shane, By "intra-domain", I mean that the same entity has control/management over = both ends of the interface. "Inter-domain" means that different entities co= ntrol/manage the interface endpoints. I have no interest in scoping lmap "phase 1" to try to deal with protocols = for supporting "inter-domain" communication outside of "ask permission to r= un a test just before running it" and providing service attributes from a d= evice inside the home network to another device inside the same home networ= k. For Measurement Controller to MA to start/stop/schedule tests, I'm only = interested in scoping lmap (phase 1) to discuss intra-domain. Same for MA t= o Data Collector. The same goes for communication between a device or netwo= rk element to a Management Server. Which isn't to say that such inter-domai= n interfaces won't or can't or shouldn't exist (I fully support their right= to exist) -- I'm just suggesting that they not be in lmap "phase 1" scope. I think there is a big need for measurement protocols to be run inter-domai= n. Since there seems to be a desire by the owners of some test endpoints to= require "ask permission first", this needs to be in lmap "phase 1" scope: = for intra-domain (test endpoints under "the ISP"s control), and inter-domai= n (one end of the test under "the ISP"s control and the other end under som= eone else's control). Also, if the MA can be under someone else's control a= nd needs to associate service attributes with the measurement data, then we= need some way to supply those attributes from "the ISP" to the MA. [I've p= ut "the ISP" in quotes because it's been suggested to be a central figure i= n the phase 1 scope.] There's also a bunch of intra-domain interfaces I'm not interested in seein= g in "phase 1". Basically, interfaces with the MA (or its physical device/e= lement) as a communication endpoint I would like to see in scope. All other= interfaces I would prefer not to have in scope for lmap "phase 1". For exa= mple, if or how a Management Server talks directly a Measurement Controller= , or a Data Collector, I really don't care.=20 Barbara From bs7652@att.com Fri Apr 12 12:14:59 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 4C39A21F8DB4 for ; Fri, 12 Apr 2013 12:14:59 -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 bDQkDlUtR5S0 for ; Fri, 12 Apr 2013 12:14:58 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1621F8DFC for ; Fri, 12 Apr 2013 12:14:58 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 23d58615.72303940.256573.00-520.713083.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 12 Apr 2013 19:14:58 +0000 (UTC) X-MXL-Hash: 51685d323c5b2480-9ab0cde4abdd3c5d5d2d6e55029b0b6126129947 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 03d58615.0.256559.00-441.713039.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 12 Apr 2013 19:14:57 +0000 (UTC) X-MXL-Hash: 51685d31687bcef7-8acab7c6ce30f798447ffbed40ee2e1da031c051 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3CJEtu5020466; Fri, 12 Apr 2013 15:14:56 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3CJEmc8020368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Apr 2013 15:14:51 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by alpi133.aldc.att.com (RSA Interceptor); Fri, 12 Apr 2013 20:14:35 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 15:14:34 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP: situation:Q6-Liaisons Thread-Index: Ac423hw1gwcdOmN1SwiWBIDhn0nbBgAn9tFfAAyaqAAAB+7SQA== Date: Fri, 12 Apr 2013 19:14:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A5632@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3D00@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F3456559C91@EMV65-UKRD.domain1.systemhost.net> <20130412150314.GB15943@elstar.local> In-Reply-To: <20130412150314.GB15943@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.42.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=f7b/8pOM c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=VfjGxOmUvtUA:10 a=QoHQE9LVNRgA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=d7lUWxnNak8A:10 a=48vgC7mUAAAA:8 a=UDEjXZXLTWfrtj] X-AnalysisOut: [R_AEwA:9 a=CjuIK1q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation:Q6-Liaisons 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, 12 Apr 2013 19:14:59 -0000 > > from a politeness perspective, do BBF &/or IEEE expect a reply? not > > sure what the normal process is. if they're happy not to get a reply > > then i'm happy if we don't! >=20 > I am not a liason person and as such I naively assume that we (a) need to= wait > until we know for sure whether there is going to be a WG effort in the IE= TF > and (b) at that point in time it might be useful to send a polite respons= e > stating that there now is a WG and that the IETF in particular invites pe= ople to > participate in the open process or to at least monitor it as they see fit= . IETF liaison process is defined in [http://tools.ietf.org/html/rfc4052]. Pe= r this RFC -- in the absence of a WG, it would be possible for an AD (or ev= en the IETF leadership) to write (or assign someone to write) a liaison res= ponse to come from an area (or IETF). Once there is a WG, it would also be = possible for the WG chair to write (or assign someone to write) a response = to come from the WG.=20 I do agree that a liaison indicating the start of the WG would be a good id= ea, to all orgs who have indicated an interest in this topic (BBF and IEEE = 802.16). Since that's a simple liaison statement to write, I think it's rea= sonable to ask those in charge to do that. Anyway, since it's ultimately the WG chair or AD who gets saddled with the = job of dealing with liaison statement creation, I will strongly support the= se in-charge people in whatever decision they make regarding liaison respon= ses. I'm also happy to put effort into convincing BBF that responses aren't= needed, as I have no desire to be tasked with writing a response to BBF. [= General rule of liaisons: whoever cares the most about having a liaison sta= tement written is volunteering to draft it.]=20 Barbara From shane@castlepoint.net Fri Apr 12 12:53: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 82D3A21F8D8E for ; Fri, 12 Apr 2013 12:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 351TbEaA6tLT for ; Fri, 12 Apr 2013 12:53:03 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9B47821F890D for ; Fri, 12 Apr 2013 12:53:03 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 3246A300028 for ; Fri, 12 Apr 2013 19:53:03 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 73279300015; Fri, 12 Apr 2013 13:53:02 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Fri, 12 Apr 2013 13:53:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Apr 12 13:53:03 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5168661f42071844110064 X-DSPAM-Factors: 27, a+Inter, 0.40000, 2013+at, 0.40000, contain+#+#+#+'service, 0.40000, ISP+#+service, 0.40000, but+#+#+#+5, 0.40000, because+#+#+suggested, 0.40000, Mime-Version*Mail+6.3, 0.40000, to+#+#+#+or, 0.40000, from+#+#+#+toward, 0.40000, Network+Management, 0.40000, and+#+could, 0.40000, to+#+#+#+an, 0.40000, be+that, 0.40000, if+#+#+can, 0.40000, to+#+#+#+to, 0.40000, to+#+#+#+to, 0.40000, Server+#+#+#+MA, 0.40000, Server+#+#+#+MA, 0.40000, 1+#+#+#+that, 0.40000, access+technology, 0.40000, Inter+#+#+function, 0.40000, only+#+#+scoping, 0.40000, lines+#+the, 0.40000, that+#+#+for, 0.40000, best+#+accomplish, 0.40000, Domain+#+#+#+permission, 0.40000, devices+#+#+#+the, 0.40000 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Fri, 12 Apr 2013 19:53:04 -0000 Hi Barbara, On Apr 12, 2013, at 12:46 PM, "STARK, BARBARA H" wrote: >>> Given the above scope, I could envision potentially having the = following >> deliverables: >>> 1. ISP lmap Architecture that includes (1) intra-domain interfaces = between >> an MA and other MAs (test endpoints) and operational support systems = that >> manage/control/configure those MAs and the physical devices/elements >> that contain the MA, and (2) inter-domain interfaces for (a) = requesting >> resources on ISP test endpoints, (b) ISP MA requesting resources on = others' >> test endpoints, and (c) ISP providing service attribute info to an MA = inside an >> end user's network. >>> 2. Mechanism for intra- and inter-domain requesting of test endpoint >>> resources >>=20 >> WRT #1 and #2, above, I am wondering if you could clarify your use of = the >> word "inter-domain"? More specifically, I think it would be helpful = if you >> could characterize inter-domain in the context of: >> a) "Control/Signaling Protocols", i.e.: those protocols that are = used to >> communication from, say, a Measurement Controller to a Measurement >> Agent to start/stop one or more tests, Measurement Agent to >> Measurement Data Collector to communicate results of tests, etc. >> b) "Measurement Protocols" and the parts of the network over which = they >> will operate, i.e.: those (IPPM) protocols that are run over-the-wire = from >> Measurement Agent to Measurement Server to measure things like: >> bandwidth, latency, packet loss, jitter, etc. >>=20 >>=20 >> FWIW, I think that (b) is more about what part, or parts, of the = network are >> intended to be measured, whereas (a) is more about how the various >> 'entities' (MA, MS, MC, etc.) within the LMAP Architecture = communicate >> with one another to accomplish the tasks to requesting a test, = starting a test, >> uploading of measurement results, etc. >=20 > Hi Shane, > By "intra-domain", I mean that the same entity has control/management = over both ends of the interface. "Inter-domain" means that different = entities control/manage the interface endpoints. >=20 > I have no interest in scoping lmap "phase 1" to try to deal with = protocols for supporting "inter-domain" communication outside of "ask = permission to run a test just before running it" I would agree that LMAP "Phase 1" must support a Inter-Domain capability = to 'ask permission to run a test just before running it'. (See below = for why). > and providing service attributes from a device inside the home network = to another device inside the same home network. I could agree with this, as well. =20 By service attributes, I assume you mean something along the lines of = the ISP "service package" the customer has subscribed to, e.g.: 100 Mbps = down/50 Mbps up; DSL or DOCSIS access technology; etc. correct? However, one addition to this would be that I think it's important to = share 'service attributes' from a so-called Measurement Parameter Server = to (a) a Measurement Collector (directly) -or- (b) from a so-called = Measurement Parameter Server to a Measurement Agent (e.g.: in the home) = and have the MA share the 'service attributes' with the Measurement = Collector, (perhaps bundled in as part of the measurement results of a = just performed test). IMO, measurement results are only going to be = meaningful if they also contain the so-called 'service attributes' so = that it's easy for someone performing post-analysis of measurement = results to know that they are looking at 'valid' data. FWIW, I don't = have a strong preference on (a) or (b) and would be open to discussing = other operational models to facilitate this communication as well as = whether (a) and (b) could "co-exist" in the overall LMAP architecture = and it will be up to ISP's (or, others) to choose whichever one they = prefer. > For Measurement Controller to MA to start/stop/schedule tests, I'm = only interested in scoping lmap (phase 1) to discuss intra-domain. Same = for MA to Data Collector. The same goes for communication between a = device or network element to a Management Server. Just so I'm clear, in the above, do you equate a "MA" to exist on, say, = only a CPE router/modem in a end-user's house? And, the "Measurement = Server" side does not contain a "MA"? (I believe that is the = appropriate frame of reference, given the various drafts in LMAP, so = far). This could fit the model you've proposed for LMAP "Phase 1" where there = is Intra-Domain communication from a Measurement Controller to a MA = (e.g.: to start/stop tests). At the same time, there exists a = third-party (Inter-Domain) "Measurement Server" to which the MA will = conduct network performance tests against. In this particular instance, = as I understand it, the 3rd-party Measurement Server would have no = "heads-up" (or, as you phrased it "be asked permission just before = running it") ... at least, via an Inter-Domain communication method = directly from a "Measurement Controller". That could be one operational = model, but it may lead to concerns with respect to a (unintended) DoS = attack on the Measurement Server side of things or, worse, we obtain = 'tainted'/suboptimal performance results, because the Measurement Server = side is over-subscribed (e.g.: BW or CPU saturated). IMO, it might be useful to think of allowing Inter-Domain communication = from the "Measurement Controller" to the "Measurement Server" and from = the "MA" to the "Measurement Server" strictly for the capability to = perform some type of "Call Admission Control" (CAC) function. The = benefit of allowing the Measurement Controller to perform CAC to the = Measurement Server is, presumably, it could aggregate a whole series of = tests it is *about* to schedule on MA's to a Measurement Server and say: = "Can you handle tests that may generate 10 Gbps of traffic in the next N = minutes?" The Measurement Server may simply respond: "No" or "No, but I = can handle 5 Gbps". OTOH, we likely need a similar CAC function on the = "MA" to Measurement Server so that in the cases of various network = and/or server failures, the "MA" can dynamically and autonomously adapt = on its own to those conditions w/out having to be explicitly told to = "knock it off" by a Measurement Controller. The latter is likely = critical in the case where the Measurement Controller is offline = (failed) or otherwise not reachable from the MA. I would agree that, in general, anything beyond a relatively = straightforward Intra- and Inter-Domain CAC function from MC and MA = toward the Measurement Server should be out-of-scope for a LMAP "Phase = 1". Does the above sound reasonable? > Which isn't to say that such inter-domain interfaces won't or can't or = shouldn't exist (I fully support their right to exist) -- I'm just = suggesting that they not be in lmap "phase 1" scope. >=20 > I think there is a big need for measurement protocols to be run = inter-domain. Since there seems to be a desire by the owners of some = test endpoints to require "ask permission first", this needs to be in = lmap "phase 1" scope: for intra-domain (test endpoints under "the ISP"s = control), and inter-domain (one end of the test under "the ISP"s control = and the other end under someone else's control). I also think a CAC function would be useful (required?) from MA to MS = and from MC to MS both in the intra- and inter-domain contexts. > Also, if the MA can be under someone else's control and needs to = associate service attributes with the measurement data, then we need = some way to supply those attributes from "the ISP" to the MA. [I've put = "the ISP" in quotes because it's been suggested to be a central figure = in the phase 1 scope.] Agreed. As I said above, I'm not sure how it is best to accomplish that = and, for that matter, whether we need to choose only one ... assuming = that having more than one does not create complexity. > There's also a bunch of intra-domain interfaces I'm not interested in = seeing in "phase 1". Basically, interfaces with the MA (or its physical = device/element) as a communication endpoint I would like to see in = scope. All other interfaces I would prefer not to have in scope for lmap = "phase 1". For example, if or how a Management Server talks directly a = Measurement Controller, or a Data Collector, I really don't care.=20 By "Management Server", do you mean something like a NMS? (Network = Management System?) -shane From bs7652@att.com Fri Apr 12 17:29:01 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 E6BE621F8DC1 for ; Fri, 12 Apr 2013 17:29:01 -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=[AWL=0.000, 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 f-W8r0p4nrIF for ; Fri, 12 Apr 2013 17:29:00 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7C321F8DA0 for ; Fri, 12 Apr 2013 17:29:00 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id cc6a8615.7c95b940.366482.00-596.1016733.nbfkord-smmo08.seg.att.com (envelope-from ); Sat, 13 Apr 2013 00:29:00 +0000 (UTC) X-MXL-Hash: 5168a6cc450b371e-0a160a4b121dec1c62c56375a789e04d2cd28fa5 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ac6a8615.0.366474.00-307.1016704.nbfkord-smmo08.seg.att.com (envelope-from ); Sat, 13 Apr 2013 00:28:59 +0000 (UTC) X-MXL-Hash: 5168a6cb412ce500-82a9880609d643e0a82b55602ef1776deaf78cc3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3D0Sv2Z029746; Fri, 12 Apr 2013 20:28:58 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3D0Smjf029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Apr 2013 20:28:52 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor); Sat, 13 Apr 2013 01:28:29 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Fri, 12 Apr 2013 20:28:29 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQ Date: Sat, 13 Apr 2013 00:28:27 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.42.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=CucIhAED c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=VfjGxOmUvtUA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=WmxBOpaqK16E80xk8bEA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=hYYI7XP0ahstUXd0:21 a=7NlAJjQ1NcGj7khF:21] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Sat, 13 Apr 2013 00:29:02 -0000 > By service attributes, I assume you mean something along the lines of the= ISP > "service package" the customer has subscribed to, e.g.: 100 Mbps down/50 > Mbps up; DSL or DOCSIS access technology; etc. correct? Yes =20 > However, one addition to this would be that I think it's important to sha= re > 'service attributes' from a so-called Measurement Parameter Server to (a)= a > Measurement Collector (directly) If the ISP who knows the attributes also manages the Data Collector, then t= hat's intra-domain, and the ISP should be able to figure out how to do that= within there OSS network without help from IETF. Therefore, I don't see a = need for the intra-domain interface to be in lmap phase 1 scope. If the ISP= does not control the Data Collector, then I think this is a much more diff= icult problem to solve, because it involves the ISP knowing that the Data C= ollector controlling entity has the end user's permission to have access to= this data. Because of the need for permission with all of its associated n= eed to authenticate the Data Collector and "know" that the end user has aut= horized that Data Collector (and allow the end user to revoke that authoriz= ation, change that authorization, etc.), I consider this a much more comple= x problem to solve and would prefer for it not to be in lmap phase 1 scope. > -or- (b) from a so-called Measurement > Parameter Server to a Measurement Agent (e.g.: in the home) and have the > MA share the 'service attributes' with the Measurement Collector, (perhap= s > bundled in as part of the measurement results of a just performed test). Yes. If an MA is already inside the home network of the end user whose serv= ice it is, then providing information to that MA about the end user's broad= band service should be ok. If the "MA" getting the info is a Trojan or spyw= are (in other words, inside the home network without the end user's permiss= ion or knowledge), then I think it having access to the end user's broadban= d service attributes may be the least of the end user's worries. > IMO, measurement results are only going to be meaningful if they also > contain the so-called 'service attributes' so that it's easy for someone > performing post-analysis of measurement results to know that they are > looking at 'valid' data. FWIW, I don't have a strong preference on (a) o= r (b) > and would be open to discussing other operational models to facilitate th= is > communication as well as whether (a) and (b) could "co-exist" in the over= all > LMAP architecture and it will be up to ISP's (or, others) to choose which= ever > one they prefer. Yes, this is an important topic. As I mentioned above, I do have a preferen= ce for which to address in the context of standardization (lmap phase 1). B= ut even if IETF doesn't define all of the 3-way authorization/authenticatio= n and data exchange mechanisms for a fully standardized (a) inter-domain so= lution, it would still be possible for an ISP to do this on their own, or t= ogether with a regulator-identified 3rd party. So the ISP (or others) will = still be free to choose that approach. =20 > > For Measurement Controller to MA to start/stop/schedule tests, I'm only > interested in scoping lmap (phase 1) to discuss intra-domain. Same for MA= to > Data Collector. The same goes for communication between a device or > network element to a Management Server. >=20 > Just so I'm clear, in the above, do you equate a "MA" to exist on, say, o= nly a > CPE router/modem in a end-user's house? And, the "Measurement Server" > side does not contain a "MA"? (I believe that is the appropriate frame o= f > reference, given the various drafts in LMAP, so far). No. In my vision of the term, an MA (as a generic Measurement Agent) can ex= ist on anything that has L1 connectivity or above. In the context of IETF, = I would suggest that IETF can be helpful with solutions for MAs that have I= P connectivity. I really think we should get away from Measurement Server. = My terminology vision is that active tests can run between MAs. One MA is g= enerally responsible for initiating a particular active test. In that case,= I tried (I think) to refer to the one as the initiating MA and the other e= nd of the test as the test endpoint. I think the lmap phase 1 scope is also= supposed to support ISP tests that may be run between endpoints (MAs) that= are all within the ISP's network. I also think that some ISPs may choose t= o run diagnostic tests (usually while on the phone with a customer, to trou= bleshoot a problem) that are initiated by the ISP network element, with the= MA in the home network as the test endpoint. This is not uncommon. Because= MAs can conduct passive measurement collection, initiate active tests or a= ct as active test endpoints, I find the term "Measurement Server" to be ver= y confusing. Is an MA that can initiate and respond to a ping test an MA wh= en it initiates the ping but a Measurement Server when it responds to the p= ing? Or is something that participates in measurements in an ISP network el= ement always a Measurement Server, no matter whether it initiates or respon= ds to tests? Al Morton did a great job at describing this terminology probl= em in one of the early lmap threads. He convinced me.=20 =20 > This could fit the model you've proposed for LMAP "Phase 1" where there i= s > Intra-Domain communication from a Measurement Controller to a MA (e.g.: > to start/stop tests). At the same time, there exists a third-party (Inte= r- > Domain) "Measurement Server" to which the MA will conduct network > performance tests against. In this particular instance, as I understand = it, the > 3rd-party Measurement Server would have no "heads-up" (or, as you > phrased it "be asked permission just before running it") ... at least, vi= a an > Inter-Domain communication method directly from a "Measurement > Controller". That could be one operational model, but it may lead to > concerns with respect to a (unintended) DoS attack on the Measurement > Server side of things or, worse, we obtain 'tainted'/suboptimal performan= ce > results, because the Measurement Server side is over-subscribed (e.g.: BW > or CPU saturated). >=20 > IMO, it might be useful to think of allowing Inter-Domain communication > from the "Measurement Controller" to the "Measurement Server" and from > the "MA" to the "Measurement Server" strictly for the capability to perfo= rm > some type of "Call Admission Control" (CAC) function. The benefit of > allowing the Measurement Controller to perform CAC to the Measurement > Server is, presumably, it could aggregate a whole series of tests it is *= about* > to schedule on MA's to a Measurement Server and say: "Can you handle > tests that may generate 10 Gbps of traffic in the next N minutes?" The > Measurement Server may simply respond: "No" or "No, but I can handle 5 > Gbps". OTOH, we likely need a similar CAC function on the "MA" to > Measurement Server so that in the cases of various network and/or server > failures, the "MA" can dynamically and autonomously adapt on its own to > those conditions w/out having to be explicitly told to "knock it off" by = a > Measurement Controller. The latter is likely critical in the case where = the > Measurement Controller is offline (failed) or otherwise not reachable fro= m > the MA. >=20 > I would agree that, in general, anything beyond a relatively straightforw= ard > Intra- and Inter-Domain CAC function from MC and MA toward the > Measurement Server should be out-of-scope for a LMAP "Phase 1". >=20 > Does the above sound reasonable? >=20 >=20 > > Which isn't to say that such inter-domain interfaces won't or can't or > shouldn't exist (I fully support their right to exist) -- I'm just sugges= ting that > they not be in lmap "phase 1" scope. > > > > I think there is a big need for measurement protocols to be run inter- > domain. Since there seems to be a desire by the owners of some test > endpoints to require "ask permission first", this needs to be in lmap "ph= ase > 1" scope: for intra-domain (test endpoints under "the ISP"s control), and > inter-domain (one end of the test under "the ISP"s control and the other = end > under someone else's control). >=20 > I also think a CAC function would be useful (required?) from MA to MS and > from MC to MS both in the intra- and inter-domain contexts. =20 If you're suggesting perhaps "reserving" resources ahead of time, for tests= that are scheduled on masses of MAs, I think I could agree with the Measur= ement Controller doing the asking. Most usage scenarios I've heard of invol= ve the Measurement Controller scheduling MAs to do mass testing, and only u= sing start/stop control for specific MA on-demand tests. I would question t= he desirability of having huge numbers of MAs all start testing at the same= time, even if the test endpoint can handle it. There may be a bottleneck s= omewhere in between that isn't scaled to expect all of the end users to max= out their data connections at the same time. And think of what that would = do all of the innocent end users who aren't involved in the test but sudden= ly have their service degraded. There's also the idea that if the end user = is actively using their access connection, then the MA is supposed to wait = and not test. Even in the on-demand start/stop case, it may be desired for = the MA to say "No, I won't run the test unless you force me to" if there is= significant traffic on the access link. And if there are masses of MAs tha= t were asked to run at the same time, is the Controller ready to deal with = a response from each all at the same time, where many may be saying "No not= now"? I really think it's much cleaner to schedule tests and get the Measu= rement Controller out of the way, and for the MA to ask permission when it'= s ready. Note that if the Measurement Controller wants to ask on behalf of = just one MA, then this could actually be the same CAC mechanism as MA to te= st endpoint. But I think I can agree to the need for us to consider the mas= s request for inter-domain mechanism to allow for a Measurement Controller = to reserve scheduled resources. > > There's also a bunch of intra-domain interfaces I'm not interested in s= eeing > in "phase 1". Basically, interfaces with the MA (or its physical > device/element) as a communication endpoint I would like to see in scope. > All other interfaces I would prefer not to have in scope for lmap "phase = 1". > For example, if or how a Management Server talks directly a Measurement > Controller, or a Data Collector, I really don't care. >=20 > By "Management Server", do you mean something like a NMS? (Network > Management System?) Yes. Or a TR-069 server. Or an SNMP server used to manage cable modems. The= re is an idea that it may be desirable to manage the MA as an application s= eparate from the device. Therefore, device management is identified as a di= stinct function from MA management. This does not mean that the MA has to b= e managed separately from the device. It just allows us to talk about that = and consider the implications. It could also allow for managed MAs to resid= e on unmanaged devices, like a desktop PC. Or for the user to download an M= A app onto their smart phone, where the smart phone itself may be managed v= ia OMA-DM by the wireless ISP. Barbara From shane@castlepoint.net Sun Apr 14 20:20:00 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 A02BC21F86DC for ; Sun, 14 Apr 2013 20:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 PW9BkMFugJio for ; Sun, 14 Apr 2013 20:19:59 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id D101E21F86C4 for ; Sun, 14 Apr 2013 20:19:59 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D1F4C300025 for ; Mon, 15 Apr 2013 03:19:58 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id CD3AF300015; Sun, 14 Apr 2013 21:19:57 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Sun, 14 Apr 2013 21:19:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Apr 14 21:19:58 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 516b71de42077235211470 X-DSPAM-Factors: 27, you're+#+perhaps, 0.40000, 2013+at, 0.40000, there+#+#+#+on, 0.40000, loses+commercial, 0.40000, should+#+#+to, 0.40000, but+#+#+#+5, 0.40000, question+#+#+#+having, 0.40000, much+#+#+#+tests, 0.40000, then+#+#+actually, 0.40000, test+but, 0.40000, scope+#+#+#+the, 0.40000, specific+#+#+#+tests, 0.40000, Mime-Version*Mail+6.3, 0.40000, from+#+#+#+toward, 0.40000, Therefore+#+don't, 0.40000, problem+#+solve, 0.40000, problem+#+solve, 0.40000, actually+#+#+same, 0.40000, it+not, 0.40000, the+#+#+#+stop, 0.40000, be+that, 0.40000, of+#+#+#+users, 0.40000, to+#+#+#+to, 0.40000, to+#+#+#+to, 0.40000, Server+#+#+#+MA, 0.40000, Server+#+#+#+MA, 0.40000, access+technology, 0.40000 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 03:20:00 -0000 Barbara, Snipping those parts where I think we're in agreement. Please see = below. On Apr 12, 2013, at 6:28 PM, "STARK, BARBARA H" wrote: >> By service attributes, I assume you mean something along the lines of = the ISP >> "service package" the customer has subscribed to, e.g.: 100 Mbps = down/50 >> Mbps up; DSL or DOCSIS access technology; etc. correct? >=20 > Yes >=20 >> However, one addition to this would be that I think it's important to = share >> 'service attributes' from a so-called Measurement Parameter Server to = (a) a >> Measurement Collector (directly) >=20 > If the ISP who knows the attributes also manages the Data Collector, = then that's intra-domain, and the ISP should be able to figure out how = to do that within there OSS network without help from IETF. Therefore, I = don't see a need for the intra-domain interface to be in lmap phase 1 = scope. If the ISP does not control the Data Collector, then I think this = is a much more difficult problem to solve, because it involves the ISP = knowing that the Data Collector controlling entity has the end user's = permission to have access to this data. Because of the need for = permission with all of its associated need to authenticate the Data = Collector and "know" that the end user has authorized that Data = Collector (and allow the end user to revoke that authorization, change = that authorization, etc.), I consider this a much more complex problem = to solve and would prefer for it not to be in lmap phase 1 scope. At a minimum, the party (e.g.: regulatory entity) who are receiving the = "service attributes" from several dozen ISPs would want to receive them = in a standards-based data model, (e.g.: XML schema), to make processing = of the data contained therein more straightforward. So, for the defined = regulatory use case, this should be in scope of "LMAP Phase 1", right? [--snip--] >> This could fit the model you've proposed for LMAP "Phase 1" where = there is >> Intra-Domain communication from a Measurement Controller to a MA = (e.g.: >> to start/stop tests). At the same time, there exists a third-party = (Inter- >> Domain) "Measurement Server" to which the MA will conduct network >> performance tests against. In this particular instance, as I = understand it, the >> 3rd-party Measurement Server would have no "heads-up" (or, as you >> phrased it "be asked permission just before running it") ... at = least, via an >> Inter-Domain communication method directly from a "Measurement >> Controller". That could be one operational model, but it may lead to >> concerns with respect to a (unintended) DoS attack on the Measurement >> Server side of things or, worse, we obtain 'tainted'/suboptimal = performance >> results, because the Measurement Server side is over-subscribed = (e.g.: BW >> or CPU saturated). >>=20 >> IMO, it might be useful to think of allowing Inter-Domain = communication >> from the "Measurement Controller" to the "Measurement Server" and = from >> the "MA" to the "Measurement Server" strictly for the capability to = perform >> some type of "Call Admission Control" (CAC) function. The benefit of >> allowing the Measurement Controller to perform CAC to the Measurement >> Server is, presumably, it could aggregate a whole series of tests it = is *about* >> to schedule on MA's to a Measurement Server and say: "Can you handle >> tests that may generate 10 Gbps of traffic in the next N minutes?" = The >> Measurement Server may simply respond: "No" or "No, but I can handle = 5 >> Gbps". OTOH, we likely need a similar CAC function on the "MA" to >> Measurement Server so that in the cases of various network and/or = server >> failures, the "MA" can dynamically and autonomously adapt on its own = to >> those conditions w/out having to be explicitly told to "knock it off" = by a >> Measurement Controller. The latter is likely critical in the case = where the >> Measurement Controller is offline (failed) or otherwise not reachable = from >> the MA. >>=20 >> I would agree that, in general, anything beyond a relatively = straightforward >> Intra- and Inter-Domain CAC function from MC and MA toward the >> Measurement Server should be out-of-scope for a LMAP "Phase 1". >>=20 >> Does the above sound reasonable? >>=20 >>=20 >>> Which isn't to say that such inter-domain interfaces won't or can't = or >> shouldn't exist (I fully support their right to exist) -- I'm just = suggesting that >> they not be in lmap "phase 1" scope. >>>=20 >>> I think there is a big need for measurement protocols to be run = inter- >> domain. Since there seems to be a desire by the owners of some test >> endpoints to require "ask permission first", this needs to be in lmap = "phase >> 1" scope: for intra-domain (test endpoints under "the ISP"s control), = and >> inter-domain (one end of the test under "the ISP"s control and the = other end >> under someone else's control). >>=20 >> I also think a CAC function would be useful (required?) from MA to MS = and >> from MC to MS both in the intra- and inter-domain contexts. >=20 > If you're suggesting perhaps "reserving" resources ahead of time, for = tests that are scheduled on masses of MAs, I think I could agree with = the Measurement Controller doing the asking. Most usage scenarios I've = heard of involve the Measurement Controller scheduling MAs to do mass = testing, and only using start/stop control for specific MA on-demand = tests. Agreed. > I would question the desirability of having huge numbers of MAs all = start testing at the same time, even if the test endpoint can handle it. = There may be a bottleneck somewhere in between that isn't scaled to = expect all of the end users to max out their data connections at the = same time. FWIW, I'm not suggesting any such thing. Rather, consider the scenario = where an entire neighborhood loses commercial power and thousands (or, = 10s of 1,000's) of the CPE devices power-on at the same time. We = definitely do not want all of those CPE's (and, more specifically the = MA's on them) to all re-initiate their tests and cause catastrophic = problems in the network. Hence, we definitely will need a CAC mechanism = at the MA's to ensure this doesn't happen. > And think of what that would do all of the innocent end users who = aren't involved in the test but suddenly have their service degraded. = There's also the idea that if the end user is actively using their = access connection, then the MA is supposed to wait and not test. Even in = the on-demand start/stop case, it may be desired for the MA to say " > No, I won't run the test unless you force me to" if there is = significant traffic on the access link. And if there are masses of MAs = that were asked to run at the same time, is the Controller ready to deal = with a response from each all at the same time, where many may be saying = "No not now"? I really think it's much cleaner to schedule tests and get = the Measurement Controller out of the way, and for the MA to ask = permission when it's ready. Note that if the Measurement Controller = wants to ask on behalf of just one MA, then this could actually be the = same CAC mechanism as MA to test endpoint. But I think I can agree to = the need for us to consider the mass request for inter-domain mechanism = to allow for a Measurement Controller to reserve scheduled resources. OK. We agree that a CAC mechanism is needed in the MA -> Measurement = Server direction both for Intra- and Inter-Domain cases. Thanks, -shane= From j.schoenwaelder@jacobs-university.de Mon Apr 15 04:46: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 5940221F93C6 for ; Mon, 15 Apr 2013 04:46:48 -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=[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 92FPjOV33dzf for ; Mon, 15 Apr 2013 04:46:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3916621F93BD for ; Mon, 15 Apr 2013 04:46:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDCE320BD4; Mon, 15 Apr 2013 13:46:45 +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 UIbS4glpZPjM; Mon, 15 Apr 2013 13:46:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5783D20BCD; Mon, 15 Apr 2013 13:46:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 14D9025A379F; Mon, 15 Apr 2013 13:46:51 +0200 (CEST) Date: Mon, 15 Apr 2013 13:46:51 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20130415114651.GA23837@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [lmap] comments on draft-eardley-lmap-terminology-00.txt 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: Mon, 15 Apr 2013 11:46:48 -0000 Hi, I have read draft-eardley-lmap-terminology-00.txt and here are some of my comments: a) In section 2, I suggest you use IP addresses from the reserved example address space, see RFC 5737 for IPv4. b) Bullet #5 in section should not really be a bullet. It might be useful to switch to a numbered list and then this bullet can be moved behind the list stating "Items 1-4 effectively define a Measurement Task" and then you add "Items x-y effectively define a Report" (removing "The definition of the Report." from the current bullet 6 since also subsequent bullets seem to belong to a Report). (Yes, this is editorial nitpicking, I know.) c) End of section 2: You seem to put JSON and YANG into the same bin but I think they are not. YANG is traditionally used to describe the structure of data that is serialized in XML. (There is also some work to also serialize YANG specified data into JSON.) In other words, YANG is a data modeling language, JSON is an encoding format and so you would need to talk about a JSON schema language here. d) Definition of Active Measurement Method: should we not replace "two" with "at least two"? Section 4 has already some examples why more than two MAs may be involved in an Active Measurement Task. e) Does it make sense to introduce abbreviations for at least some of the terms? This way, we could write MA in emails like this and be sure everybody reads that as Measurement Agent. f) Controller: s/an Instruction/Instructions/ g) Control Protocol: I suggest to rephrase this as follows: Control Protocol: The protocol delivering Instructions from a Controller to a Complete-MA. I think this shorter version is sufficient and avoids confusion (some might read transport protocol that as a layer 4 protocol). h) Information Model: I suggest to rephrase this: Information Model: The protocol neutral definition of the semantics of either the Instruction or the Report. This aligns with RFC 3444. In particular, I disagree that arrangement of fields (the order they appear in and any hierarchy) belong into an Information Model. Note: JSON does not maintain order of the name/value pairs making up an object, see RFC 4627. i) Instruction: I suggest to remove "; a specific instance of the Data Model" given that the definition of "Data Model" is fairly broad. j) Report Protocol: I suggest to rephrase this as follows: Report Protocol: The protocol delivering Reports from a Complete-MA to a Collector. I think this shorter version is sufficient and avoids confusion (some might read transport protocol as a layer 4 protocol). k) I think the last paragraph in section 4 should not be there. In fact, I likely won't agree to it as it goes far beyond talking about terminology. So I propose to remove this paragraph and instead to define the term Bootstrap Protocol, e.g. like this: Bootstrap Protocol: A protocol that initializes a Complete-MA with the information necessary to talk to a Controller. If you want to keep text in section 4, you may mention that there might be different bootstrap protocols and that organizations other than the IETF might design their own bootstrap protocols (e.g., BBF based on TR-069). l) We found it very useful to talk about something we call a Measurement Cycle. Measurement Cycle: A collection of Measurement Results collected for over a given time period and/or for a specific purpose, typically with a consistent set of measurement parameters and a consistent Measurement Schedule. We found it very helpful to have data tagged with a Measurement Cycle identifier when it is received by the collector. This allows to filter out data easily during data analysis without having to track when an updated was actually pushed to an MA. Finally, should we also define the terms Measurement Parameters and Environmental Constraints? They are part of the Instruction according to section 2 but not covered by the terms defined. I also have comments concerning MA, Complete-MA, and Remote MA but I will put those into a different email. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Mon Apr 15 06:21:21 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 A646821F877B for ; Mon, 15 Apr 2013 06:21:21 -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 bv-E7nkzpS9t for ; Mon, 15 Apr 2013 06:21:21 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id CE3A321F93A9 for ; Mon, 15 Apr 2013 06:21:20 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 0defb615.61905940.67936.00-554.185991.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 15 Apr 2013 13:21:20 +0000 (UTC) X-MXL-Hash: 516bfed05d3e17f1-85c23b6973983fb0d43ff1438dd1ee49001ea43e Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fcefb615.0.67928.00-371.185964.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 15 Apr 2013 13:21:20 +0000 (UTC) X-MXL-Hash: 516bfed00e9f413b-8b42de9327ad6f2d291b9a2c5d0a289ab9897da1 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3FDLIK2008242; Mon, 15 Apr 2013 09:21:19 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3FDL9aX008122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 09:21:14 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by alpi131.aldc.att.com (RSA Interceptor); Mon, 15 Apr 2013 14:20:55 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 09:20:55 -0400 From: "STARK, BARBARA H" To: Shane Amante Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIA== Date: Mon, 15 Apr 2013 13:20:54 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> In-Reply-To: <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.60.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=OvD4PVDt c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=xJU_4c9FIKsA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=Hn9H03kOubYbhJOaKYgA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 13:21:21 -0000 Further snipping... > >> However, one addition to this would be that I think it's important to > >> share 'service attributes' from a so-called Measurement Parameter > >> Server to (a) a Measurement Collector (directly) > > > > If the ISP who knows the attributes also manages the Data Collector, th= en > that's intra-domain, and the ISP should be able to figure out how to do t= hat > within there OSS network without help from IETF. Therefore, I don't see a > need for the intra-domain interface to be in lmap phase 1 scope. If the I= SP > does not control the Data Collector, then I think this is a much more dif= ficult > problem to solve, because it involves the ISP knowing that the Data Colle= ctor > controlling entity has the end user's permission to have access to this d= ata. > Because of the need for permission with all of its associated need to > authenticate the Data Collector and "know" that the end user has authoriz= ed > that Data Collector (and allow the end user to revoke that authorization, > change that authorization, etc.), I consider this a much more complex > problem to solve and would prefer for it not to be in lmap phase 1 scope. >=20 > At a minimum, the party (e.g.: regulatory entity) who are receiving the > "service attributes" from several dozen ISPs would want to receive them i= n a > standards-based data model, (e.g.: XML schema), to make processing of the > data contained therein more straightforward. So, for the defined regulat= ory > use case, this should be in scope of "LMAP Phase 1", right? Would the xml representation of service attributes provided to a "Data Coll= ector" be different than the xml representation provided to a MA? That is, = MAs may also need to have a very precise understanding of the service attri= butes being provided to them. Therefore, I saw the creation of an xml repre= sentation for service attributes to an MA to be a very important part of th= at interface. I guess, though, that a Data Collector probably would need ad= ditional metadata, so they could associate a specific set of collected data= with a specific set of service attributes. If you think that the service a= ttributes to Data Collector would drive additional data elements, then I th= ink it would be reasonable to put that interface "in scope", but only for t= he xml, and not for the protocol or authentication/authorization/trust mode= ling. I would also prefer to have just a single set of service attribute xm= l (sufficient for both interfaces), and not separate xml for service attrib= utes to MA vs. service attributes to Data Collector. Barbara From acmorton@att.com Mon Apr 15 06:27: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 56EDB21F8EFD for ; Mon, 15 Apr 2013 06:27:50 -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 ECiVDmQ2P9aU for ; Mon, 15 Apr 2013 06:27:49 -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 11F6921F8E94 for ; Mon, 15 Apr 2013 06:27:49 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id EFDEA120813; Mon, 15 Apr 2013 09:28:12 -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 14ACDE38F2; Mon, 15 Apr 2013 09:19:07 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 15 Apr 2013 09:27:48 -0400 From: "MORTON JR., ALFRED C (AL)" To: Juergen Schoenwaelder , "lmap@ietf.org" Date: Mon, 15 Apr 2013 09:27:47 -0400 Thread-Topic: Measurement Cycle term for draft-eardley-lmap-terminology-00.txt Thread-Index: Ac452ew7j6IB8F7rS4W12y+FBKeSXg== Message-ID: 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] Measurement Cycle term for draft-eardley-lmap-terminology-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, 15 Apr 2013 13:27:50 -0000 Hi Juergen, Thanks for your comments on the Terminology draft. One clarification I'd like to ask (changing subject line): you wrote: > l) We found it very useful to talk about something we call a > Measurement Cycle. >=20 > Measurement Cycle: A collection of Measurement Results collected > for over a given time period and/or for a specific purpose, > typically with a consistent set of measurement parameters and a > consistent Measurement Schedule. >=20 > We found it very helpful to have data tagged with a Measurement > Cycle identifier when it is received by the collector. This allows > to filter out data easily during data analysis without having to > track when an updated was actually pushed to an MA. (in the last line above, what was updated? the definition of the Cycle?) It seems that the Measurement Cycle refers only to a set of Results which are the product of an Instruction (as we've currently defined it): Instruction: The description of Measurement Tasks to perform and the details of the Report to send; a specific instance of the Data Model. The Instruction is sent by a Controller to a Complete-MA. So, if there was a unique identifier for each Instruction, and all MAs operating that Instruction tagged their results with that same identifier when reporting to the Collector, would it satisfy the goal for a=20 Measurement Cycle identifier? Alternatively, we could re-name the term Instruction as Measurement Cycle, if that's more descriptive. regards, Al From philip.eardley@bt.com Mon Apr 15 06:46:25 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 96C2A21F905C for ; Mon, 15 Apr 2013 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 MQLI5-1Uta4Q for ; Mon, 15 Apr 2013 06:46:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3621F8EFD for ; Mon, 15 Apr 2013 06:46:23 -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.279.1; Mon, 15 Apr 2013 14:46:22 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Mon, 15 Apr 2013 14:46:22 +0100 From: To: , Date: Mon, 15 Apr 2013 14:46:20 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac45iCAszcZvSJzUTKSAfp0GlSaU0wAVkkCA Message-ID: <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> In-Reply-To: <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 13:46:25 -0000 >=20 > FWIW, I'm not suggesting any such thing. Rather, consider the scenario > where an entire neighborhood loses commercial power and thousands (or, > 10s of 1,000's) of the CPE devices power-on at the same time. We > definitely do not want all of those CPE's (and, more specifically the > MA's on them) to all re-initiate their tests and cause catastrophic > problems in the network. Hence, we definitely will need a CAC > mechanism at the MA's to ensure this doesn't happen. >=20 I agree we don't want this to happen but I don't see why we need admission = control to solve it. After a power outage a number of things could happen: - the MA still has its Measurement Schedule. It just re-starts running test= s (Measurement Tasks) - the MA has lost its Measurement Schedule, or it has expired. It simply wa= its to hear from the Controller with a new one - the MA has forgotten who its Controller is. The initialisation process ne= eds to run again (it needs to hear from the 'Management Server' about who i= ts controller is and security details ('Management Server' =3D term from th= e Broadband forum liaison). This is probably a BBF defined process (at leas= t for ISP-controlled MA). In any case, it's only this (re-)initialisation o= r re-homing process that needs some kind of load control (and which could b= e handled by a back-off algorithm rather than CAC) From j.schoenwaelder@jacobs-university.de Mon Apr 15 06:55:35 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 ACC3921F93D3 for ; Mon, 15 Apr 2013 06:55:35 -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=[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 5enJpKDn88nQ for ; Mon, 15 Apr 2013 06:55:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 29D0D21F93E3 for ; Mon, 15 Apr 2013 06:55:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E82DD20BD8; Mon, 15 Apr 2013 15:55:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8B8Q48bZ2yyQ; Mon, 15 Apr 2013 15:55:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 913DE20AFE; Mon, 15 Apr 2013 15:55:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9A9425A3DE0; Mon, 15 Apr 2013 15:55:36 +0200 (CEST) Date: Mon, 15 Apr 2013 15:55:36 +0200 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED C (AL)" Message-ID: <20130415135536.GA23933@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED C (AL)" , "lmap@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "lmap@ietf.org" Subject: Re: [lmap] Measurement Cycle term for draft-eardley-lmap-terminology-00.txt 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: Mon, 15 Apr 2013 13:55:35 -0000 On Mon, Apr 15, 2013 at 09:27:47AM -0400, MORTON JR., ALFRED C (AL) wrote: > Hi Juergen, > > Thanks for your comments on the Terminology draft. > One clarification I'd like to ask (changing subject line): > > you wrote: > > l) We found it very useful to talk about something we call a > > Measurement Cycle. > > > > Measurement Cycle: A collection of Measurement Results collected > > for over a given time period and/or for a specific purpose, > > typically with a consistent set of measurement parameters and a > > consistent Measurement Schedule. > > > > We found it very helpful to have data tagged with a Measurement > > Cycle identifier when it is received by the collector. This allows > > to filter out data easily during data analysis without having to > > track when an updated was actually pushed to an MA. > > (in the last line above, what was updated? the definition of the Cycle?) > > It seems that the Measurement Cycle refers only to a set of Results > which are the product of an Instruction (as we've currently defined it): > > Instruction: The description of Measurement Tasks to perform and the > details of the Report to send; a specific instance of the Data Model. > The Instruction is sent by a Controller to a Complete-MA. > > So, if there was a unique identifier for each Instruction, and all MAs > operating that Instruction tagged their results with that same identifier > when reporting to the Collector, would it satisfy the goal for a > Measurement Cycle identifier? > > Alternatively, we could re-name the term Instruction as Measurement Cycle, > if that's more descriptive. I think Instruction is a good term, I would not rename it. The way we use a Measurement Cycle it is really a tag carried with an Instruction to a device. Now, if a device restarts and looses context, it will get a new Instruction to reinstall the state driving the measurements - however as long as we are in the same measurement cycle, this new Instruction will carry the same tag. There might also be Instruction within the same Measurement Cycle that reschedule measurements without really affecting the measurement itself (e.g. you move tests forward or backward in the schedule to make room for other measurements). Hence, I think a Measurement Cycle has not a 1:1 relationship to an Instruction but is really a tag carried in an Instruction and echoed back to the Collector. /js -- 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 Mon Apr 15 07:04:11 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 F3BB821F93A5 for ; Mon, 15 Apr 2013 07:04:10 -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=[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 10ce2s5tFsvU for ; Mon, 15 Apr 2013 07:04:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3623121F93BB for ; Mon, 15 Apr 2013 07:04:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36F7E20BD8; Mon, 15 Apr 2013 16:04:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tDnpz3Pgj7_2; Mon, 15 Apr 2013 16:04:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 738B520BCD; Mon, 15 Apr 2013 16:04:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6A20D25A3F4E; Mon, 15 Apr 2013 16:04:15 +0200 (CEST) Date: Mon, 15 Apr 2013 16:04:15 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130415140415.GC23933@elstar.local> Mail-Followup-To: philip.eardley@bt.com, shane@castlepoint.net, bs7652@att.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: shane@castlepoint.net, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-Use Cases 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: Mon, 15 Apr 2013 14:04:11 -0000 On Mon, Apr 15, 2013 at 02:46:20PM +0100, philip.eardley@bt.com wrote: > - the MA has forgotten who its Controller is. The initialisation process needs to run again (it needs to hear from the 'Management Server' about who its controller is and security details ('Management Server' = term from the Broadband forum liaison). This is probably a BBF defined process (at least for ISP-controlled MA). Question: Do ISPs using (TV) cable network technology deploy BBF technology or do they have their own technology to control the cable modems? My question is whether ISP => BBF technology in the access network is generally true. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bs7652@att.com Mon Apr 15 07:42:28 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 477DD21F93E1 for ; Mon, 15 Apr 2013 07:42:28 -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 2gpE-uZ6Qiv4 for ; Mon, 15 Apr 2013 07:42:27 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id DA74921F93BB for ; Mon, 15 Apr 2013 07:42:17 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 9c11c615.2aaad420c940.129778.00-585.358816.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 15 Apr 2013 14:42:17 +0000 (UTC) X-MXL-Hash: 516c11c97302781f-b648857c1b84ae08090152c984c313796311dec9 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 7c11c615.0.129760.00-395.358754.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 15 Apr 2013 14:42:17 +0000 (UTC) X-MXL-Hash: 516c11c976a2f43a-f9566090537a49deca91170d0df8abc283ed901c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3FEgFWo026308; Mon, 15 Apr 2013 10:42:15 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3FEg5Mu026146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 10:42:10 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Mon, 15 Apr 2013 15:41:53 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 10:41:53 -0400 From: "STARK, BARBARA H" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAFeB0AAAAoDCAAAgh/7A= Date: Mon, 15 Apr 2013 14:41:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A671F@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <20130415140415.GC23933@elstar.local> In-Reply-To: <20130415140415.GC23933@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.164.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=K9KV6VqI c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=pTt7bGbMxHAA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=e9qsufxtAAAA:8 a=XKfbYx4oAAAA:8] X-AnalysisOut: [ a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=1rFDfcjwJN7vtPDdAtgA:] X-AnalysisOut: [9 a=CjuIK1q_8ugA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=] X-AnalysisOut: [4CLKj2Bp5_UA:10 a=W1qU_X6G3J8A:10 a=uI1Or78iWTcA:10 a=lZB8] X-AnalysisOut: [15dzVvQA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 14:42:28 -0000 No. Not all ISPs use BBF-defined architectures or technology. In my experience, the main protocols used by service providers to manage de= vices are BBF TR-069 (aka CWMP), SNMP, and OMA-DM (for mobile devices). But my own read on Phil's comment is to interpret it more generically as: T= his initialization process is probably not something that lmap needs to dea= l with in Phase 1, because different entities will want to do things differ= ent ways, and lmap may not have the operational experience during Phase 1 t= o recommend one way over another. Which is a sentiment I would agree with. Barbara > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, April 15, 2013 10:04 AM > To: philip.eardley@bt.com > Cc: shane@castlepoint.net; STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > On Mon, Apr 15, 2013 at 02:46:20PM +0100, philip.eardley@bt.com wrote: >=20 > > - the MA has forgotten who its Controller is. The initialisation proces= s needs > to run again (it needs to hear from the 'Management Server' about who its > controller is and security details ('Management Server' =3D term from the > Broadband forum liaison). This is probably a BBF defined process (at leas= t for > ISP-controlled MA). >=20 > Question: Do ISPs using (TV) cable network technology deploy BBF > technology or do they have their own technology to control the cable > modems? My question is whether ISP =3D> BBF technology in the access > network is generally true. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From shane@castlepoint.net Mon Apr 15 10:01: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 3386021F964B for ; Mon, 15 Apr 2013 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 C5sS-6RNrJOB for ; Mon, 15 Apr 2013 10:01:35 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id AF46221F9649 for ; Mon, 15 Apr 2013 10:01:35 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 5629A300054 for ; Mon, 15 Apr 2013 17:01:35 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 80E29300021; Mon, 15 Apr 2013 11:01:33 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 15 Apr 2013 11:01:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 15 11:01:35 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516c326f42072431714263 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, devices+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, that+are, 0.01000, On+Apr, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, the+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, Subject*LMAP+situation, 0.01000, the+#+#+the, 0.01000, the+#+#+the, 0.01000, Subject*Re+#+LMAP, 0.01000, to+#+in, 0.01000, the+#+to, 0.01000, com+wrote, 0.01000, Subject*Re+#+#+#+Q1-Use, 0.01000, the+MA, 0.01000, the+MA, 0.01000, Subject*situation+#+Cases, 0.01000, network+#+#+#+will, 0.01000, Subject*LMAP+#+Q1-Use, 0.01000, to+#+a, 0.01000, Mime-Version*X+#+#+1503, 0.01000 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 17:01:36 -0000 Phil, On Apr 15, 2013, at 7:46 AM, wrote: >> FWIW, I'm not suggesting any such thing. Rather, consider the = scenario >> where an entire neighborhood loses commercial power and thousands = (or, >> 10s of 1,000's) of the CPE devices power-on at the same time. We >> definitely do not want all of those CPE's (and, more specifically the >> MA's on them) to all re-initiate their tests and cause catastrophic >> problems in the network. Hence, we definitely will need a CAC >> mechanism at the MA's to ensure this doesn't happen. >>=20 >=20 > I agree we don't want this to happen but I don't see why we need = admission control to solve it. >=20 > After a power outage a number of things could happen: A number of things could happen, but the question is more likely: what = do we (LMAP, if/when a WG is formed) want to *recommend should/must = happen*? Presumably, as part of a "Deployment BCP" (???) (or, an LMAP = Architecture Doc) we'd want to recommend what is considered a Best = Practice at the MA (and, other components of the overall Architecture). > - the MA still has its Measurement Schedule. It just re-starts running = tests (Measurement Tasks) > - the MA has lost its Measurement Schedule, or it has expired. It = simply waits to hear from the Controller with a new one > - the MA has forgotten who its Controller is. The initialisation = process needs to run again (it needs to hear from the 'Management = Server' about who its controller is and security details ('Management = Server' =3D term from the Broadband forum liaison). This is probably a = BBF defined process (at least for ISP-controlled MA). In any case, it's = only this (re-)initialisation or re-homing process that needs some kind = of load control (and which could be handled by a back-off algorithm = rather than CAC) Those are certainly valid suggestions. However, we would still want to = have a (relatively) straightforward CAC mechanism between the MA (CPE = device) and Measurement Server? At the end of the day, we don't want to = be in a situation where a bunch of MA's (due to an unfortunate sequence = of events), that are running tests autonomously, all end up = over-subscribing a single Measurement Server, thus making any = measurement results captured during that time to be considered suspect = or, worse, invalid. -shane= From acmorton@att.com Mon Apr 15 10:32:11 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 B2D9821F9615 for ; Mon, 15 Apr 2013 10:32:11 -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 AgMIewlhzWYG for ; Mon, 15 Apr 2013 10:32:10 -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 2DE7E21F9600 for ; Mon, 15 Apr 2013 10:32:10 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 64E0F120A31; Mon, 15 Apr 2013 13:32:34 -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 C830DE36D3; Mon, 15 Apr 2013 13:23:27 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 15 Apr 2013 13:32:09 -0400 From: "MORTON JR., ALFRED C (AL)" To: Shane Amante , "philip.eardley@bt.com" Date: Mon, 15 Apr 2013 13:32:08 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac45+ugvajQjxBi7S6SM+AF7RntpNAAAr9+g Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> In-Reply-To: <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> 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: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 17:32:11 -0000 Hi Shane, you wrote: > Those are certainly valid suggestions. However, we would still want to > have a (relatively) straightforward CAC mechanism between the MA (CPE > device) and Measurement Server? At the end of the day, we don't want to > be in a situation where a bunch of MA's (due to an unfortunate sequence o= f > events), that are running tests autonomously, all end up over-subscribing > a single Measurement Server, thus making any measurement results captured > during that time to be considered suspect or, worse, invalid. >=20 The CAC function (between MAs, one is your Server device above)=20 could be accomplished by a dedicated testing protocol, if I understand the requirement here, using the pre-test control exchanges. A MA can reject testing session requests when it has no remaining resources.=20 This seems to be a critical part of LMAP systems, and certainly needs to be mentioned in the framework draft, but it may simply end-up as a requirement= =20 for the active test protocol chosen and for the CAC outcome communicated by= the Complete MA to the Controller/Collector in the appropriate protocol. hope this helps, Al=20 > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Monday, April 15, 2013 1:02 PM > To: philip.eardley@bt.com > Cc: STARK, BARBARA H; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > Phil, >=20 > On Apr 15, 2013, at 7:46 AM, wrote: > >> FWIW, I'm not suggesting any such thing. Rather, consider the scenari= o > >> where an entire neighborhood loses commercial power and thousands (or, > >> 10s of 1,000's) of the CPE devices power-on at the same time. We > >> definitely do not want all of those CPE's (and, more specifically the > >> MA's on them) to all re-initiate their tests and cause catastrophic > >> problems in the network. Hence, we definitely will need a CAC > >> mechanism at the MA's to ensure this doesn't happen. > >> > > > > I agree we don't want this to happen but I don't see why we need > admission control to solve it. > > > > After a power outage a number of things could happen: >=20 > A number of things could happen, but the question is more likely: what do > we (LMAP, if/when a WG is formed) want to *recommend should/must happen*? > Presumably, as part of a "Deployment BCP" (???) (or, an LMAP Architecture > Doc) we'd want to recommend what is considered a Best Practice at the MA > (and, other components of the overall Architecture). >=20 >=20 > > - the MA still has its Measurement Schedule. It just re-starts running > tests (Measurement Tasks) > > - the MA has lost its Measurement Schedule, or it has expired. It simpl= y > waits to hear from the Controller with a new one > > - the MA has forgotten who its Controller is. The initialisation proces= s > needs to run again (it needs to hear from the 'Management Server' about > who its controller is and security details ('Management Server' =3D term > from the Broadband forum liaison). This is probably a BBF defined process > (at least for ISP-controlled MA). In any case, it's only this (re- > )initialisation or re-homing process that needs some kind of load control > (and which could be handled by a back-off algorithm rather than CAC) >=20 > Those are certainly valid suggestions. However, we would still want to > have a (relatively) straightforward CAC mechanism between the MA (CPE > device) and Measurement Server? At the end of the day, we don't want to > be in a situation where a bunch of MA's (due to an unfortunate sequence o= f > events), that are running tests autonomously, all end up over-subscribing > a single Measurement Server, thus making any measurement results captured > during that time to be considered suspect or, worse, invalid. >=20 > -shane > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Mon Apr 15 10:33: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 C957A21F9452 for ; Mon, 15 Apr 2013 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=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 J-mk3r4s0yVB for ; Mon, 15 Apr 2013 10:33:42 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id AF68B21F8C55 for ; Mon, 15 Apr 2013 10:33:41 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 15 Apr 2013 18:33:34 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 15 Apr 2013 18:33:34 +0100 From: To: Date: Mon, 15 Apr 2013 18:33:33 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac45+uRGj3wgE/sHSKO/DnC/w2ynRwAABcrg Message-ID: <9510D26531EF184D9017DF24659BB87F34565F8B66@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> In-Reply-To: <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 17:33:42 -0000 Hi Shane, I hadn't thought about the power outage example before. So I'm interested w= hether you need admission control to cope with that problem. So far I don't= think you do. On the wider problem > to be in a situation where a bunch of MA's (due to an unfortunate > sequence of events), that are running tests autonomously, all end up > over-subscribing a single Measurement Server, thus making any > measurement results captured during that time to be considered suspect > or, worse, invalid. Agree in principle there could be a problem of overloading a measurement se= rver (Remote-MA if you like terminology in http://datatracker.ietf.org/doc/= draft-eardley-lmap-terminology/) Alternatives to admission control include - Measurement Method includes a back-off algorithm (I got no response so I'= ll stop sending big file) - Remote-MA uses standard load balancing techniques - Remote-MA ignores the other MA (doesn't respond to request to send big fi= le) - Remote-MA's site temporarily blocks 'misbehaving' domain (ie domain initi= ating too many Measurement Tasks at the moment) - MA runs a sanity check with Remote-MA first time performs a particular Me= asurement Method with it (if you like, a one-off admission control) - operational advice and good practice (eg start individual Measurement Tas= ks at a slightly randomised time; keep measurement traffic to -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: 15 April 2013 18:02 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > Phil, >=20 > On Apr 15, 2013, at 7:46 AM, wrote: > >> FWIW, I'm not suggesting any such thing. Rather, consider the > >> scenario where an entire neighborhood loses commercial power and > >> thousands (or, 10s of 1,000's) of the CPE devices power-on at the > >> same time. We definitely do not want all of those CPE's (and, more > >> specifically the MA's on them) to all re-initiate their tests and > >> cause catastrophic problems in the network. Hence, we definitely > >> will need a CAC mechanism at the MA's to ensure this doesn't happen. > >> > > > > I agree we don't want this to happen but I don't see why we need > admission control to solve it. > > > > After a power outage a number of things could happen: >=20 > A number of things could happen, but the question is more likely: what > do we (LMAP, if/when a WG is formed) want to *recommend should/must > happen*? Presumably, as part of a "Deployment BCP" (???) (or, an LMAP > Architecture Doc) we'd want to recommend what is considered a Best > Practice at the MA (and, other components of the overall Architecture). >=20 >=20 > > - the MA still has its Measurement Schedule. It just re-starts > running > > tests (Measurement Tasks) > > - the MA has lost its Measurement Schedule, or it has expired. It > > simply waits to hear from the Controller with a new one > > - the MA has forgotten who its Controller is. The initialisation > > process needs to run again (it needs to hear from the 'Management > > Server' about who its controller is and security details ('Management > > Server' =3D term from the Broadband forum liaison). This is probably a > > BBF defined process (at least for ISP-controlled MA). In any case, > > it's only this (re-)initialisation or re-homing process that needs > > some kind of load control (and which could be handled by a back-off > > algorithm rather than CAC) >=20 > Those are certainly valid suggestions. However, we would still want to > have a (relatively) straightforward CAC mechanism between the MA (CPE > device) and Measurement Server? At the end of the day, we don't want > to be in a situation where a bunch of MA's (due to an unfortunate > sequence of events), that are running tests autonomously, all end up > over-subscribing a single Measurement Server, thus making any > measurement results captured during that time to be considered suspect > or, worse, invalid. >=20 > -shane From shane@castlepoint.net Mon Apr 15 11:01: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 E3A7921F9615 for ; Mon, 15 Apr 2013 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 Ajt5yYIkUqRl for ; Mon, 15 Apr 2013 11:01:36 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 512FD21F9610 for ; Mon, 15 Apr 2013 11:01:36 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id EE0CF300078 for ; Mon, 15 Apr 2013 18:01:35 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 5EC83300025; Mon, 15 Apr 2013 12:01:34 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: Date: Mon, 15 Apr 2013 12:01:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6A0CBEF1-9F8B-464E-9E06-CD0C6664AA73@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> To: "MORTON JR., ALFRED C (AL)" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 15 12:01:35 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516c407f42072049811285 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+or, 0.01000, devices+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, that+are, 0.01000, that+are, 0.01000, I'm+#+suggesting, 0.01000, between+#+MA, 0.01000, between+#+MA, 0.01000, could+#+#+#+of, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, to+#+this, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, of+things, 0.01000, of+things, 0.01000, MA's+to, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, and+other, 0.01000, the+#+#+#+to, 0.01000, From*Amante+shane, 0.01000 Cc: "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 18:01:37 -0000 Al, On Apr 15, 2013, at 11:32 AM, "MORTON JR., ALFRED C (AL)" = wrote: > Hi Shane, > you wrote: >> Those are certainly valid suggestions. However, we would still want = to >> have a (relatively) straightforward CAC mechanism between the MA (CPE >> device) and Measurement Server? At the end of the day, we don't want = to >> be in a situation where a bunch of MA's (due to an unfortunate = sequence of >> events), that are running tests autonomously, all end up = over-subscribing >> a single Measurement Server, thus making any measurement results = captured >> during that time to be considered suspect or, worse, invalid. >>=20 >=20 > The CAC function (between MAs, one is your Server device above)=20 > could be accomplished by a dedicated testing protocol, if I = understand > the requirement here, using the pre-test control exchanges. A MA can = reject > testing session requests when it has no remaining resources. I completely agree. =20 > This seems to be a critical part of LMAP systems, and certainly needs = to be > mentioned in the framework draft, but it may simply end-up as a = requirement=20 > for the active test protocol chosen and for the CAC outcome = communicated by the > Complete MA to the Controller/Collector in the appropriate protocol. Agreed. -shane > hope this helps, > Al=20 >=20 >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf = Of >> Shane Amante >> Sent: Monday, April 15, 2013 1:02 PM >> To: philip.eardley@bt.com >> Cc: STARK, BARBARA H; lmap@ietf.org >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >>=20 >> Phil, >>=20 >> On Apr 15, 2013, at 7:46 AM, wrote: >>>> FWIW, I'm not suggesting any such thing. Rather, consider the = scenario >>>> where an entire neighborhood loses commercial power and thousands = (or, >>>> 10s of 1,000's) of the CPE devices power-on at the same time. We >>>> definitely do not want all of those CPE's (and, more specifically = the >>>> MA's on them) to all re-initiate their tests and cause catastrophic >>>> problems in the network. Hence, we definitely will need a CAC >>>> mechanism at the MA's to ensure this doesn't happen. >>>>=20 >>>=20 >>> I agree we don't want this to happen but I don't see why we need >> admission control to solve it. >>>=20 >>> After a power outage a number of things could happen: >>=20 >> A number of things could happen, but the question is more likely: = what do >> we (LMAP, if/when a WG is formed) want to *recommend should/must = happen*? >> Presumably, as part of a "Deployment BCP" (???) (or, an LMAP = Architecture >> Doc) we'd want to recommend what is considered a Best Practice at the = MA >> (and, other components of the overall Architecture). >>=20 >>=20 >>> - the MA still has its Measurement Schedule. It just re-starts = running >> tests (Measurement Tasks) >>> - the MA has lost its Measurement Schedule, or it has expired. It = simply >> waits to hear from the Controller with a new one >>> - the MA has forgotten who its Controller is. The initialisation = process >> needs to run again (it needs to hear from the 'Management Server' = about >> who its controller is and security details ('Management Server' =3D = term >> from the Broadband forum liaison). This is probably a BBF defined = process >> (at least for ISP-controlled MA). In any case, it's only this (re- >> )initialisation or re-homing process that needs some kind of load = control >> (and which could be handled by a back-off algorithm rather than CAC) >>=20 >> Those are certainly valid suggestions. However, we would still want = to >> have a (relatively) straightforward CAC mechanism between the MA (CPE >> device) and Measurement Server? At the end of the day, we don't want = to >> be in a situation where a bunch of MA's (due to an unfortunate = sequence of >> events), that are running tests autonomously, all end up = over-subscribing >> a single Measurement Server, thus making any measurement results = captured >> during that time to be considered suspect or, worse, invalid. >>=20 >> -shane >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >=20 From shane@castlepoint.net Mon Apr 15 11:29:17 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 A707E21F96BC for ; Mon, 15 Apr 2013 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.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 hkwaNTsRKvXD for ; Mon, 15 Apr 2013 11:29:17 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9021F96BB for ; Mon, 15 Apr 2013 11:29:16 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id B3F48300077 for ; Mon, 15 Apr 2013 18:29:16 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id B929A300025; Mon, 15 Apr 2013 12:29:15 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F8B66@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 15 Apr 2013 12:29:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <333D2CB9-0B29-4791-B2C9-4592369C0A6E@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34565F8B66@EMV65-UKRD.domain1.systemhost.net> To: philip.eardley@bt.com X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 15 12:29:16 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516c46fc42076507418894 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, loses+commercial, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+or, 0.01000, and+#+could, 0.01000, consider+#+#+#+an, 0.01000, devices+#+#+#+the, 0.01000, initiate+#+tests, 0.01000, and+#+#+#+the, 0.01000, and+#+#+#+the, 0.01000, that+are, 0.01000, that+are, 0.01000, I'm+#+suggesting, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Rather+#+#+scenario, 0.01000, between+#+MA, 0.01000, of+#+CPE, 0.01000, the+#+#+We, 0.01000, neighborhood+#+#+#+and, 0.01000, could+#+#+#+of, 0.01000, could+#+#+#+of, 0.01000, of+1, 0.01000, cause+#+problems, 0.01000, power+#+thousands, 0.01000 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 18:29:17 -0000 Hi Phil, On Apr 15, 2013, at 11:33 AM, philip.eardley@bt.com wrote: > Hi Shane, > I hadn't thought about the power outage example before. So I'm = interested whether you need admission control to cope with that problem. = So far I don't think you do. >=20 > On the wider problem >> to be in a situation where a bunch of MA's (due to an unfortunate >> sequence of events), that are running tests autonomously, all end up >> over-subscribing a single Measurement Server, thus making any >> measurement results captured during that time to be considered = suspect >> or, worse, invalid. >=20 > Agree in principle there could be a problem of overloading a = measurement server (Remote-MA if you like terminology in = http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology/) >=20 >=20 > Alternatives to admission control include > - Measurement Method includes a back-off algorithm (I got no response = so I'll stop sending big file) > - Remote-MA uses standard load balancing techniques > - Remote-MA ignores the other MA (doesn't respond to request to send = big file) > - Remote-MA's site temporarily blocks 'misbehaving' domain (ie domain = initiating too many Measurement Tasks at the moment) > - MA runs a sanity check with Remote-MA first time performs a = particular Measurement Method with it (if you like, a one-off admission = control) > - operational advice and good practice (eg start individual = Measurement Tasks at a slightly randomised time; keep measurement = traffic to - a Measurement Method that creates a lot of load must include an = initial msg from MA that Remote-MA can respond with an 'overloaded' = error code [this is effectively admission control, but devolving the = problem to the Measurement Method] >=20 > So there seem several alternatives to alleviate the risk of overload.=20= > BTW, I'm not sure what the right answer is - I suspect several = techniques should be used in combination. > Not yet convinced either for or against devising a special admission = control protocol=20 >=20 > Also admission protocol > - only protects the Remote-MA (not its network);=20 > - itself loads the Remote-MA - mustn't be limiting factor on = Remote-MA's capacity > - is not applicable if the Remote-MA isn't lmap-enabled (say it's a = DNS server) I'd agree with most of your points above. At this point, I'm not trying = to suggest any specific technical solution(s). Instead, I'm attempting = to clarify & suggest requirements for a (hopefully) forthcoming LMAP WG = and it's short-term deliverables/scope, (e.g.: "LMAP Phase 1" as we've = been calling it): a) An "admission control" method between two MA's that communicate = directly with each other is REQUIRED, (e.g.: Measurement Agent on a CPE = to a Measurement Agent on a 'server'); b) The aforementioned "admission control" method MUST be the same for = Intra-Domain and Inter-Domain MA's. Note, at this point, I don't have an opinion on whether a "special/new" = protocol is required to achieve the above -or- if the solution becomes, = as Al states, an aspect of an (existing?) "pre-test protocol". I = believe the latter would certainly be preferred, but for now I'm trying = to phrase the above requirements as I did to avoid getting into = solutions prematurely. Is there a particular draft you, Al or Barbara can suggest we should = consider incorporating these into, for now? -shane > phil >=20 >=20 >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: 15 April 2013 18:02 >> To: Eardley,PL,Philip,TUB8 R >> Cc: bs7652@att.com; lmap@ietf.org >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >>=20 >> Phil, >>=20 >> On Apr 15, 2013, at 7:46 AM, wrote: >>>> FWIW, I'm not suggesting any such thing. Rather, consider the >>>> scenario where an entire neighborhood loses commercial power and >>>> thousands (or, 10s of 1,000's) of the CPE devices power-on at the >>>> same time. We definitely do not want all of those CPE's (and, more >>>> specifically the MA's on them) to all re-initiate their tests and >>>> cause catastrophic problems in the network. Hence, we definitely >>>> will need a CAC mechanism at the MA's to ensure this doesn't = happen. >>>>=20 >>>=20 >>> I agree we don't want this to happen but I don't see why we need >> admission control to solve it. >>>=20 >>> After a power outage a number of things could happen: >>=20 >> A number of things could happen, but the question is more likely: = what >> do we (LMAP, if/when a WG is formed) want to *recommend should/must >> happen*? Presumably, as part of a "Deployment BCP" (???) (or, an = LMAP >> Architecture Doc) we'd want to recommend what is considered a Best >> Practice at the MA (and, other components of the overall = Architecture). >>=20 >>=20 >>> - the MA still has its Measurement Schedule. It just re-starts >> running >>> tests (Measurement Tasks) >>> - the MA has lost its Measurement Schedule, or it has expired. It >>> simply waits to hear from the Controller with a new one >>> - the MA has forgotten who its Controller is. The initialisation >>> process needs to run again (it needs to hear from the 'Management >>> Server' about who its controller is and security details = ('Management >>> Server' =3D term from the Broadband forum liaison). This is probably = a >>> BBF defined process (at least for ISP-controlled MA). In any case, >>> it's only this (re-)initialisation or re-homing process that needs >>> some kind of load control (and which could be handled by a back-off >>> algorithm rather than CAC) >>=20 >> Those are certainly valid suggestions. However, we would still want = to >> have a (relatively) straightforward CAC mechanism between the MA (CPE >> device) and Measurement Server? At the end of the day, we don't want >> to be in a situation where a bunch of MA's (due to an unfortunate >> sequence of events), that are running tests autonomously, all end up >> over-subscribing a single Measurement Server, thus making any >> measurement results captured during that time to be considered = suspect >> or, worse, invalid. >>=20 >> -shane >=20 From shane@castlepoint.net Mon Apr 15 11:47:10 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 B6A7521F96C1 for ; Mon, 15 Apr 2013 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 MWBrBaNApnty for ; Mon, 15 Apr 2013 11:47:10 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3864721F96A0 for ; Mon, 15 Apr 2013 11:47:10 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 0173F300074 for ; Mon, 15 Apr 2013 18:47:09 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 6CC85300025; Mon, 15 Apr 2013 12:47:09 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> Date: Mon, 15 Apr 2013 12:47:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 15 12:47:09 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516c4b2d42075436819134 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+to, 0.01000, MA+to, 0.01000, to+#+the, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, To*STARK+BARBARA, 0.01000, the+#+#+#+I, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, bs7652+#+#+wrote, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, Apr+#+#+#+7, 0.01000, with+#+of, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, the+end, 0.01000, the+end, 0.01000, a+single, 0.01000, the+#+#+#+to, 0.01000, the+#+#+#+to, 0.01000, From*Amante+shane, 0.01000, the+#+Collector, 0.01000, the+#+Collector, 0.01000, Subject*LMAP+situation, 0.01000, and+the, 0.01000, Subject*Re+#+LMAP, 0.01000 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 18:47:10 -0000 Barbara, On Apr 15, 2013, at 7:20 AM, "STARK, BARBARA H" wrote: > Further snipping... >=20 >>>> However, one addition to this would be that I think it's important = to >>>> share 'service attributes' from a so-called Measurement Parameter >>>> Server to (a) a Measurement Collector (directly) >>>=20 >>> If the ISP who knows the attributes also manages the Data Collector, = then >> that's intra-domain, and the ISP should be able to figure out how to = do that >> within there OSS network without help from IETF. Therefore, I don't = see a >> need for the intra-domain interface to be in lmap phase 1 scope. If = the ISP >> does not control the Data Collector, then I think this is a much more = difficult >> problem to solve, because it involves the ISP knowing that the Data = Collector >> controlling entity has the end user's permission to have access to = this data. >> Because of the need for permission with all of its associated need to >> authenticate the Data Collector and "know" that the end user has = authorized >> that Data Collector (and allow the end user to revoke that = authorization, >> change that authorization, etc.), I consider this a much more complex >> problem to solve and would prefer for it not to be in lmap phase 1 = scope. >>=20 >> At a minimum, the party (e.g.: regulatory entity) who are receiving = the >> "service attributes" from several dozen ISPs would want to receive = them in a >> standards-based data model, (e.g.: XML schema), to make processing of = the >> data contained therein more straightforward. So, for the defined = regulatory >> use case, this should be in scope of "LMAP Phase 1", right? >=20 > Would the xml representation of service attributes provided to a "Data = Collector" be different than the xml representation provided to a MA? = That is, MAs may also need to have a very precise understanding of the = service attributes being provided to them. Therefore, I saw the creation = of an xml representation for service attributes to an MA to be a very = important part of that interface. I guess, though, that a Data Collector = probably would need additional metadata, so they could associate a = specific set of collected data with a specific set of service = attributes. If you think that the service attributes to Data Collector = would drive additional data elements, then I think it would be = reasonable to put that interface "in scope", but only for the xml, and = not for the protocol or authentication/authorization/trust modeling. I = would also prefer to have just a single set of service attribute xml = (sufficient for both interfaces), and not separate xml for service = attributes to MA vs.=20 > service attributes to Data Collector. Agreed. -shane From j.schoenwaelder@jacobs-university.de Mon Apr 15 12:14:57 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 85F8821F9452 for ; Mon, 15 Apr 2013 12:14:57 -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=[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 X2Omz9BbRHha for ; Mon, 15 Apr 2013 12:14:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B92A721F942C for ; Mon, 15 Apr 2013 12:14:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E0EE20A13; Mon, 15 Apr 2013 21:14:56 +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 kkOcbgX5H8Ff; Mon, 15 Apr 2013 21:14:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADD7A209D7; Mon, 15 Apr 2013 21:14:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5328325A4DCB; Mon, 15 Apr 2013 21:15:00 +0200 (CEST) Date: Mon, 15 Apr 2013 21:14:59 +0200 From: Juergen Schoenwaelder To: lmap@ietf.org Message-ID: <20130415191457.GA25223@elstar.local> Mail-Followup-To: lmap@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-00.txt 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: Mon, 15 Apr 2013 19:14:57 -0000 Hi, I have an issue with the terms Measurement Agent, Remote Measurement Agent and Complete Measurement Agents as defined in the I-D. I do not really see why we need all three and I am concerned that we make the most frequently needed term the most complex to write and spell out. My understanding is that LMAP defines Control Protocol and a Report Protocol between a Controller / Collector and - well the rather ugly term "Complete Measurement Agent". Note that these specifications will have to talk a lot about this entity - which has the weirdest and longest name. Furthermore, I see little value of the term Measurement Agent because the Remote Measurement Agents and the Complete Measurement Agents really do very different things from an LMAP protocol perspective (The Remote Measurement Agent does not nothing, the Complete Measurement Agent does all.) I also think the current definition of Measurement Agent is likely misleading - instead of 'performs' one should perhaps use 'is involved in'. (If I throw a packet at a DNS server of an HTTP server, I consider this server to be involved in the test, not to perform this test.) Bottom line is that I think we simplify the terminology a lot if we remove the current definition of a Measurement Agent, a Complete Measurement Agent, and Remote Measurement Agent and instead use this: Measurement Agent: A function that receives Instructions from a Controller, performs Measurement Tasks and reports Measurement Results to a Collector. Measurement Peer: A function that receives control messages and test packets from a Measurement Agent and may reply to the Measurement Agent as defined by the Measurement Method. Well, Measurement Peer is a new invention and not necessarily the best term one could come up with. In other contexts, this has been called a measurement server (I tried to avoid 'server'). The key of this note, however, is to just have to two simple to understand and use terms and to avoid a generalization that I do not see useful for writing specs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Mon Apr 15 14:06:55 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 C885121F9601 for ; Mon, 15 Apr 2013 14:06:55 -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 OMi2XJUNXZ3c for ; Mon, 15 Apr 2013 14:06:55 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id E2EEC21F95EE for ; Mon, 15 Apr 2013 14:06:54 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3FL6neV004135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 15:06:50 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id A05A91E009B; Mon, 15 Apr 2013 15:06:44 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 689D81E0065; Mon, 15 Apr 2013 15:06:44 -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 r3FL6hdS020307; Mon, 15 Apr 2013 16:06:43 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r3FL6hVY020289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 16:06:43 -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, 15 Apr 2013 16:06:43 -0500 From: "Bugenhagen, Michael K" To: "'Shane Amante'" , "STARK, BARBARA H" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1Xg Date: Mon, 15 Apr 2013 21:06:42 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> In-Reply-To: <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> 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 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Mon, 15 Apr 2013 21:06:55 -0000 Shane, Barbara, On the architecture including some sort of ISP attribute information ---=20 =20 We could assume the tests are run separately and merged with ISP infor= mation, or we could assume the probe gathers service environment informatio= n and includes it with every test result (does a real-time encapsulation). Using the post processing merge framework has significant challenges, some = of which require local network environment validation regardless. Examples - =20 1) Matching the test probe results to the ISP service attributes - a) Increases the Challenges associated with creating anonymous data=20 b) Doesn't reflect when a customer moves a box from one service to another= (it happens) ** Nothing I know reflects b) other than the probe validating it's where i= t should be (what's the environment) so this is required.... =20 =09 2) Service Environment changes - When a service environment changes (enforcement of a bandwidth cap - mob= ile, provisioning speed change, ....) In order to apply this to a specific test result from a ISP service re= cord (multiple ones that is) one must. 1) Create a timeline per service of it's state 2) Map that state to each test result - My thought here is that post processing information from two different s= ources drives the solution in the wrong direction by making the anonymity m= ore difficult, and creating expanded post processing requirements. =20 So having the probe collect and encapsulate the environment with each t= est result seems a no brainer to me. Just my 2.5 cents... Mike=20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of Sha= ne Amante Sent: Monday, April 15, 2013 1:47 PM To: STARK, BARBARA H Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-Use Cases Barbara, On Apr 15, 2013, at 7:20 AM, "STARK, BARBARA H" wrote: > Further snipping... >=20 >>>> However, one addition to this would be that I think it's important=20 >>>> to share 'service attributes' from a so-called Measurement=20 >>>> Parameter Server to (a) a Measurement Collector (directly) >>>=20 >>> If the ISP who knows the attributes also manages the Data Collector,=20 >>> then >> that's intra-domain, and the ISP should be able to figure out how to=20 >> do that within there OSS network without help from IETF. Therefore, I=20 >> don't see a need for the intra-domain interface to be in lmap phase 1=20 >> scope. If the ISP does not control the Data Collector, then I think=20 >> this is a much more difficult problem to solve, because it involves=20 >> the ISP knowing that the Data Collector controlling entity has the end u= ser's permission to have access to this data. >> Because of the need for permission with all of its associated need to=20 >> authenticate the Data Collector and "know" that the end user has=20 >> authorized that Data Collector (and allow the end user to revoke that=20 >> authorization, change that authorization, etc.), I consider this a=20 >> much more complex problem to solve and would prefer for it not to be in = lmap phase 1 scope. >>=20 >> At a minimum, the party (e.g.: regulatory entity) who are receiving=20 >> the "service attributes" from several dozen ISPs would want to=20 >> receive them in a standards-based data model, (e.g.: XML schema), to=20 >> make processing of the data contained therein more straightforward. =20 >> So, for the defined regulatory use case, this should be in scope of "LMA= P Phase 1", right? >=20 > Would the xml representation of service attributes provided to a "Data=20 > Collector" be different than the xml representation provided to a MA?=20 > That is, MAs may also need to have a very precise understanding of the=20 > service attributes being provided to them. Therefore, I saw the=20 > creation of an xml representation for service attributes to an MA to=20 > be a very important part of that interface. I guess, though, that a=20 > Data Collector probably would need additional metadata, so they could=20 > associate a specific set of collected data with a specific set of=20 > service attributes. If you think that the service attributes to Data=20 > Collector would drive additional data elements, then I think it would=20 > be reasonable to put that interface "in scope", but only for the xml,=20 > and not for the protocol or authentication/authorization/trust=20 > modeling. I would also prefer to have just a single set of service=20 > attribute xml (sufficient for both interfaces), and not separate xml=20 > for service attributes to MA vs .=20 > service attributes to Data Collector. Agreed. -shane _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From trammell@tik.ee.ethz.ch Mon Apr 15 14:12: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 8145E21F9122 for ; Mon, 15 Apr 2013 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 iWYR2z9WgHkf for ; Mon, 15 Apr 2013 14:12:28 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7913321F877B for ; Mon, 15 Apr 2013 14:12:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 250ABD930D; Mon, 15 Apr 2013 23:12:27 +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 T+ZDrqCAdJ3g; Mon, 15 Apr 2013 23:12:26 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 022FED9309; Mon, 15 Apr 2013 23:12:22 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <20130415191457.GA25223@elstar.local> Date: Tue, 16 Apr 2013 09:12:18 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415191457.GA25223@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1503) Cc: lmap@ietf.org Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-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, 15 Apr 2013 21:12:29 -0000 Hi, Juergen, all. +1. Comments inline. On 16 Apr 2013, at 7:14, Juergen Schoenwaelder = wrote: > Hi, >=20 > I have an issue with the terms Measurement Agent, Remote Measurement > Agent and Complete Measurement Agents as defined in the I-D. I do not > really see why we need all three and I am concerned that we make the > most frequently needed term the most complex to write and spell out. >=20 > My understanding is that LMAP defines Control Protocol and a Report > Protocol between a Controller / Collector and - well the rather ugly > term "Complete Measurement Agent". Note that these specifications will > have to talk a lot about this entity - which has the weirdest and > longest name. >=20 > Furthermore, I see little value of the term Measurement Agent because > the Remote Measurement Agents and the Complete Measurement Agents > really do very different things from an LMAP protocol perspective (The > Remote Measurement Agent does not nothing, the Complete Measurement > Agent does all.) I also think the current definition of Measurement > Agent is likely misleading - instead of 'performs' one should perhaps > use 'is involved in'. (If I throw a packet at a DNS server of an HTTP > server, I consider this server to be involved in the test, not to > perform this test.) Agree completely. LMAP sits between the Controller and the . = How that does measurement is _only_ in scope to the extent that = a Controller has to know about it in order to coordinate its actions. I = can't think of any arrangement of such components requiring the = Controller to manage distributed parts of a that is less = complicated and more robust than one in which the Controller has a = single part of the to which it delegates the distributed = arrangement.=20 (There may be complexities of measurement device _management_ -- = upgrading software, collecting load stats and other metadata, and so on = -- that might be simplified by a Controller knowing about every = subcomponent, but this is also questionably in scope.) > Bottom line is that I think we simplify the terminology a lot if we > remove the current definition of a Measurement Agent, a Complete > Measurement Agent, and Remote Measurement Agent and instead use this: >=20 > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement = Results > to a Collector. >=20 > Measurement Peer: A function that receives control messages and test > packets from a Measurement Agent and may reply to the Measurement > Agent as defined by the Measurement Method. >=20 > Well, Measurement Peer is a new invention and not necessarily the best > term one could come up with. In other contexts, this has been called a > measurement server (I tried to avoid 'server'). The key of this note, > however, is to just have to two simple to understand and use terms and > to avoid a generalization that I do not see useful for writing specs. Yep. As far as I'm concerned we could blend the two into one, to further = underscore the fact that we _really don't care_ how a Measurement Agent = performs the measurements it does: Measurement Agent: A function that receives Instructions from a Controller, performs Measurement Tasks and reports Measurement = Results to a Collector; perhaps in concert with other components distributed throughout the observed network, which it itself controls. Best regards, Brian= From Michael.K.Bugenhagen@centurylink.com Mon Apr 15 14:14: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 B739621F93B7 for ; Mon, 15 Apr 2013 14:14:39 -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 1x8BoBbM0jED for ; Mon, 15 Apr 2013 14:14:37 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7521F93BA for ; Mon, 15 Apr 2013 14:14:37 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3FLEV7f011359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Apr 2013 15:14:31 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2145D1E0096; Mon, 15 Apr 2013 15:14:26 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F3C5F1E0071; Mon, 15 Apr 2013 15:14:25 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3FLEPRh008128; Mon, 15 Apr 2013 15:14:25 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3FLEObR008075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 15:14:25 -0600 (MDT) 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, 15 Apr 2013 16:14:24 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "trammell@tik.ee.ethz.ch" , "acmorton@att.com" Thread-Topic: [lmap] LMAP: situation: Q3-Passive/Active measurements Thread-Index: Ac428bycfJYM0O5WRoyVVp9j2EejEwAByVkgAAwEw4AAIDiwgACc3vXA Date: Mon, 15 Apr 2013 21:14:24 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> , <1D65E908-932A-405E-85FB-9641B17FE4AE@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3456559C93@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3456559C93@EMV65-UKRD.domain1.systemhost.net> 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 Cc: "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active 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, 15 Apr 2013 21:14:39 -0000 I do think that passive measurements are of significant use to customers wh= o what to see them. Given the privacy issue, I believe the context of defining privacy domains = may be of use ---=20 Example of - 3 each "privacy domains"=20 1) Home LAN =3D Customer privacy domain - they get access to all their info= rmation 2) ISP Segment =3D ISP segment from the Drain to the Home Network - This could be fully made available to the customer - Anonymously made to regulators - Fully available to ISP's provided the information is used to maintain th= e quality of the service 3) Internet domain (drain to/from web server performance) - Open and publi= c provided it's anonymous Best regards, Mike -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Friday, April 12, 2013 8:16 AM To: trammell@tik.ee.ethz.ch; acmorton@att.com Cc: bs7652@att.com; lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements agree with all this. analysis of privacy would be worthwhile i think. active measurements also r= aise privacy concerns - and the report may do as well if it includes info b= eyond just the measurement results (eg about the subscriber) am quite interested in helping to study privacy issues ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of Brian Tram= mell [trammell@tik.ee.ethz.ch] Sent: 11 April 2013 22:53 To: MORTON JR., ALFRED C (AL) Cc: STARK, BARBARA H; lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements hi, Al, Barbara, all, +1 on all points in this thread. Both passive and active measurements are c= learly in scope. I think one thing that this discussion (and the thread preceding if followi= ng from the IEEE "public"/"private" terminological confusion) indicates is = that a statement on end-user privacy may be in scope, as well, if only to s= tate in initial documents that certain measurements must not be published. Best regards, Brian On 12 Apr 2013, at 9:47, "MORTON JR., ALFRED C (AL)" wro= te: > Barbara's response leads to another point stemming from discussion=20 > earlier this week: "neutrality" of measurements. Subscribers already=20 > trust their ISPs with the unencrypted contents of their packets, and=20 > an ISP would have few subscribers if it gave private information away. > A similar code of conduct extends to measurements and published=20 > results, and the potential to loose subscribers for ethical=20 > transgressions is equally great. > > Al > >> -----Original Message----- >> From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf=20 >> Of STARK, BARBARA H >> Sent: Thursday, April 11, 2013 4:19 PM >> To: lmap@ietf.org >> Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements >> >> *** Security Advisory: This Message Originated Outside of AT&T ***. >> Reference http://cso.att.com/EmailSecurity/IDSP.html for more informatio= n. >> >>> Question 3: Active and passive measurements Do we agree that both=20 >>> active and passive measurements are in scope? >> >> I certainly agree. If we do a BCP around privacy of end-user data, I=20 >> think it's very important to include passive measurement data in that=20 >> discussion. It may be that passive measurements aren't appropriate=20 >> for data that gets publicly shared. In which case that question=20 >> should be tackled head on. But passive measurements are absolutely ok=20 >> for end users to collect inside their own home network, and it's=20 >> standard practice for ISP's to collect passive measurements inside their= network elements. >> Passive measurements are very important tools where the data is not=20 >> intended to be shared with others. >> Barbara >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From shane@castlepoint.net Mon Apr 15 19:21:26 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 E1C2E21F925A for ; Mon, 15 Apr 2013 19:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.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 0fmuFQAUMV1F for ; Mon, 15 Apr 2013 19:21:26 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAAA21F91B8 for ; Mon, 15 Apr 2013 19:21:25 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 6E5C3300079 for ; Tue, 16 Apr 2013 02:21:25 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 72B2A300062; Mon, 15 Apr 2013 20:21:24 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: Date: Mon, 15 Apr 2013 20:21:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> To: "Bugenhagen, Michael K" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Apr 15 20:21:25 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516cb5a542071612315009 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, that+are, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, On+Apr, 0.01000, the+#+#+#+I, 0.01000, I+agree, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, Cc*ietf.org+#+ietf.org, 0.01000, them+to, 0.01000, them+to, 0.01000, From*Amante+shane, 0.01000, the+#+Collector, 0.01000, the+#+Collector, 0.01000, Subject*LMAP+situation, 0.01000, Cc*bs7652+att.com, 0.01000, service+attributes, 0.01000, service+attributes, 0.01000, the+#+#+the, 0.01000, Subject*Re+#+LMAP, 0.01000, could+#+a, 0.01000, could+#+a, 0.01000, at+#+#+PM, 0.01000, the+Measurement, 0.01000 Cc: "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 02:21:27 -0000 Michael, On Apr 15, 2013, at 3:06 PM, "Bugenhagen, Michael K" = wrote: > On the architecture including some sort of ISP attribute information = ---=20 >=20 > We could assume the tests are run separately and merged with ISP = information, or we could assume the probe gathers service environment = information and includes it with every test result (does a real-time = encapsulation). > Using the post processing merge framework has significant challenges, = some of which require local network environment validation regardless. [--snip--] > - My thought here is that post processing information from two = different sources drives the solution in the wrong direction by making = the anonymity more difficult, and creating expanded post processing = requirements. =20 I agree the above may be true. However, it could be a bit premature to = take post-processing correlation off the table. Specifically, we need = to strive to keep the MA function(s) that are shipped in embedded = devices, (CPE modem/routers, WiFi AP's, etc.), as "simple as possible, = but no simpler" and, also, we know that SW on those devices may not be = upgraded "often" ... then, that CPE-based MA could become a "bottleneck" = in the architecture=20 For example, if packages 'service attributes' in XML, then = ships them to the MA ... the question then becomes: will the MA need to = "understand" the service attributes encapsulated in that XML before = repackaging them (again) to upload them to the Measurement Collector = (alongside the network performance measurement results)? =20 So long as the MA can treat the service attributes it receives from = as "opaque", before shipping it to the Measurement = Collector, then I would definitely agree with you above. We shall see. -shane From trevor.burbridge@bt.com Tue Apr 16 01:18: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 35E8721F869C for ; Tue, 16 Apr 2013 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 QyM6jcdAE57r for ; Tue, 16 Apr 2013 01:18:43 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E1A0E21F8675 for ; Tue, 16 Apr 2013 01:18:41 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 16 Apr 2013 09:18:40 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.2]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Tue, 16 Apr 2013 09:18:40 +0100 From: To: , , Date: Tue, 16 Apr 2013 09:18:39 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 08:18:44 -0000 Making sure that the probe is on the line we expect is certainly a challeng= ing problem, but one that seems to face us regardless of whether the line/s= ubscriber information is being given to the MA or the Collector. In both ca= ses the network can check the IP address used by the MA. It would be nice i= f the MA or any other home device were able to get some broadband identifie= r for its line but that isn't really an LMAP specific capability. I would certainly support a simple way of the MA checking the line identity= . What I don't think it needs to do is retreive further line/subscriber inf= ormation. It seems in this case we're simply pushing information up to the = MA only to collect it back again. Do we want to do this for every possible = parameter that we are going to use for correlation in the data analysis? If= we're not going to do it with all parameters, why do it for a few? - we wo= uld need to add the extra ones in after result collection in that case. Add= ing 20 parameters to 5 columns of test results is also a serious reporting = overhead. There are two other concerns with the MA approach. Firstly we would need ve= ry timely information from the various network OSS providing the parameters= . Doing the splicing after collection removes any tight timing requirements= for the availability of this data (although we do obviously need good time= stamps). Having the MA check these parameters before every test is also a b= ig overhead. Secondly I worry about security (including both privacy and business confid= entialility). Instead of managing an interface with a handful of Collectors= , we need to manage access control for millions of MAs to make sure they ca= n only get their own information. Also just because an MA is on a specific = broadband line, what information should it really be able to get? Do we nee= d to then have access policies on the MA to control which of this data is t= hen reported to different collectors? Just trying to paint the other side to the story. Enhancing the data after = collection is not trivial. However, I think it is the better option than ha= ving the MA do it. Trevor. >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >Bugenhagen, Michael K >Sent: 15 April 2013 22:07 >To: 'Shane Amante'; STARK, BARBARA H >Cc: lmap@ietf.org >Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > >Shane, Barbara, > > On the architecture including some sort of ISP attribute information --- > > We could assume the tests are run separately and merged with ISP >information, or we could assume the probe gathers service environment >information and includes it with every test result (does a real-time >encapsulation). >Using the post processing merge framework has significant challenges, some >of which require local network environment validation regardless. > >Examples - > >1) Matching the test probe results to the ISP service attributes - > a) Increases the Challenges associated with creating anonymous data > b) Doesn't reflect when a customer moves a box from one service to >another (it happens) > ** Nothing I know reflects b) other than the probe validating it's >where it should be (what's the environment) so this is required.... > > >2) Service Environment changes > - When a service environment changes (enforcement of a bandwidth >cap - mobile, provisioning speed change, ....) > In order to apply this to a specific test result from a ISP service >record (multiple ones that is) one must. > 1) Create a timeline per service of it's state > 2) Map that state to each test result > > - My thought here is that post processing information from two >different sources drives the solution in the wrong direction by making the >anonymity more difficult, and creating expanded post processing >requirements. > > So having the probe collect and encapsulate the environment with each >test result seems a no brainer to me. > >Just my 2.5 cents... > >Mike > > > > > > > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of >Shane Amante >Sent: Monday, April 15, 2013 1:47 PM >To: STARK, BARBARA H >Cc: lmap@ietf.org >Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > >Barbara, > >On Apr 15, 2013, at 7:20 AM, "STARK, BARBARA H" >wrote: >> Further snipping... >> >>>>> However, one addition to this would be that I think it's important >>>>> to share 'service attributes' from a so-called Measurement >>>>> Parameter Server to (a) a Measurement Collector (directly) >>>> >>>> If the ISP who knows the attributes also manages the Data Collector, >>>> then >>> that's intra-domain, and the ISP should be able to figure out how to >>> do that within there OSS network without help from IETF. Therefore, I >>> don't see a need for the intra-domain interface to be in lmap phase 1 >>> scope. If the ISP does not control the Data Collector, then I think >>> this is a much more difficult problem to solve, because it involves >>> the ISP knowing that the Data Collector controlling entity has the end >user's permission to have access to this data. >>> Because of the need for permission with all of its associated need to >>> authenticate the Data Collector and "know" that the end user has >>> authorized that Data Collector (and allow the end user to revoke that >>> authorization, change that authorization, etc.), I consider this a >>> much more complex problem to solve and would prefer for it not to be in >lmap phase 1 scope. >>> >>> At a minimum, the party (e.g.: regulatory entity) who are receiving >>> the "service attributes" from several dozen ISPs would want to >>> receive them in a standards-based data model, (e.g.: XML schema), to >>> make processing of the data contained therein more straightforward. >>> So, for the defined regulatory use case, this should be in scope of "LM= AP >Phase 1", right? >> >> Would the xml representation of service attributes provided to a "Data >> Collector" be different than the xml representation provided to a MA? >> That is, MAs may also need to have a very precise understanding of the >> service attributes being provided to them. Therefore, I saw the >> creation of an xml representation for service attributes to an MA to >> be a very important part of that interface. I guess, though, that a >> Data Collector probably would need additional metadata, so they could >> associate a specific set of collected data with a specific set of >> service attributes. If you think that the service attributes to Data >> Collector would drive additional data elements, then I think it would >> be reasonable to put that interface "in scope", but only for the xml, >> and not for the protocol or authentication/authorization/trust >> modeling. I would also prefer to have just a single set of service >> attribute xml (sufficient for both interfaces), and not separate xml >> for service attributes to MA vs > . >> service attributes to Data Collector. > >Agreed. > >-shane > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap From philip.eardley@bt.com Tue Apr 16 02:50:35 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 D4FB521F95E3 for ; Tue, 16 Apr 2013 02:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_72=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 hCW-H7mYUxpc for ; Tue, 16 Apr 2013 02:50:35 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8765D21F8ECB for ; Tue, 16 Apr 2013 02:50:34 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 16 Apr 2013 10:50:33 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 16 Apr 2013 10:50:33 +0100 From: To: Date: Tue, 16 Apr 2013 10:50:31 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac46ByQg8MCO8Vt3QMyzesTAO0sIuQAf2mZg Message-ID: <9510D26531EF184D9017DF24659BB87F34565F8D82@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34564E9078@EMV65-UKRD.domain1.systemhost.net> <9071F711-5D14-4C4B-BB7C-2A0D76D0EC09@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34565F8B66@EMV65-UKRD.domain1.systemhost.net> <333D2CB9-0B29-4791-B2C9-4592369C0A6E@castlepoint.net> In-Reply-To: <333D2CB9-0B29-4791-B2C9-4592369C0A6E@castlepoint.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 09:50:36 -0000 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: 15 April 2013 19:29 > To: Eardley,PL,Philip,TUB8 R > Cc: bs7652@att.com; lmap@ietf.org > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 > Hi Phil, >=20 > On Apr 15, 2013, at 11:33 AM, philip.eardley@bt.com wrote: > > Hi Shane, > > I hadn't thought about the power outage example before. So I'm > interested whether you need admission control to cope with that > problem. So far I don't think you do. > > > > On the wider problem > >> to be in a situation where a bunch of MA's (due to an unfortunate > >> sequence of events), that are running tests autonomously, all end up > >> over-subscribing a single Measurement Server, thus making any > >> measurement results captured during that time to be considered > >> suspect or, worse, invalid. > > > > Agree in principle there could be a problem of overloading a > > measurement server (Remote-MA if you like terminology in > > http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology/) > > > > > > Alternatives to admission control include > > - Measurement Method includes a back-off algorithm (I got no response > > so I'll stop sending big file) > > - Remote-MA uses standard load balancing techniques > > - Remote-MA ignores the other MA (doesn't respond to request to send > > big file) > > - Remote-MA's site temporarily blocks 'misbehaving' domain (ie domain > > initiating too many Measurement Tasks at the moment) > > - MA runs a sanity check with Remote-MA first time performs a > > particular Measurement Method with it (if you like, a one-off > > admission control) > > - operational advice and good practice (eg start individual > > Measurement Tasks at a slightly randomised time; keep measurement > > traffic to > - a Measurement Method that creates a lot of load must include an > > initial msg from MA that Remote-MA can respond with an 'overloaded' > > error code [this is effectively admission control, but devolving the > > problem to the Measurement Method] > > > > So there seem several alternatives to alleviate the risk of overload. > > BTW, I'm not sure what the right answer is - I suspect several > techniques should be used in combination. > > Not yet convinced either for or against devising a special admission > > control protocol > > > > Also admission protocol > > - only protects the Remote-MA (not its network); > > - itself loads the Remote-MA - mustn't be limiting factor on > > Remote-MA's capacity > > - is not applicable if the Remote-MA isn't lmap-enabled (say it's a > > DNS server) >=20 > I'd agree with most of your points above. At this point, I'm not > trying to suggest any specific technical solution(s). Instead, I'm > attempting to clarify & suggest requirements for a (hopefully) > forthcoming LMAP WG and it's short-term deliverables/scope, (e.g.: > "LMAP Phase 1" as we've been calling it): > a) An "admission control" method between two MA's that communicate > directly with each other is REQUIRED, (e.g.: Measurement Agent on a CPE > to a Measurement Agent on a 'server'); > b) The aforementioned "admission control" method MUST be the same for > Intra-Domain and Inter-Domain MA's. >=20 >=20 > Note, at this point, I don't have an opinion on whether a "special/new" > protocol is required to achieve the above -or- if the solution becomes, > as Al states, an aspect of an (existing?) "pre-test protocol". I > believe the latter would certainly be preferred, but for now I'm trying > to phrase the above requirements as I did to avoid getting into > solutions prematurely. >=20 > Is there a particular draft you, Al or Barbara can suggest we should > consider incorporating these into, for now? >=20 > -shane Where the IPPM protocol includes a pre-test that's great (such as OWAMP & T= WAMP) Where it doesn't, I don't see "admission control between the two MAs" as a = MUST. I think that can be left to the test and the MA (on the 'server') to = decide what to do amongst the many possibilities phil >=20 >=20 >=20 > > phil > > > > > >> -----Original Message----- > >> From: Shane Amante [mailto:shane@castlepoint.net] > >> Sent: 15 April 2013 18:02 > >> To: Eardley,PL,Philip,TUB8 R > >> Cc: bs7652@att.com; lmap@ietf.org > >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > >> > >> Phil, > >> > >> On Apr 15, 2013, at 7:46 AM, wrote: > >>>> FWIW, I'm not suggesting any such thing. Rather, consider the > >>>> scenario where an entire neighborhood loses commercial power and > >>>> thousands (or, 10s of 1,000's) of the CPE devices power-on at the > >>>> same time. We definitely do not want all of those CPE's (and, > more > >>>> specifically the MA's on them) to all re-initiate their tests and > >>>> cause catastrophic problems in the network. Hence, we definitely > >>>> will need a CAC mechanism at the MA's to ensure this doesn't > happen. > >>>> > >>> > >>> I agree we don't want this to happen but I don't see why we need > >> admission control to solve it. > >>> > >>> After a power outage a number of things could happen: > >> > >> A number of things could happen, but the question is more likely: > >> what do we (LMAP, if/when a WG is formed) want to *recommend > >> should/must happen*? Presumably, as part of a "Deployment BCP" > (???) > >> (or, an LMAP Architecture Doc) we'd want to recommend what is > >> considered a Best Practice at the MA (and, other components of the > overall Architecture). > >> > >> > >>> - the MA still has its Measurement Schedule. It just re-starts > >> running > >>> tests (Measurement Tasks) > >>> - the MA has lost its Measurement Schedule, or it has expired. It > >>> simply waits to hear from the Controller with a new one > >>> - the MA has forgotten who its Controller is. The initialisation > >>> process needs to run again (it needs to hear from the 'Management > >>> Server' about who its controller is and security details > >>> ('Management Server' =3D term from the Broadband forum liaison). This > >>> is probably a BBF defined process (at least for ISP-controlled MA). > >>> In any case, it's only this (re-)initialisation or re-homing > process > >>> that needs some kind of load control (and which could be handled by > >>> a back-off algorithm rather than CAC) > >> > >> Those are certainly valid suggestions. However, we would still want > >> to have a (relatively) straightforward CAC mechanism between the MA > >> (CPE > >> device) and Measurement Server? At the end of the day, we don't > want > >> to be in a situation where a bunch of MA's (due to an unfortunate > >> sequence of events), that are running tests autonomously, all end up > >> over-subscribing a single Measurement Server, thus making any > >> measurement results captured during that time to be considered > >> suspect or, worse, invalid. > >> > >> -shane > > >=20 From bs7652@att.com Tue Apr 16 05:30:06 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 5F6C621F8F12 for ; Tue, 16 Apr 2013 05:30:06 -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 lu9JMC2zyj3Y for ; Tue, 16 Apr 2013 05:30:05 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 91D0F21F86F4 for ; Tue, 16 Apr 2013 05:30:05 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id d444d615.2aaaee23c940.54093.00-570.146001.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 16 Apr 2013 12:30:05 +0000 (UTC) X-MXL-Hash: 516d444d02d1bf88-f6b6bcac5d353ca335062c89471869348fc0977f Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b444d615.0.54074.00-486.145956.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 16 Apr 2013 12:30:04 +0000 (UTC) X-MXL-Hash: 516d444c218b8796-1f3ab4407d03be9b7eaf8919a60de9ad79ca9b70 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GCU3AB029577; Tue, 16 Apr 2013 08:30:03 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GCTuvY029525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 08:29:57 -0400 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 16 Apr 2013 13:29:44 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 08:29:44 -0400 From: "STARK, BARBARA H" To: "trevor.burbridge@bt.com" , "Michael.K.Bugenhagen@centurylink.com" , "shane@castlepoint.net" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQ Date: Tue, 16 Apr 2013 12:29:43 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.185.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=OvT4PVDt c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=LX9RdhQRmLMA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=ur_JhPUa1QBLMAVSxz0A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=TNgKh2SX85ip2-I1:21 a=fvKFM0EAF5p47knL:21] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 12:30:06 -0000 Trying to focus on what is in scope and not in scope for lmap phase 1... I thought Shane and I had sort of agreed that "in scope" would include: 1. Identifying service attributes and creating an extensible xml model of t= hese attributes. This would consider the service attributes that would be n= eeded if they were provided to an MA, inter-domain (from the access provide= r who has them to an authorized 3rd party who is collecting the data), and = intra-domain (where the access provider has the service attributes and is d= oing data collection, so standard xml naming is really needed more for serv= ice attributes that will be included with collected data ultimately provide= d to others for analysis). I thought we had agreed that there was no need f= or a particular service attribute to have a different xml "name" or represe= ntation, depending on how it was delivered. 2. Mechanisms for providing service attributes directly to an MA (primarily= targeted at the case where the MA is not controlled by the access provider= , and does not provide its data to the access provider). Just because something is "in scope" doesn't mean we necessarily end up man= aging to create a solution for it. But it does mean we discuss it and see w= hat we think we can come up with. "Out of scope" are mechanisms/protocols for intra-domain and inter-domain t= ransfer of service attributes. So, Mike and Trevor, are you disagreeing with this "in scope" and "out of s= cope" characterization? Specifically... Mike, do you object to trying to come up with a holistic service attribute = xml model, that considers the type of data needed by all of the various tra= nsfer usages? Trevor, do you object to lmap phase 1 consideration of potential mechanisms= for supplying service attributes to MAs that do not send data to the acces= s provider? I absolutely agree that sending service attributes to a system = that also gets the collected data is a great way to go, and how I would rec= ommend an access provider do things, where the access provider collects the= data and has the service attributes. But I also have no desire to ask the = IETF to recommend mechanisms for getting that data from one internal access= provider IT system to another. Are you wanting IETF to define a mechanism = for intra-domain transfer of service attributes? I'm also not keen on askin= g IETF to try to solve the inter-domain transfer problem in lmap phase 1, b= ecause I think it involves 3-way trust relationships, which can be difficul= t to manage. To be sufficiently robust and flexible, the end user must be a= ble to grant and revoke authority for a 3rd party to receive that end user'= s service attributes. The access provider has to trust the end user is the = end user, that the end user has provided that authorization, and that the 3= rd party is indeed the party that the end user has authorized. Somebody has= to manage the trust relationship. Different regulators might want differen= t ways to manage the trust relationship. It's complex. Are you wanting to = put mechanisms for inter-domain service attribute transfer in lmap phase 1? Barbara From trevor.burbridge@bt.com Tue Apr 16 05:46:14 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 4E53B21F95B4 for ; Tue, 16 Apr 2013 05:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, 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 dfw01UGjCn+j for ; Tue, 16 Apr 2013 05:46:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6121F9593 for ; Tue, 16 Apr 2013 05:46:13 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Apr 2013 13:46:11 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.2]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 16 Apr 2013 13:46:11 +0100 From: To: , , Date: Tue, 16 Apr 2013 13:46:10 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQAABcvnA= Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 12:46:14 -0000 >-----Original Message----- >From: STARK, BARBARA H [mailto:bs7652@att.com] >Sent: 16 April 2013 13:30 >To: Burbridge,T,Trevor,TUB8 R; Michael.K.Bugenhagen@centurylink.com; >shane@castlepoint.net >Cc: lmap@ietf.org >Subject: RE: [lmap] LMAP: situation: Q1-Use Cases [snip] >Trevor, do you object to lmap phase 1 consideration of potential >mechanisms for supplying service attributes to MAs that do not send data t= o >the access provider? As you suggest below, the correct question from a requirements point-of-vie= w is whether we include inter-domain service attribute transfer in phase 1.= I certainly wouldn't push for it. For intra-domain, do I think the correct implementation is via the MA - no.= Would this change if inter-domain was in scope? Not convinced. >I absolutely agree that sending service attributes to a >system that also gets the collected data is a great way to go, and how I >would recommend an access provider do things, where the access provider >collects the data and has the service attributes. But I also have no desir= e to >ask the IETF to recommend mechanisms for getting that data from one >internal access provider IT system to another. Are you wanting IETF to def= ine >a mechanism for intra-domain transfer of service attributes? I'm also not >keen on asking IETF to try to solve the inter-domain transfer problem in >lmap phase 1, because I think it involves 3-way trust relationships, which= can >be difficult to manage. To be sufficiently robust and flexible, the end us= er >must be able to grant and revoke authority for a 3rd party to receive that >end user's service attributes. The access provider has to trust the end us= er is >the end user, that the end user has provided that authorization, and that = the >3rd party is indeed the party that the end user has authorized. Somebody >has to manage the trust relationship. Different regulators might want >different ways to manage the trust relationship. It's complex. Are you >wanting to put mechanisms for inter-domain service attribute transfer in >lmap phase 1? No. >Barbara Trevor. From acmorton@att.com Tue Apr 16 06:28:07 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 6A81421F969B for ; Tue, 16 Apr 2013 06:28:07 -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 dwCGXBrEZ8Sa for ; Tue, 16 Apr 2013 06:28:06 -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 E328721F9652 for ; Tue, 16 Apr 2013 06:28:05 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 7D73A1206B2; Tue, 16 Apr 2013 09:28:31 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 81E77F00EF; Tue, 16 Apr 2013 09:28:05 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Tue, 16 Apr 2013 09:28:05 -0400 From: "MORTON JR., ALFRED C (AL)" To: Brian Trammell , Juergen Schoenwaelder Date: Tue, 16 Apr 2013 09:28:04 -0400 Thread-Topic: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-00.txt Thread-Index: Ac46HfZxV93nGr10TJWEA9O7xHBpogAhMigQ Message-ID: References: <20130415191457.GA25223@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-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, 16 Apr 2013 13:28:07 -0000 Juergen wrote: > > Bottom line is that I think we simplify the terminology a lot if we > > remove the current definition of a Measurement Agent, a Complete > > Measurement Agent, and Remote Measurement Agent and instead use this: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement Results > > to a Collector. > > > > Measurement Peer: A function that receives control messages and test > > packets from a Measurement Agent and may reply to the Measurement > > Agent as defined by the Measurement Method. > > > > Well, Measurement Peer is a new invention and not necessarily the best > > term one could come up with. In other contexts, this has been called a > > measurement server (I tried to avoid 'server'). The key of this note, > > however, is to just have to two simple to understand and use terms and > > to avoid a generalization that I do not see useful for writing specs. Brian wrote: >=20 > Yep. As far as I'm concerned we could blend the two into one, to further > underscore the fact that we _really don't care_ how a Measurement Agent > performs the measurements it does: >=20 > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement Result= s > to a Collector; perhaps in concert with other components distributed > throughout the observed network, which it itself controls. > This single name is closer to what I was thinking "terminologically" last O= ctober. There will be cases (I believe) where one MA is Instructed to perform some measurements, but is simply a measurement peer for other measurement s= essions. After initialization and instruction, different MAs can be distinguished by= the named roles of the measurement protocol they use to execute the instruction= s. Some MAs may only be initialized, then sit and wait to be contacted by othe= r MAs. A small tweak at the end: Measurement Agent: A function that receives Instructions from a Controller, performs Measurement Tasks and reports Measurement Results to a Collector; perhaps in concert with other components distributed throughout the observed network, with which it coordinates as needed. (either MA can reject a test session, following the CAC discussion yesterda= y) Al > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Brian Trammell > Sent: Monday, April 15, 2013 5:12 PM > To: Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap- > terminology-00.txt >=20 > Hi, Juergen, all. >=20 > +1. Comments inline. >=20 > On 16 Apr 2013, at 7:14, Juergen Schoenwaelder university.de> wrote: >=20 > > Hi, > > > > I have an issue with the terms Measurement Agent, Remote Measurement > > Agent and Complete Measurement Agents as defined in the I-D. I do not > > really see why we need all three and I am concerned that we make the > > most frequently needed term the most complex to write and spell out. > > > > My understanding is that LMAP defines Control Protocol and a Report > > Protocol between a Controller / Collector and - well the rather ugly > > term "Complete Measurement Agent". Note that these specifications will > > have to talk a lot about this entity - which has the weirdest and > > longest name. > > > > Furthermore, I see little value of the term Measurement Agent because > > the Remote Measurement Agents and the Complete Measurement Agents > > really do very different things from an LMAP protocol perspective (The > > Remote Measurement Agent does not nothing, the Complete Measurement > > Agent does all.) I also think the current definition of Measurement > > Agent is likely misleading - instead of 'performs' one should perhaps > > use 'is involved in'. (If I throw a packet at a DNS server of an HTTP > > server, I consider this server to be involved in the test, not to > > perform this test.) >=20 > Agree completely. >=20 > LMAP sits between the Controller and the . > How that does measurement is _only_ in scope to the extent that a > Controller has to know about it in order to coordinate its actions. I > can't think of any arrangement of such components requiring the Controlle= r > to manage distributed parts of a that is less complicated and mor= e > robust than one in which the Controller has a single part of the > to which it delegates the distributed arrangement. >=20 > (There may be complexities of measurement device _management_ -- upgradin= g > software, collecting load stats and other metadata, and so on -- that > might be simplified by a Controller knowing about every subcomponent, but > this is also questionably in scope.) >=20 >=20 > > Bottom line is that I think we simplify the terminology a lot if we > > remove the current definition of a Measurement Agent, a Complete > > Measurement Agent, and Remote Measurement Agent and instead use this: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement Results > > to a Collector. > > > > Measurement Peer: A function that receives control messages and test > > packets from a Measurement Agent and may reply to the Measurement > > Agent as defined by the Measurement Method. > > > > Well, Measurement Peer is a new invention and not necessarily the best > > term one could come up with. In other contexts, this has been called a > > measurement server (I tried to avoid 'server'). The key of this note, > > however, is to just have to two simple to understand and use terms and > > to avoid a generalization that I do not see useful for writing specs. >=20 > Yep. As far as I'm concerned we could blend the two into one, to further > underscore the fact that we _really don't care_ how a Measurement Agent > performs the measurements it does: >=20 > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement Result= s > to a Collector; perhaps in concert with other components distributed > throughout the observed network, which it itself controls. >=20 > Best regards, >=20 > Brian > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From bs7652@att.com Tue Apr 16 06:32:55 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 22BE321F92C5 for ; Tue, 16 Apr 2013 06:32:55 -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 AZzEMlJDCMiY for ; Tue, 16 Apr 2013 06:32:54 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4521F92C2 for ; Tue, 16 Apr 2013 06:32:54 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 6035d615.2aaafb451940.85935.00-578.233697.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 16 Apr 2013 13:32:54 +0000 (UTC) X-MXL-Hash: 516d5306735e284c-e600272e7d762c8a0977ec176ae814e77c6a3db0 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4035d615.0.85919.00-408.233634.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 16 Apr 2013 13:32:53 +0000 (UTC) X-MXL-Hash: 516d53057c73a50b-8b8a9d52c60fd3857d0bc2cba1436ee7c913c8b3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GDWpFX017699; Tue, 16 Apr 2013 09:32:52 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GDWhVp017558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 09:32:47 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi132.aldc.att.com (RSA Interceptor); Tue, 16 Apr 2013 14:32:27 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 09:32:27 -0400 From: "STARK, BARBARA H" To: "trevor.burbridge@bt.com" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQAABcvnAAAAuv4A== Date: Tue, 16 Apr 2013 13:32:26 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A6CF9@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.185.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=KdRlR3kD c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=LX9RdhQRmLMA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=nEtC41px180HZRUssboA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 13:32:55 -0000 > >Trevor, do you object to lmap phase 1 consideration of potential > >mechanisms for supplying service attributes to MAs that do not send > >data to the access provider? >=20 > As you suggest below, the correct question from a requirements point-of- > view is whether we include inter-domain service attribute transfer in pha= se > 1. I certainly wouldn't push for it. >=20 > For intra-domain, do I think the correct implementation is via the MA - n= o. > Would this change if inter-domain was in scope? Not convinced. Hi Trevor, OK. I hear you, but I disagree that "service attribute to MA" should be "ou= t of scope". I would like for some sort of solution to exist where a 3rd pa= rty can manage the MA and collect the MA's data, and have the MA in that ca= se be able to get service attributes. This doesn't mean that I want there t= o be a BCP recommending this method. It doesn't mean it should preclude arc= hitectures where the access provider does data collection. It does mean tha= t I don't think there is a "one size fits all" way to architect measurement= collection that will be "the" right way for every provider and every gover= nment in the world. It means I want the mechanism to exist and be defined, = and be available to whoever wants to implement it. I also think that providing an MA with service attributes is useful in the = case where the end user just wants to run his/her own tests and not share t= he data with anybody. End users should be able to have access to their serv= ice attributes. Barbara From trevor.burbridge@bt.com Tue Apr 16 06:42: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 1450321F96EA for ; Tue, 16 Apr 2013 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, 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 W1QcdduGl603 for ; Tue, 16 Apr 2013 06:42:39 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73C21F96C3 for ; Tue, 16 Apr 2013 06:42:39 -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.279.1; Tue, 16 Apr 2013 14:42:31 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.2]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Tue, 16 Apr 2013 14:42:31 +0100 From: To: Date: Tue, 16 Apr 2013 14:42:29 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQAABcvnAAAAuv4AABT6eQ Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A6CF9@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A6CF9@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 13:42:40 -0000 >-----Original Message----- >From: STARK, BARBARA H [mailto:bs7652@att.com] >Sent: 16 April 2013 14:32 >To: Burbridge,T,Trevor,TUB8 R >Cc: lmap@ietf.org >Subject: RE: [lmap] LMAP: situation: Q1-Use Cases > >> >Trevor, do you object to lmap phase 1 consideration of potential >> >mechanisms for supplying service attributes to MAs that do not send >> >data to the access provider? >> >> As you suggest below, the correct question from a requirements >> point-of- view is whether we include inter-domain service attribute >> transfer in phase 1. I certainly wouldn't push for it. >> >> For intra-domain, do I think the correct implementation is via the MA - = no. >> Would this change if inter-domain was in scope? Not convinced. > >Hi Trevor, >OK. I hear you, but I disagree that "service attribute to MA" should be "o= ut >of scope". I would like for some sort of solution to exist where a 3rd par= ty >can manage the MA and collect the MA's data, and have the MA in that case >be able to get service attributes. This doesn't mean that I want there to = be a >BCP recommending this method. It doesn't mean it should preclude >architectures where the access provider does data collection. It does mean >that I don't think there is a "one size fits all" way to architect measure= ment >collection that will be "the" right way for every provider and every >government in the world. It means I want the mechanism to exist and be >defined, and be available to whoever wants to implement it. > >I also think that providing an MA with service attributes is useful in the= case >where the end user just wants to run his/her own tests and not share the >data with anybody. End users should be able to have access to their servic= e >attributes. >Barbara Not sure we're disagreeing. I'm not precluding the MA reporting stuff. The report information model may= contain context information. Certainly any individual test result is free = to report whatever measured or local parameters it wants to. On getting service attributes to the MA, the only question is whether there= is a single standard way of doing that in LMAP. I'm not saying there shoul= dn't be ways of doing it. Some ISPs might push this info to the home gatewa= y. Others might provide it on the customer web portal. Trevor. From shane@castlepoint.net Tue Apr 16 06:50: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 0020921F9729 for ; Tue, 16 Apr 2013 06:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_91=0.6, RDNS_NONE=0.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 A3fqhxIHa3d4 for ; Tue, 16 Apr 2013 06:50:07 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0B67E21F9727 for ; Tue, 16 Apr 2013 06:50:06 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 86C5D30007A for ; Tue, 16 Apr 2013 13:50:06 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 08A25300035; Tue, 16 Apr 2013 07:50:04 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: Date: Tue, 16 Apr 2013 07:50:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> To: trevor.burbridge@bt.com X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 16 07:50:06 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516d570e42077566110529 X-DSPAM-Factors: 27, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+to, 0.01000, to+#+#+#+to, 0.01000, from+a, 0.01000, and+#+#+end, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, have+no, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, to+#+to, 0.01000, to+#+to, 0.01000, the+#+#+#+I, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, the+end, 0.01000, the+end, 0.01000, we+#+to, 0.01000, From*Amante+shane, 0.01000, lmap+#+1, 0.01000, lmap+#+1, 0.01000, AM+#+#+bt, 0.01000, this+is, 0.01000, this+is, 0.01000 Cc: lmap@ietf.org, bs7652@att.com, Michael.K.Bugenhagen@centurylink.com Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 13:50:08 -0000 Trevor, Barbara, On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >> -----Original Message----- >> From: STARK, BARBARA H [mailto:bs7652@att.com] >> Sent: 16 April 2013 13:30 >> To: Burbridge,T,Trevor,TUB8 R; Michael.K.Bugenhagen@centurylink.com; >> shane@castlepoint.net >> Cc: lmap@ietf.org >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases > [snip] >> Trevor, do you object to lmap phase 1 consideration of potential >> mechanisms for supplying service attributes to MAs that do not send = data to >> the access provider? >=20 > As you suggest below, the correct question from a requirements = point-of-view is whether we include inter-domain service attribute = transfer in phase 1. I certainly wouldn't push for it. I think we need to be careful to separate out two aspects of the service = attributes discussion: a) Representation of service attributes inside an XML schema. IMO, it = seems this is the right thing to do regardless of whether this is = "intra-" or "inter-"domain, since everyone who is going to = programmatically interpret measurement results is going to want a = standardized representation of "service attributes" to make it = straightforward to parse them. b) Transfer of the aforementioned "service attribute XML schema" from = one host to another host and/or from one party to another party. For = this I would ask the question of: why wouldn't we just use HTTP or = HTTPS? In doing so, it would allow LMAP to leverage a variety of = existing, already-specified & implemented authentication mechanisms for = HTTP/HTTPS. And, for that matter, it could be up to ISPs to decide what = they wanted to use, e.g.: simple username/password and/or SSL = certificates. At that point, it's up to a bi-lateral negotiation = between Party A to Party B, (in the context of inter-domain), at the = time they stand up the capability to 'download' (or, upload) the XML = service attribute schema.=20 Also, please note that I said: "bi-lateral negotiation" above. IOW, two = parties are dealing directly with each other, thus they should be able = to negotiate amongst themselves (out-of-band, of course) what HTTP/HTTPS = mechanism(s) are required to "safely" xfer the XML service attribute = schema, etc. -shane > For intra-domain, do I think the correct implementation is via the MA = - no. Would this change if inter-domain was in scope? Not convinced. >=20 >> I absolutely agree that sending service attributes to a >> system that also gets the collected data is a great way to go, and = how I >> would recommend an access provider do things, where the access = provider >> collects the data and has the service attributes. But I also have no = desire to >> ask the IETF to recommend mechanisms for getting that data from one >> internal access provider IT system to another. Are you wanting IETF = to define >> a mechanism for intra-domain transfer of service attributes? I'm also = not >> keen on asking IETF to try to solve the inter-domain transfer problem = in >> lmap phase 1, because I think it involves 3-way trust relationships, = which can >> be difficult to manage. To be sufficiently robust and flexible, the = end user >> must be able to grant and revoke authority for a 3rd party to receive = that >> end user's service attributes. The access provider has to trust the = end user is >> the end user, that the end user has provided that authorization, and = that the >> 3rd party is indeed the party that the end user has authorized. = Somebody >> has to manage the trust relationship. Different regulators might want >> different ways to manage the trust relationship. It's complex. Are = you >> wanting to put mechanisms for inter-domain service attribute transfer = in >> lmap phase 1? >=20 > No. >=20 >> Barbara >=20 > Trevor. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap >=20 From Michael.K.Bugenhagen@centurylink.com Tue Apr 16 06:59:10 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 53F1221F969B for ; Tue, 16 Apr 2013 06:59:10 -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 Kv0ILgeUTRhH for ; Tue, 16 Apr 2013 06:59:09 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6B63021F968C for ; Tue, 16 Apr 2013 06:59:09 -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 r3GDx4Zd005738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 08:59:04 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0A74F1E004E; Tue, 16 Apr 2013 07:58:59 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id E00941E006F; Tue, 16 Apr 2013 07:58:58 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3GDwwvh029852; Tue, 16 Apr 2013 07:58:58 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3GDwwDM029843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 07:58:58 -0600 (MDT) 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; Tue, 16 Apr 2013 08:58:57 -0500 From: "Bugenhagen, Michael K" To: "'STARK, BARBARA H'" , "trevor.burbridge@bt.com" , "shane@castlepoint.net" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgP//vc/Q Date: Tue, 16 Apr 2013 13:58:57 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 13:59:10 -0000 Barbara, Short answer - YES on Service attributes XML model, otherwise we can't h= ave true validated results with tests that compare the=20 "throughput" to "sold speed" - Aka a non-qualifiable result if we don't kno= w what the actual "sold speed" was, which of course is a service attribute. This is part of the greater scope of the project, and is really not a "SHOU= LD" - it's more of a "MUST" requirement. ------------------------ Long answer (they why's examined) - and a hitch to more succinctly defining= Inter-domain {look at 1. b) under Inter-domain classes} Ok - for my phase 1 in/out preferences & reasoning, I'll have to answer tho= se multi-part questions one by one 1. a) Identifying service attributes and creating an extensible xml model o= f these attributes This would consider the service attributes that would be= needed if they were provided to an MA. Yes - Definitely should be part of the Scope for Phase 1, and should be i= n a standard XML format...=20 I'll extend this to say that the test results should also be in a standa= rd format as well, and should include the Service attributes That I've somewhat coined the term "test environment" (looking for a mor= e suitable nomenclature but better term has been ID'd yet) =09 Logic behind this (test results including the service attributes in plac= e during the test) - =20 Data analysis after the fact become increasingly difficult to conduct ac= curately without the environmental data of the test environment. The = last thing anyone needs is to complete an analysis not understanding the en= vironment and coming up with incorrect conclusions due to missing data. = That itself would discredit the methodology and framework itself. 1. b) inter-domain (from the access provider who has them to an authorized = 3rd party who is collecting the data), and intra-domain (where the access p= rovider has the service attributes and is doing data collection, so standar= d xml naming is really needed more for service attributes that will be incl= uded with collected data ultimately provided to others for analysis). I tho= ught we had agreed that there was no need for a particular service attribut= e to have a different xml "name" or representation, depending on how it was= delivered. I) I believe knowing the test environment is required to provide validated= test results regardless of who's testing. - Which aligns with classifying a validated or qualified vs. non-validate= d/qualified test result=20 (either you know the service attributes or didn't) II) Inter-Domain testing classes - This could be multiple things - we need to define it. a) MA, Controller, and Collector in one domain, but a second test MA i= s outside (no or partial results shared) - IN SCOPE b) MA, Controller, and 3rd party Collector - OUT OF SCOPE c) 3rd party MA, 3rd party Controller, and 3rd party Collector - IN SC= OPE (supports customer conducting testing) =20 2.) XML model for service attributes - Definitely in scope to support the a= & c models and create a validated / Qualified test Best Regards, Mike ---------------------------------------------------------------------------= ---------------------------------------------- -----Original Message----- From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Tuesday, April 16, 2013 7:30 AM To: trevor.burbridge@bt.com; Bugenhagen, Michael K; shane@castlepoint.net Cc: lmap@ietf.org Subject: RE: [lmap] LMAP: situation: Q1-Use Cases Trying to focus on what is in scope and not in scope for lmap phase 1... I thought Shane and I had sort of agreed that "in scope" would include: 1. Identifying service attributes and creating an extensible xml model of t= hese attributes. This would consider the service attributes that would be n= eeded if they were provided to an MA, inter-domain (from the access provide= r who has them to an authorized 3rd party who is collecting the data), and = intra-domain (where the access provider has the service attributes and is d= oing data collection, so standard xml naming is really needed more for serv= ice attributes that will be included with collected data ultimately provide= d to others for analysis). I thought we had agreed that there was no need f= or a particular service attribute to have a different xml "name" or represe= ntation, depending on how it was delivered. 2. - I Just because something is "in scope" doesn't mean we necessarily end up man= aging to create a solution for it. But it does mean we discuss it and see w= hat we think we can come up with. "Out of scope" are mechanisms/protocols for intra-domain and inter-domain t= ransfer of service attributes. So, Mike and Trevor, are you disagreeing with this "in scope" and "out of s= cope" characterization? Specifically... Mike, do you object to trying to come up with a holistic service attribute = xml model, that considers the type of data needed by all of the various tra= nsfer usages? Trevor, do you object to lmap phase 1 consideration of potential mechanisms= for supplying service attributes to MAs that do not send data to the acces= s provider? I absolutely agree that sending service attributes to a system = that also gets the collected data is a great way to go, and how I would rec= ommend an access provider do things, where the access provider collects the= data and has the service attributes. But I also have no desire to ask the = IETF to recommend mechanisms for getting that data from one internal access= provider IT system to another. Are you wanting IETF to define a mechanism = for intra-domain transfer of service attributes? I'm also not keen on askin= g IETF to try to solve the inter-domain transfer problem in lmap phase 1, b= ecause I think it involves 3-way trust relationships, which can be difficul= t to manage. To be sufficiently robust and flexible, the end user must be a= ble to grant and revoke authority for a 3rd party to receive that end user'= s service attributes. The access provider has to trust the end user is the = end user, that the end user has provided that authorization, and that the 3= rd party is indeed the party that the end user has authorized. Somebody has= to manage the trust relationship. Different regulators might want differen= t ways to manage the trust relationship. It's complex. Are you wanting to = put mechanisms for inter-domain service attribute transfer in lmap phase 1? Barbara From j.schoenwaelder@jacobs-university.de Tue Apr 16 07:00:06 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 3ABC821F969F for ; Tue, 16 Apr 2013 07:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cgPkQJlsnnWZ for ; Tue, 16 Apr 2013 07:00: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 4E23021F968C for ; Tue, 16 Apr 2013 07:00:03 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 770DE20AFA; Tue, 16 Apr 2013 16:00:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZKB6ZZiLYnNa; Tue, 16 Apr 2013 16:00:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09C5E20BE9; Tue, 16 Apr 2013 16:00:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D3A9D25A7D0E; Tue, 16 Apr 2013 16:00:05 +0200 (CEST) Date: Tue, 16 Apr 2013 16:00:05 +0200 From: Juergen Schoenwaelder To: Shane Amante Message-ID: <20130416140005.GC28527@elstar.local> Mail-Followup-To: Shane Amante , trevor.burbridge@bt.com, lmap@ietf.org, bs7652@att.com, Michael.K.Bugenhagen@centurylink.com References: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: trevor.burbridge@bt.com, bs7652@att.com, Michael.K.Bugenhagen@centurylink.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-Use Cases 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: Tue, 16 Apr 2013 14:00:06 -0000 On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: > Trevor, Barbara, > > On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: > >> -----Original Message----- > >> From: STARK, BARBARA H [mailto:bs7652@att.com] > >> Sent: 16 April 2013 13:30 > >> To: Burbridge,T,Trevor,TUB8 R; Michael.K.Bugenhagen@centurylink.com; > >> shane@castlepoint.net > >> Cc: lmap@ietf.org > >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases > > [snip] > >> Trevor, do you object to lmap phase 1 consideration of potential > >> mechanisms for supplying service attributes to MAs that do not send data to > >> the access provider? > > > > As you suggest below, the correct question from a requirements point-of-view is whether we include inter-domain service attribute transfer in phase 1. I certainly wouldn't push for it. > > I think we need to be careful to separate out two aspects of the service attributes discussion: > a) Representation of service attributes inside an XML schema. IMO, it seems this is the right thing to do regardless of whether this is "intra-" or "inter-"domain, since everyone who is going to programmatically interpret measurement results is going to want a standardized representation of "service attributes" to make it straightforward to parse them. How realistic is it that we can define a standard data model for service attributes that matches a significant portion of the products out there in the wild? > b) Transfer of the aforementioned "service attribute XML schema" from one host to another host and/or from one party to another party. For this I would ask the question of: why wouldn't we just use HTTP or HTTPS? In doing so, it would allow LMAP to leverage a variety of existing, already-specified & implemented authentication mechanisms for HTTP/HTTPS. And, for that matter, it could be up to ISPs to decide what they wanted to use, e.g.: simple username/password and/or SSL certificates. At that point, it's up to a bi-lateral negotiation between Party A to Party B, (in the context of inter-domain), at the time they stand up the capability to 'download' (or, upload) the XML service attribute schema. Securing the protocol is not the problem, it is key management that is usually the problem. Do we expect an MA to have credentials that allow it to fetch service attributes? How are those credentials managed during the lifecycle of the MA? It may be much harder to manage the necessary credentials on thousands of MAs compared to a solution where a few data collector or a data analysis function fetch service attributes. (Of course, this still requires proper authorization but the key management problem seems to be at a very different order of scale - at least if we can assume #controller << #MAs or #data-analyzer << #MAs.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Michael.K.Bugenhagen@centurylink.com Tue Apr 16 07:13:20 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 3326721F9694 for ; Tue, 16 Apr 2013 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 gSgqEIY9QuXf for ; Tue, 16 Apr 2013 07:13:19 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC121F968B for ; Tue, 16 Apr 2013 07:13:19 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3GEDDZo026097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 08:13:13 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 0368A1E008C; Tue, 16 Apr 2013 08:13:08 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id C4C211E005E; Tue, 16 Apr 2013 08:13:07 -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 r3GED7IU004512; Tue, 16 Apr 2013 09:13:07 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r3GED6Os004481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 09:13:07 -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; Tue, 16 Apr 2013 09:13:06 -0500 From: "Bugenhagen, Michael K" To: "'trevor.burbridge@bt.com'" , "shane@castlepoint.net" , "bs7652@att.com" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAGRSkA== Date: Tue, 16 Apr 2013 14:13:06 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> 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 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:13:20 -0000 Trevor - A few thoughts on your points ---=20 You first statement mentioned - There are two other concerns with the MA approach. Firstly we would need ve= ry timely information from the various network OSS providing the parameters= . Doing the splicing after collection removes any tight timing requirements= for the availability of this data (although we do obviously need good time= stamps). Having the MA check these parameters before every test is also a b= ig overhead. -- Your statement assumes a methodology given it's considered "big overh= ead," - I think the approach used here is key, and there may be ways of = making this easy vs. difficult. I would agree that using today's construct= s this is difficult, however we collectively have the ability to create a = new methodology to accomplish making the SA (service attributes) obtainable= , and low overhead. =20 - I would also like to point out that there really only a small amount of = "provisionable" service attributes, but a large amount of different types=20 Of performance that can be tracked. I don't think it's appropriate t= o ask a ISP to track every performance aspect of every line, that is more= intuitive of a business service vs. a Internet Service, so the subset of "= SET by the ISP" attributes are really the ones we're interested in. Your second statement - Secondly I worry about security (including both privacy and business confid= entialility). Instead of managing an interface with a handful of Collectors= , we need to manage access control for millions of MAs to make sure they ca= n only get their own information. Also just because an MA is on a specific = broadband line, what information should it really be able to get? Do we nee= d to then have access policies on the MA to control which of this data is t= hen reported to different collectors? -- My thoughts here are that we have 3 distinct events occurring in the fr= amework (Assuming we ignore the MA getting the service attributes) 1) Some controller programs a MA to run tests (BOTs work a lot like this = so high security is required) 2) MA to MA testing occurs - and a "may I run this test" like control pro= tocol is required, however high security (not so much) 3) The MA send test results to the collector (seems light security would = be ok here) For #1 - Given all currently placed elements have some sort of provisio= ning security ... logic would say to use that #2 & #3 are much lighter security issues vs. #1. Cheers, Mike ---------------------- -----Original Message----- From: trevor.burbridge@bt.com [mailto:trevor.burbridge@bt.com]=20 Sent: Tuesday, April 16, 2013 3:19 AM To: Bugenhagen, Michael K; shane@castlepoint.net; bs7652@att.com Cc: lmap@ietf.org Subject: RE: [lmap] LMAP: situation: Q1-Use Cases Making sure that the probe is on the line we expect is certainly a challeng= ing problem, but one that seems to face us regardless of whether the line/s= ubscriber information is being given to the MA or the Collector. In both ca= ses the network can check the IP address used by the MA. It would be nice i= f the MA or any other home device were able to get some broadband identifie= r for its line but that isn't really an LMAP specific capability. I would certainly support a simple way of the MA checking the line identity= . What I don't think it needs to do is retreive further line/subscriber inf= ormation. It seems in this case we're simply pushing information up to the = MA only to collect it back again. Do we want to do this for every possible = parameter that we are going to use for correlation in the data analysis? If= we're not going to do it with all parameters, why do it for a few? - we wo= uld need to add the extra ones in after result collection in that case. Add= ing 20 parameters to 5 columns of test results is also a serious reporting = overhead. There are two other concerns with the MA approach. Firstly we would need ve= ry timely information from the various network OSS providing the parameters= . Doing the splicing after collection removes any tight timing requirements= for the availability of this data (although we do obviously need good time= stamps). Having the MA check these parameters before every test is also a b= ig overhead. Secondly I worry about security (including both privacy and business confid= entialility). Instead of managing an interface with a handful of Collectors= , we need to manage access control for millions of MAs to make sure they ca= n only get their own information. Also just because an MA is on a specific = broadband line, what information should it really be able to get? Do we nee= d to then have access policies on the MA to control which of this data is t= hen reported to different collectors? Just trying to paint the other side to the story. Enhancing the data after = collection is not trivial. However, I think it is the better option than ha= ving the MA do it. Trevor. >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of=20 >Bugenhagen, Michael K >Sent: 15 April 2013 22:07 >To: 'Shane Amante'; STARK, BARBARA H >Cc: lmap@ietf.org >Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > >Shane, Barbara, > > On the architecture including some sort of ISP attribute information=20 > --- > > We could assume the tests are run separately and merged with ISP=20 >information, or we could assume the probe gathers service environment=20 >information and includes it with every test result (does a real-time=20 >encapsulation). >Using the post processing merge framework has significant challenges,=20 >some of which require local network environment validation regardless. > >Examples - > >1) Matching the test probe results to the ISP service attributes - > a) Increases the Challenges associated with creating anonymous data > b) Doesn't reflect when a customer moves a box from one service to=20 >another (it happens) > ** Nothing I know reflects b) other than the probe validating it's=20 >where it should be (what's the environment) so this is required.... > > >2) Service Environment changes > - When a service environment changes (enforcement of a bandwidth cap -=20 >mobile, provisioning speed change, ....) > In order to apply this to a specific test result from a ISP=20 >service record (multiple ones that is) one must. > 1) Create a timeline per service of it's state > 2) Map that state to each test result > > - My thought here is that post processing information from two=20 >different sources drives the solution in the wrong direction by making=20 >the anonymity more difficult, and creating expanded post processing=20 >requirements. > > So having the probe collect and encapsulate the environment with=20 >each test result seems a no brainer to me. > >Just my 2.5 cents... > >Mike > > > > > > > >-----Original Message----- >From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of=20 >Shane Amante >Sent: Monday, April 15, 2013 1:47 PM >To: STARK, BARBARA H >Cc: lmap@ietf.org >Subject: Re: [lmap] LMAP: situation: Q1-Use Cases > >Barbara, > >On Apr 15, 2013, at 7:20 AM, "STARK, BARBARA H" >wrote: >> Further snipping... >> >>>>> However, one addition to this would be that I think it's important=20 >>>>> to share 'service attributes' from a so-called Measurement=20 >>>>> Parameter Server to (a) a Measurement Collector (directly) >>>> >>>> If the ISP who knows the attributes also manages the Data=20 >>>> Collector, then >>> that's intra-domain, and the ISP should be able to figure out how to=20 >>> do that within there OSS network without help from IETF. Therefore,=20 >>> I don't see a need for the intra-domain interface to be in lmap=20 >>> phase 1 scope. If the ISP does not control the Data Collector, then=20 >>> I think this is a much more difficult problem to solve, because it=20 >>> involves the ISP knowing that the Data Collector controlling entity=20 >>> has the end >user's permission to have access to this data. >>> Because of the need for permission with all of its associated need=20 >>> to authenticate the Data Collector and "know" that the end user has=20 >>> authorized that Data Collector (and allow the end user to revoke=20 >>> that authorization, change that authorization, etc.), I consider=20 >>> this a much more complex problem to solve and would prefer for it=20 >>> not to be in >lmap phase 1 scope. >>> >>> At a minimum, the party (e.g.: regulatory entity) who are receiving=20 >>> the "service attributes" from several dozen ISPs would want to=20 >>> receive them in a standards-based data model, (e.g.: XML schema), to=20 >>> make processing of the data contained therein more straightforward. >>> So, for the defined regulatory use case, this should be in scope of=20 >>> "LMAP >Phase 1", right? >> >> Would the xml representation of service attributes provided to a=20 >> "Data Collector" be different than the xml representation provided to a = MA? >> That is, MAs may also need to have a very precise understanding of=20 >> the service attributes being provided to them. Therefore, I saw the=20 >> creation of an xml representation for service attributes to an MA to=20 >> be a very important part of that interface. I guess, though, that a=20 >> Data Collector probably would need additional metadata, so they could=20 >> associate a specific set of collected data with a specific set of=20 >> service attributes. If you think that the service attributes to Data=20 >> Collector would drive additional data elements, then I think it would=20 >> be reasonable to put that interface "in scope", but only for the xml,=20 >> and not for the protocol or authentication/authorization/trust >> modeling. I would also prefer to have just a single set of service=20 >> attribute xml (sufficient for both interfaces), and not separate xml=20 >> for service attributes to MA vs > . >> service attributes to Data Collector. > >Agreed. > >-shane > > >_______________________________________________ >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 shane@castlepoint.net Tue Apr 16 07:16: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 313EA21F971F for ; Tue, 16 Apr 2013 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, J_CHICKENPOX_91=0.6, RDNS_NONE=0.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 R1Xr-ASJ-MFJ for ; Tue, 16 Apr 2013 07:16:02 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5B70321F970C for ; Tue, 16 Apr 2013 07:16:02 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 25CCF30007D for ; Tue, 16 Apr 2013 14:16:02 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 04E1E300062; Tue, 16 Apr 2013 08:15:59 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <20130416140005.GC28527@elstar.local> Date: Tue, 16 Apr 2013 08:15:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130416140005.GC28527@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 16 08:16:02 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516d5d2242071193021194 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+to, 0.01000, be+#+a, 0.01000, LMAP+#+#+Use, 0.01000, from+a, 0.01000, a+#+where, 0.01000, MA+to, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Q1+Use, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, to+#+to, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, they+#+#+#+e, 0.01000, and+or, 0.01000, and+or, 0.01000, Subject*lmap+#+#+Q1-Use, 0.01000, the+#+#+ensure, 0.01000, we+#+to, 0.01000, a+#+#+Server, 0.01000, From*Amante+shane, 0.01000 Cc: trevor.burbridge@bt.com, bs7652@att.com, Michael.K.Bugenhagen@centurylink.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:16:03 -0000 On Apr 16, 2013, at 8:00 AM, Juergen Schoenwaelder = wrote: > On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: >> Trevor, Barbara, >>=20 >> On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >>>> -----Original Message----- >>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>> Sent: 16 April 2013 13:30 >>>> To: Burbridge,T,Trevor,TUB8 R; = Michael.K.Bugenhagen@centurylink.com; >>>> shane@castlepoint.net >>>> Cc: lmap@ietf.org >>>> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >>> [snip] >>>> Trevor, do you object to lmap phase 1 consideration of potential >>>> mechanisms for supplying service attributes to MAs that do not send = data to >>>> the access provider? >>>=20 >>> As you suggest below, the correct question from a requirements = point-of-view is whether we include inter-domain service attribute = transfer in phase 1. I certainly wouldn't push for it. >>=20 >> I think we need to be careful to separate out two aspects of the = service attributes discussion: >> a) Representation of service attributes inside an XML schema. IMO, = it seems this is the right thing to do regardless of whether this is = "intra-" or "inter-"domain, since everyone who is going to = programmatically interpret measurement results is going to want a = standardized representation of "service attributes" to make it = straightforward to parse them. >=20 > How realistic is it that we can define a standard data model for > service attributes that matches a significant portion of the products > out there in the wild? I'm pretty confident it can be done, assuming we confine ourselves to = representing the most common of service attributes: - Upload speed, (in Kbps) - Download speed, (in Kbps) - Service package 'name', (i.e.: product/service-tier as sold) - ISP name - Access technology: DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other? - Customer or Line ID <-- note, this would have to be some pseudo-random = identifier that associates this particular service to a particular = broadband "line", but doesn't reveal anything else about the customer to = ensure privacy/anonymity of the customer. >> b) Transfer of the aforementioned "service attribute XML schema" = from one host to another host and/or from one party to another party. = For this I would ask the question of: why wouldn't we just use HTTP or = HTTPS? In doing so, it would allow LMAP to leverage a variety of = existing, already-specified & implemented authentication mechanisms for = HTTP/HTTPS. And, for that matter, it could be up to ISPs to decide what = they wanted to use, e.g.: simple username/password and/or SSL = certificates. At that point, it's up to a bi-lateral negotiation = between Party A to Party B, (in the context of inter-domain), at the = time they stand up the capability to 'download' (or, upload) the XML = service attribute schema. >=20 > Securing the protocol is not the problem, it is key management that is > usually the problem. Do we expect an MA to have credentials that allow > it to fetch service attributes? How are those credentials managed > during the lifecycle of the MA? It may be much harder to manage the > necessary credentials on thousands of MAs compared to a solution where > a few data collector or a data analysis function fetch service > attributes. (Of course, this still requires proper authorization but > the key management problem seems to be at a very different order of > scale - at least if we can assume #controller << #MAs or=20 > #data-analyzer << #MAs.) +1. Great points. Yet another reason to consider xfer'ing of XML = service attribute schema on a "Network Parameter Server" on ISP A to, = for example, Data Collector owned/operated by Entity B, combined with = post-correlation of customer/line ID in the XML service attribute schema = to measurement performance results. -shane > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From Michael.K.Bugenhagen@centurylink.com Tue Apr 16 07:18:00 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 2EBCE21F96E7 for ; Tue, 16 Apr 2013 07:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_91=0.6] 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 rrbltLKa4OnB for ; Tue, 16 Apr 2013 07:17:59 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id CDB5321F96B4 for ; Tue, 16 Apr 2013 07:17:58 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3GEHrMZ000282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 08:17:53 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B07201E0072; Tue, 16 Apr 2013 09:17:47 -0500 (CDT) Received: from suomp61i.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 8E9BC1E005D; Tue, 16 Apr 2013 09:17:47 -0500 (CDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r3GEHl8p014001; Tue, 16 Apr 2013 09:17:47 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r3GEHkrg013992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 09:17:46 -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; Tue, 16 Apr 2013 09:17:46 -0500 From: "Bugenhagen, Michael K" To: "'Juergen Schoenwaelder'" , "Shane Amante" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgIAABJkAgAAR2ACAAALOgP//sL8g Date: Tue, 16 Apr 2013 14:17:45 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130416140005.GC28527@elstar.local> In-Reply-To: <20130416140005.GC28527@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.117.206.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "trevor.burbridge@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:18:00 -0000 Juergen - Part of the solution to securing the Service attributes is what part o= f the network you have to be attached to in order to obtain it. IMO that should be on the Customer LAN, if the customer lets you attach to = their LAN then at least part of the problem goes away. Regards, Mike -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, April 16, 2013 9:00 AM To: Shane Amante Cc: trevor.burbridge@bt.com; lmap@ietf.org; bs7652@att.com; Bugenhagen, Mic= hael K Subject: Re: [lmap] LMAP: situation: Q1-Use Cases On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: > Trevor, Barbara, >=20 > On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: > >> -----Original Message----- > >> From: STARK, BARBARA H [mailto:bs7652@att.com] > >> Sent: 16 April 2013 13:30 > >> To: Burbridge,T,Trevor,TUB8 R;=20 > >> Michael.K.Bugenhagen@centurylink.com; > >> shane@castlepoint.net > >> Cc: lmap@ietf.org > >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases > > [snip] > >> Trevor, do you object to lmap phase 1 consideration of potential=20 > >> mechanisms for supplying service attributes to MAs that do not send=20 > >> data to the access provider? > >=20 > > As you suggest below, the correct question from a requirements point-of= -view is whether we include inter-domain service attribute transfer in phas= e 1. I certainly wouldn't push for it. >=20 > I think we need to be careful to separate out two aspects of the service = attributes discussion: > a) Representation of service attributes inside an XML schema. IMO, it s= eems this is the right thing to do regardless of whether this is "intra-" o= r "inter-"domain, since everyone who is going to programmatically interpret= measurement results is going to want a standardized representation of "ser= vice attributes" to make it straightforward to parse them. How realistic is it that we can define a standard data model for service at= tributes that matches a significant portion of the products out there in th= e wild? > b) Transfer of the aforementioned "service attribute XML schema" from on= e host to another host and/or from one party to another party. For this I = would ask the question of: why wouldn't we just use HTTP or HTTPS? In doing= so, it would allow LMAP to leverage a variety of existing, already-specifi= ed & implemented authentication mechanisms for HTTP/HTTPS. And, for that m= atter, it could be up to ISPs to decide what they wanted to use, e.g.: simp= le username/password and/or SSL certificates. At that point, it's up to a = bi-lateral negotiation between Party A to Party B, (in the context of inter= -domain), at the time they stand up the capability to 'download' (or, uploa= d) the XML service attribute schema. Securing the protocol is not the problem, it is key management that is usua= lly the problem. Do we expect an MA to have credentials that allow it to fe= tch service attributes? How are those credentials managed during the lifec= ycle of the MA? It may be much harder to manage the necessary credentials o= n thousands of MAs compared to a solution where a few data collector or a d= ata analysis function fetch service attributes. (Of course, this still requ= ires proper authorization but the key management problem seems to be at a v= ery different order of scale - at least if we can assume #controller << #MA= s or #data-analyzer << #MAs.) /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 Michael.K.Bugenhagen@centurylink.com Tue Apr 16 07:28: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 A8F8921F971A for ; Tue, 16 Apr 2013 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_91=0.6] 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 EFfJpUv-G5wx for ; Tue, 16 Apr 2013 07:28:36 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 783DB21F93E9 for ; Tue, 16 Apr 2013 07:28:32 -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 r3GESRTl006577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 09:28:28 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 90DD91E0076; Tue, 16 Apr 2013 08:28:22 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 5C3ED1E004E; Tue, 16 Apr 2013 08:28:22 -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 r3GESL1S029181; Tue, 16 Apr 2013 09:28:21 -0500 (CDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id r3GESJ6J029137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 09:28:21 -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; Tue, 16 Apr 2013 09:28:19 -0500 From: "Bugenhagen, Michael K" To: "'Shane Amante'" , Juergen Schoenwaelder Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgIAABJkAgAAR2ACAAALOgIAABHEA//+tAEA= Date: Tue, 16 Apr 2013 14:28:18 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130416140005.GC28527@elstar.local> 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 Cc: "trevor.burbridge@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:28:37 -0000 Shane - Nice start.. I tweaked changed, and added some This is the (Service attributes from the ISP to the MA context).. I think we'll need the MA to store more information about the Device it'= s in / or on in it's MIB itself... Suggested Tweaks - =20 I split line rate and User information rate..., added PON, and tweaked Pr= oduct name, and Unique ID (removed customer - we're identifying a access se= rvice link, not a person)...=20 Service Attributes -=20 - IP upload speed, (in Kbps) - aka User information rate up - IP download speed, (in Kbps) - aka User information rate down - Link speed upload, (in Kbps) - Link speed download, (in Kbps) - ISP Product name, (i.e.: product/service-tier as sold) - ISP name - Access technology: PON, DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other= ? - Unique Line ID <-- note, this would have to be some pseudo-random identif= ier that associates this particular service to a particular broadband "line= ", but doesn't reveal anything else about the customer to ensure privacy/an= onymity of the customer. Regards, Mike --------------------------------------- -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 Sent: Tuesday, April 16, 2013 9:16 AM To: Juergen Schoenwaelder Cc: trevor.burbridge@bt.com; lmap@ietf.org; bs7652@att.com; Bugenhagen, Mic= hael K Subject: Re: [lmap] LMAP: situation: Q1-Use Cases On Apr 16, 2013, at 8:00 AM, Juergen Schoenwaelder wrote: > On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: >> Trevor, Barbara, >>=20 >> On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >>>> -----Original Message----- >>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>> Sent: 16 April 2013 13:30 >>>> To: Burbridge,T,Trevor,TUB8 R;=20 >>>> Michael.K.Bugenhagen@centurylink.com; >>>> shane@castlepoint.net >>>> Cc: lmap@ietf.org >>>> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >>> [snip] >>>> Trevor, do you object to lmap phase 1 consideration of potential=20 >>>> mechanisms for supplying service attributes to MAs that do not send=20 >>>> data to the access provider? >>>=20 >>> As you suggest below, the correct question from a requirements point-of= -view is whether we include inter-domain service attribute transfer in phas= e 1. I certainly wouldn't push for it. >>=20 >> I think we need to be careful to separate out two aspects of the service= attributes discussion: >> a) Representation of service attributes inside an XML schema. IMO, it = seems this is the right thing to do regardless of whether this is "intra-" = or "inter-"domain, since everyone who is going to programmatically interpre= t measurement results is going to want a standardized representation of "se= rvice attributes" to make it straightforward to parse them. >=20 > How realistic is it that we can define a standard data model for=20 > service attributes that matches a significant portion of the products=20 > out there in the wild? I'm pretty confident it can be done, assuming we confine ourselves to repre= senting the most common of service attributes: - Upload speed, (in Kbps) - Download speed, (in Kbps) - Service package 'name', (i.e.: product/service-tier as sold) - ISP name - Access technology: DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other? - Customer or Line ID <-- note, this would have to be some pseudo-random id= entifier that associates this particular service to a particular broadband = "line", but doesn't reveal anything else about the customer to ensure priva= cy/anonymity of the customer. >> b) Transfer of the aforementioned "service attribute XML schema" from o= ne host to another host and/or from one party to another party. For this I= would ask the question of: why wouldn't we just use HTTP or HTTPS? In doin= g so, it would allow LMAP to leverage a variety of existing, already-specif= ied & implemented authentication mechanisms for HTTP/HTTPS. And, for that = matter, it could be up to ISPs to decide what they wanted to use, e.g.: sim= ple username/password and/or SSL certificates. At that point, it's up to a= bi-lateral negotiation between Party A to Party B, (in the context of inte= r-domain), at the time they stand up the capability to 'download' (or, uplo= ad) the XML service attribute schema. >=20 > Securing the protocol is not the problem, it is key management that is=20 > usually the problem. Do we expect an MA to have credentials that allow=20 > it to fetch service attributes? How are those credentials managed=20 > during the lifecycle of the MA? It may be much harder to manage the=20 > necessary credentials on thousands of MAs compared to a solution where=20 > a few data collector or a data analysis function fetch service=20 > attributes. (Of course, this still requires proper authorization but=20 > the key management problem seems to be at a very different order of=20 > scale - at least if we can assume #controller << #MAs or=20 > #data-analyzer << #MAs.) +1. Great points. Yet another reason to consider xfer'ing of XML service = attribute schema on a "Network Parameter Server" on ISP A to, for example, = Data Collector owned/operated by Entity B, combined with post-correlation o= f customer/line ID in the XML service attribute schema to measurement perfo= rmance results. -shane > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From philip.eardley@bt.com Tue Apr 16 07:30: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 A35AE21F9737 for ; Tue, 16 Apr 2013 07:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 aaOCwt0wCGWN for ; Tue, 16 Apr 2013 07:30:09 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id EC3E121F9736 for ; Tue, 16 Apr 2013 07:30:08 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Apr 2013 15:30:07 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 16 Apr 2013 15:30:07 +0100 From: To: , , Date: Tue, 16 Apr 2013 15:30:06 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAEpiKA= Message-ID: <9510D26531EF184D9017DF24659BB87F34565F8FD3@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:30:09 -0000 > 2) Service Environment changes > - When a service environment changes (enforcement of a bandwidth > cap - mobile, provisioning speed change, ....) > In order to apply this to a specific test result from a ISP > service record (multiple ones that is) one must. > 1) Create a timeline per service of it's state > 2) Map that state to each test result The bandwidth cap is interesting. For the device that enforces (or the one that decides about) a bandwidth ca= p - does anyone know what kind of mgt interface it has? Is the info available? Is it time stamped? From shane@castlepoint.net Tue Apr 16 07:42: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 A14DC21F92C5 for ; Tue, 16 Apr 2013 07:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.463 X-Spam-Level: X-Spam-Status: No, score=0.463 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, J_CHICKENPOX_91=0.6, RDNS_NONE=0.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 7jcMV7EO0llP for ; Tue, 16 Apr 2013 07:42:45 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 31A7121F91A2 for ; Tue, 16 Apr 2013 07:42:45 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id CF3B0300062 for ; Tue, 16 Apr 2013 14:42:44 +0000 (UTC) Received: from mbp.castlepoint.net (184-96-123-182.hlrn.qwest.net [184.96.123.182]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id C661B300035; Tue, 16 Apr 2013 08:42:42 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: Date: Tue, 16 Apr 2013 08:42:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> References: <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130416140005.GC28527@elstar.local> To: "Bugenhagen, Michael K" X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Apr 16 08:42:44 2013 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 516d636442071948469375 X-DSPAM-Factors: 27, 2013+at, 0.01000, 2013+at, 0.01000, Mime-Version*Mail+6.3, 0.01000, to+#+#+#+or, 0.01000, to+#+#+#+to, 0.01000, be+#+a, 0.01000, LMAP+#+#+Use, 0.01000, LMAP+#+#+Use, 0.01000, from+a, 0.01000, a+#+where, 0.01000, MA+to, 0.01000, MA+to, 0.01000, to+#+the, 0.01000, to+#+the, 0.01000, Q1+Use, 0.01000, Q1+Use, 0.01000, to+#+#+in, 0.01000, On+Apr, 0.01000, On+Apr, 0.01000, Michael+#+Bugenhagen, 0.01000, Michael+#+Bugenhagen, 0.01000, service+#+#+a, 0.01000, service+#+#+a, 0.01000, to+#+to, 0.01000, Subject*lmap+#+#+#+Cases, 0.01000, Mime-Version*OS+X, 0.01000, they+#+#+#+e, 0.01000 Cc: "trevor.burbridge@bt.com" , Juergen Schoenwaelder , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:42:46 -0000 Mike, On Apr 16, 2013, at 8:28 AM, "Bugenhagen, Michael K" = wrote: > Shane - Nice start.. I tweaked changed, and added some >=20 > This is the (Service attributes from the ISP to the MA context).. > I think we'll need the MA to store more information about the Device = it's in / or on in it's MIB itself... That could be useful. > Suggested Tweaks - >=20 > I split line rate and User information rate..., added PON, and = tweaked Product name, and Unique ID (removed customer - we're = identifying a access service link, not a person)...=20 Can you clarify why you think splitting "line rate" and "user = information rate" is important? For example, are you trying to = distinguish between throughput with and without packet/framing overhead, = (e.g.: PPPoA/PPPoE overhead?) I was thinking and hoping to avoid that, = because when we're talking about _Internet_ network performance, we're = talking about IP throughput. Plus, IP is thee common denominator across = every access network technology. > Service Attributes -=20 > - IP upload speed, (in Kbps) - aka User information rate up > - IP download speed, (in Kbps) - aka User information rate down > - Link speed upload, (in Kbps) > - Link speed download, (in Kbps) Not sure I understand/agree with the above, yet, but I'm hoping you can = clarify. > - ISP Product name, (i.e.: product/service-tier as sold) > - ISP name > - Access technology: PON, DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, = Other? > - Unique Line ID <-- note, this would have to be some pseudo-random = identifier that associates this particular service to a particular = broadband "line", but doesn't reveal anything else about the customer to = ensure privacy/anonymity of the customer. I like the above modifications. Thanks! -shane > Regards, > Mike >=20 > --------------------------------------- >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Tuesday, April 16, 2013 9:16 AM > To: Juergen Schoenwaelder > Cc: trevor.burbridge@bt.com; lmap@ietf.org; bs7652@att.com; = Bugenhagen, Michael K > Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >=20 >=20 > On Apr 16, 2013, at 8:00 AM, Juergen Schoenwaelder = wrote: >> On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: >>> Trevor, Barbara, >>>=20 >>> On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >>>>> -----Original Message----- >>>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>>> Sent: 16 April 2013 13:30 >>>>> To: Burbridge,T,Trevor,TUB8 R;=20 >>>>> Michael.K.Bugenhagen@centurylink.com; >>>>> shane@castlepoint.net >>>>> Cc: lmap@ietf.org >>>>> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >>>> [snip] >>>>> Trevor, do you object to lmap phase 1 consideration of potential=20= >>>>> mechanisms for supplying service attributes to MAs that do not = send=20 >>>>> data to the access provider? >>>>=20 >>>> As you suggest below, the correct question from a requirements = point-of-view is whether we include inter-domain service attribute = transfer in phase 1. I certainly wouldn't push for it. >>>=20 >>> I think we need to be careful to separate out two aspects of the = service attributes discussion: >>> a) Representation of service attributes inside an XML schema. IMO, = it seems this is the right thing to do regardless of whether this is = "intra-" or "inter-"domain, since everyone who is going to = programmatically interpret measurement results is going to want a = standardized representation of "service attributes" to make it = straightforward to parse them. >>=20 >> How realistic is it that we can define a standard data model for=20 >> service attributes that matches a significant portion of the products=20= >> out there in the wild? >=20 > I'm pretty confident it can be done, assuming we confine ourselves to = representing the most common of service attributes: > - Upload speed, (in Kbps) > - Download speed, (in Kbps) > - Service package 'name', (i.e.: product/service-tier as sold) > - ISP name > - Access technology: DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, = Other? > - Customer or Line ID <-- note, this would have to be some = pseudo-random identifier that associates this particular service to a = particular broadband "line", but doesn't reveal anything else about the = customer to ensure privacy/anonymity of the customer. >=20 >=20 >=20 >>> b) Transfer of the aforementioned "service attribute XML schema" = from one host to another host and/or from one party to another party. = For this I would ask the question of: why wouldn't we just use HTTP or = HTTPS? In doing so, it would allow LMAP to leverage a variety of = existing, already-specified & implemented authentication mechanisms for = HTTP/HTTPS. And, for that matter, it could be up to ISPs to decide what = they wanted to use, e.g.: simple username/password and/or SSL = certificates. At that point, it's up to a bi-lateral negotiation = between Party A to Party B, (in the context of inter-domain), at the = time they stand up the capability to 'download' (or, upload) the XML = service attribute schema. >>=20 >> Securing the protocol is not the problem, it is key management that = is=20 >> usually the problem. Do we expect an MA to have credentials that = allow=20 >> it to fetch service attributes? How are those credentials managed=20 >> during the lifecycle of the MA? It may be much harder to manage the=20= >> necessary credentials on thousands of MAs compared to a solution = where=20 >> a few data collector or a data analysis function fetch service=20 >> attributes. (Of course, this still requires proper authorization but=20= >> the key management problem seems to be at a very different order of=20= >> scale - at least if we can assume #controller << #MAs or=20 >> #data-analyzer << #MAs.) >=20 > +1. Great points. Yet another reason to consider xfer'ing of XML = service attribute schema on a "Network Parameter Server" on ISP A to, = for example, Data Collector owned/operated by Entity B, combined with = post-correlation of customer/line ID in the XML service attribute schema = to measurement performance results. >=20 > -shane >=20 >=20 >> /js >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >>=20 >=20 >=20 >=20 From bs7652@att.com Tue Apr 16 07:52:22 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 69E7221F9765 for ; Tue, 16 Apr 2013 07:52:16 -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 HGEUNuQYAuz7 for ; Tue, 16 Apr 2013 07:52:15 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3C821F9757 for ; Tue, 16 Apr 2013 07:52:08 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8956d615.6ea9a940.118251.00-540.327441.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 16 Apr 2013 14:52:08 +0000 (UTC) X-MXL-Hash: 516d65980832888d-905037d63a74226480bbcaf2d93aa17d4b78a1e8 Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5956d615.0.118226.00-350.327322.nbfkord-smmo07.seg.att.com (envelope-from ); Tue, 16 Apr 2013 14:52:06 +0000 (UTC) X-MXL-Hash: 516d659653510f3f-e1c7b8ed382a18e19df4e958a72699b56c4cc5e5 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GEq4Nn006095; Tue, 16 Apr 2013 10:52:05 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r3GEptFX005962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 10:52:00 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor); Tue, 16 Apr 2013 15:51:36 +0100 Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 10:51:36 -0400 From: "STARK, BARBARA H" To: Shane Amante , "trevor.burbridge@bt.com" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac428lQleMswhgKrTLGGIHCRxvv/WwAxIzsAAAbJ87AAAbV5gAACcgTQAHG+owAAC+CtIAAUgUqAAATfrAAAF3e0gAABF0BQAABcvnAACh7OAAAHHsnw Date: Tue, 16 Apr 2013 14:51:35 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611302A6DC7@GAALPA1MSGUSR9L.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.185.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=OvT4PVDt c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=LX9RdhQRmLMA:10 a=QFZubNyoG38A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=16L39IA0IFsA:10 a=VfgkvVrJ09HErzioGpMA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "Michael.K.Bugenhagen@centurylink.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 14:52:31 -0000 > b) Transfer of the aforementioned "service attribute XML schema" from on= e > host to another host and/or from one party to another party. For this I > would ask the question of: why wouldn't we just use HTTP or HTTPS? In > doing so, it would allow LMAP to leverage a variety of existing, already- > specified & implemented authentication mechanisms for HTTP/HTTPS. And, > for that matter, it could be up to ISPs to decide what they wanted to use= , > e.g.: simple username/password and/or SSL certificates. At that point, i= t's up > to a bi-lateral negotiation between Party A to Party B, (in the context o= f > inter-domain), at the time they stand up the capability to 'download' (or= , > upload) the XML service attribute schema. >=20 > Also, please note that I said: "bi-lateral negotiation" above. IOW, two = parties > are dealing directly with each other, thus they should be able to negotia= te > amongst themselves (out-of-band, of course) what HTTP/HTTPS > mechanism(s) are required to "safely" xfer the XML service attribute > schema, etc. I was hoping to consider the possibility of service discovery mechanisms to= see if "service attribute" data existed somewhere in the home. That is, might the process of figuring out where to direct the MA to find t= he info be made easier if the access provider CE router (if there is one) u= ses something like DNS-SD and/or mDNS to make it easy to find the xml page = on the CE router that can provide the info. BTW, I'm also interested in the MA being able to learn whether the WAN link= is currently in use, so I would expect this to be part of what could be su= pplied to the MA. Even an off-the-shelf CE router might be able to provide = that. But only if the MA had an easy way to find the info and the info were= provided using standard nomenclature. I'm not convinced that every single piece of useful data that the CE router= might provide to other devices inside the home network requires top notch = security credentials to access. I'm not convinced that informing devices in= side the home network about some aspects of the service package is necessar= ily a violation of privacy (where views of privacy vary from country to cou= ntry). After all, these in-home devices are already capable of collecting a= ll sorts of passive measurements, discovering topology, seeing all the serv= ices being advertised in the home (UPnP and Bonjour), running performance t= ests to see what bandwidth is available to them, etc. I do agree that bi-la= teral negotiation of credentials could be a possibility. It may be that the= end user is instructed to put their email address and login (if these are = from the access provider -- which in many cases they are) into the MA. Ther= e's a wide range of possibilities. I'm not interested in figuring out how t= o exchange credentials, but I think it's possible to do without too much tr= ouble, and so it shouldn't be a reason for refusing to allow discussion of = the "info to MA" interface. Anyway, I thought there were some interesting intricacies around mechanisms= for providing ancillary data (including service attributes) to MAs that at= least were worthy of discussion. I'm getting the sense that others would p= refer for such discussion to be out of scope. If that's the consensus, then= I'll be happy to accept it. Barbara From philip.eardley@bt.com Tue Apr 16 09:28: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 40F7821F8E77 for ; Tue, 16 Apr 2013 09:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 baSo3S5Pv+G1 for ; Tue, 16 Apr 2013 09:28:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 699EA21F875C for ; Tue, 16 Apr 2013 09:28:04 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Apr 2013 17:08:20 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 16 Apr 2013 17:08:20 +0100 From: To: , , , Date: Tue, 16 Apr 2013 17:08:19 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgP//vc/QgAApwkA= Message-ID: <9510D26531EF184D9017DF24659BB87F34565F9092@EMV65-UKRD.domain1.systemhost.net> References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 16:28:05 -0000 I think that lmap phase 1 should make the assumption that the measurement s= ystem is under the control of a single organisation (the MA, controller and= collector) - the measurement peer may be under another org's control (eg DNS server) - an MA can run tests if it wants and report results to whoever it wants (c= f. ookla speed tests). Lmap doesn't try to stop this happening (it's up to = customer) I think this assumption simplifies the security and policy considerations a= lot phil > II) Inter-Domain testing classes - > This could be multiple things - we need to define it. > a) MA, Controller, and Collector in one domain, > but a second test MA is outside (no or partial results shared) - IN > SCOPE > b) MA, Controller, and 3rd party Collector - OUT > OF SCOPE > c) 3rd party MA, 3rd party Controller, and 3rd > party Collector - IN SCOPE (supports customer conducting testing) >=20 ... > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Tuesday, April 16, 2013 7:30 AM > To: trevor.burbridge@bt.com; Bugenhagen, Michael K; > shane@castlepoint.net > Cc: lmap@ietf.org > Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >=20 > Trying to focus on what is in scope and not in scope for lmap phase ... >=20 > "Out of scope" are mechanisms/protocols for intra-domain and inter- > domain transfer of service attributes. >=20 > So, Mike and Trevor, are you disagreeing with this "in scope" and "out > of scope" characterization? Specifically... >=20 > Mike, do you object to trying to come up with a holistic service > attribute xml model, that considers the type of data needed by all of > the various transfer usages? >=20 > Trevor, do you object to lmap phase 1 consideration of potential > mechanisms for supplying service attributes to MAs that do not send > data to the access provider? I absolutely agree that sending service > attributes to a system that also gets the collected data is a great way > to go, and how I would recommend an access provider do things, where > the access provider collects the data and has the service attributes. > But I also have no desire to ask the IETF to recommend mechanisms for > getting that data from one internal access provider IT system to > another. Are you wanting IETF to define a mechanism for intra-domain > transfer of service attributes? I'm also not keen on asking IETF to try > to solve the inter-domain transfer problem in lmap phase 1, because I > think it involves 3-way trust relationships, which can be difficult to > manage. To be sufficiently robust and flexible, the end user must be > able to grant and revoke authority for a 3rd party to receive that end > user's service attri butes. The access provider has to trust the end > user is the end user, that the end user has provided that > authorization, and that the 3rd party is indeed the party that the end > user has authorized. Somebody has to manage the trust relationship. > Different regulators might want different ways to manage the trust > relationship. It's complex. Are you wanting to put mechanisms for > inter-domain service attribute transfer in lmap phase 1? >=20 > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From Michael.K.Bugenhagen@centurylink.com Tue Apr 16 10:06:01 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 3BE1821F971F for ; Tue, 16 Apr 2013 10:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 oOxtrPBegpYc for ; Tue, 16 Apr 2013 10:06:00 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE4C21F96FF for ; Tue, 16 Apr 2013 10:06:00 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3GH5p2U022405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 11:05:52 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9E0921E005E; Tue, 16 Apr 2013 11:05:46 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 7F9991E004E; Tue, 16 Apr 2013 11:05:46 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3GH5krI001102; Tue, 16 Apr 2013 11:05:46 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3GH5jxn001096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 11:05:46 -0600 (MDT) 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; Tue, 16 Apr 2013 12:05:44 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "bs7652@att.com" , "trevor.burbridge@bt.com" , "shane@castlepoint.net" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgP//vc/QgAApwkCAABGdEA== Date: Tue, 16 Apr 2013 17:05:44 +0000 Message-ID: References: <2D09D61DDFA73D4C884805CC7865E611302A3E19@GAALPA1MSGUSR9L.ITServices.sbc.com> <9A49517D-038D-4E0B-B34C-A78ABEAFC130@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A55C2@GAALPA1MSGUSR9L.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E611302A5785@GAALPA1MSGUSR9L.ITServices.sbc.com> <7F2C3930-26BA-4EC5-8481-70D3B89A0837@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F34565F9092@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F9092@EMV65-UKRD.domain1.systemhost.net> 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 Cc: "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 17:06:01 -0000 Phil, I concur, I like yours it's simpler and cleaner... --M -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of phi= lip.eardley@bt.com Sent: Tuesday, April 16, 2013 11:08 AM To: Bugenhagen, Michael K; bs7652@att.com; trevor.burbridge@bt.com; shane@c= astlepoint.net Cc: lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-Use Cases I think that lmap phase 1 should make the assumption that the measurement s= ystem is under the control of a single organisation (the MA, controller and= collector) - the measurement peer may be under another org's control (eg DNS server) - an MA can run tests if it wants and report results to whoever it wants (c= f. ookla speed tests). Lmap doesn't try to stop this happening (it's up to = customer) I think this assumption simplifies the security and policy considerations a= lot phil > II) Inter-Domain testing classes - > This could be multiple things - we need to define it. > a) MA, Controller, and Collector in one domain, but a second test=20 > MA is outside (no or partial results shared) - IN SCOPE > b) MA, Controller, and 3rd party Collector - OUT OF SCOPE > c) 3rd party MA, 3rd party Controller, and 3rd party Collector -=20 > IN SCOPE (supports customer conducting testing) >=20 ... > -----Original Message----- > From: STARK, BARBARA H [mailto:bs7652@att.com] > Sent: Tuesday, April 16, 2013 7:30 AM > To: trevor.burbridge@bt.com; Bugenhagen, Michael K;=20 > shane@castlepoint.net > Cc: lmap@ietf.org > Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >=20 > Trying to focus on what is in scope and not in scope for lmap phase ... >=20 > "Out of scope" are mechanisms/protocols for intra-domain and inter-=20 > domain transfer of service attributes. >=20 > So, Mike and Trevor, are you disagreeing with this "in scope" and "out=20 > of scope" characterization? Specifically... >=20 > Mike, do you object to trying to come up with a holistic service=20 > attribute xml model, that considers the type of data needed by all of=20 > the various transfer usages? >=20 > Trevor, do you object to lmap phase 1 consideration of potential=20 > mechanisms for supplying service attributes to MAs that do not send=20 > data to the access provider? I absolutely agree that sending service=20 > attributes to a system that also gets the collected data is a great=20 > way to go, and how I would recommend an access provider do things,=20 > where the access provider collects the data and has the service attribute= s. > But I also have no desire to ask the IETF to recommend mechanisms for=20 > getting that data from one internal access provider IT system to=20 > another. Are you wanting IETF to define a mechanism for intra-domain=20 > transfer of service attributes? I'm also not keen on asking IETF to=20 > try to solve the inter-domain transfer problem in lmap phase 1,=20 > because I think it involves 3-way trust relationships, which can be=20 > difficult to manage. To be sufficiently robust and flexible, the end=20 > user must be able to grant and revoke authority for a 3rd party to=20 > receive that end user's service attri butes. The access provider has=20 > to trust the end user is the end user, that the end user has provided=20 > that authorization, and that the 3rd party is indeed the party that=20 > the end user has authorized. Somebody has to manage the trust relationshi= p. > Different regulators might want different ways to manage the trust=20 > relationship. It's complex. Are you wanting to put mechanisms for=20 > inter-domain service attribute transfer in lmap phase 1? >=20 > Barbara >=20 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Tue Apr 16 12:37:28 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 E1C9621F9748 for ; Tue, 16 Apr 2013 12:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 RGYcbTV4Oc0p for ; Tue, 16 Apr 2013 12:37:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CE8ED21F9742 for ; Tue, 16 Apr 2013 12:37:27 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3282420C02; Tue, 16 Apr 2013 21:37: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 GZlqhaKz7bDr; Tue, 16 Apr 2013 21:37: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 5FD422090B; Tue, 16 Apr 2013 21:37:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4AF1025A8766; Tue, 16 Apr 2013 21:37:33 +0200 (CEST) Date: Tue, 16 Apr 2013 21:37:33 +0200 From: Juergen Schoenwaelder To: "Bugenhagen, Michael K" Message-ID: <20130416193733.GB29261@elstar.local> Mail-Followup-To: "Bugenhagen, Michael K" , 'Shane Amante' , "trevor.burbridge@bt.com" , "bs7652@att.com" , "lmap@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E611302A665F@GAALPA1MSGUSR9L.ITServices.sbc.com> <35FB5A98-D505-4121-9F14-798EA11A4D3F@castlepoint.net> <2D09D61DDFA73D4C884805CC7865E611302A6C80@GAALPA1MSGUSR9L.ITServices.sbc.com> <20130416140005.GC28527@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Shane Amante' , "trevor.burbridge@bt.com" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-Use Cases 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: Tue, 16 Apr 2013 19:37:29 -0000 On Tue, Apr 16, 2013 at 02:28:18PM +0000, Bugenhagen, Michael K wrote: > Shane - Nice start.. I tweaked changed, and added some > > This is the (Service attributes from the ISP to the MA context).. > I think we'll need the MA to store more information about the Device it's in / or on in it's MIB itself... > > > Suggested Tweaks - > > I split line rate and User information rate..., added PON, and tweaked Product name, and Unique ID (removed customer - we're identifying a access service link, not a person)... > > > Service Attributes - > - IP upload speed, (in Kbps) - aka User information rate up > - IP download speed, (in Kbps) - aka User information rate down > - Link speed upload, (in Kbps) > - Link speed download, (in Kbps) > - ISP Product name, (i.e.: product/service-tier as sold) > - ISP name > - Access technology: PON, DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other? > - Unique Line ID <-- note, this would have to be some pseudo-random identifier that associates this particular service to a particular broadband "line", but doesn't reveal anything else about the customer to ensure privacy/anonymity of the customer. > I have heard about service contracts where there are limits like a certain amount of data (with varying definitions of 'data') per month (or some other time frame) and traffic shaping by the provider is explicitely allowed either if you reach the data limit or if you inject traffic that is for some reason disliked by the ISP (e.g. they reserve the right to throttle p2p traffic). If we consider cellular networks, things can get even more interesting. The devil really is in the details. What does Kbps mean? What does 'amount of data' mean? What does throttling mean? How do you report whether the line is being throttled due to the fact that the traffic crossed some threshold or carries stuff that somehow is disliked by the ISP (see some of the Glasnost results)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jason.weil@twcable.com Tue Apr 16 12:41:17 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 E146421F9488 for ; Tue, 16 Apr 2013 12:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 2tC1ctZAH9um for ; Tue, 16 Apr 2013 12:41:17 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4153821F947C for ; Tue, 16 Apr 2013 12:41:17 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,487,1363147200"; d="scan'208";a="59923973" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Apr 2013 15:40:58 -0400 Received: from PRVPEXVS11.corp.twcable.com ([10.136.163.42]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 16 Apr 2013 15:41:16 -0400 From: "Weil, Jason" To: "trevor.burbridge@bt.com" , "bs7652@att.com" Date: Tue, 16 Apr 2013 15:41:19 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac462lwki+LMJHYTRVuUkQT4MiTTbQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 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] LMAP: situation: Q1-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: Tue, 16 Apr 2013 19:41:18 -0000 [Snip] "...On getting service attributes to the MA, the only question is whether there is a single standard way of doing that in LMAP. I'm not saying there shouldn't be ways of doing it. Some ISPs might push this info to the home gateway. Others might provide it on the customer web portal." A pull model may be useful as well where the MA requests service attribute information from an service attribute service. The service offering that information could offer varying level of information detail based on the trust relationship with the MA. Jason On 4/16/13 9:42 AM, "trevor.burbridge@bt.com" wrote: >>-----Original Message----- >>From: STARK, BARBARA H [mailto:bs7652@att.com] >>Sent: 16 April 2013 14:32 >>To: Burbridge,T,Trevor,TUB8 R >>Cc: lmap@ietf.org >>Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >> >>> >Trevor, do you object to lmap phase 1 consideration of potential >>> >mechanisms for supplying service attributes to MAs that do not send >>> >data to the access provider? >>> >>> As you suggest below, the correct question from a requirements >>> point-of- view is whether we include inter-domain service attribute >>> transfer in phase 1. I certainly wouldn't push for it. >>> >>> For intra-domain, do I think the correct implementation is via the MA >>>- no. >>> Would this change if inter-domain was in scope? Not convinced. >> >>Hi Trevor, >>OK. I hear you, but I disagree that "service attribute to MA" should be >>"out >>of scope". I would like for some sort of solution to exist where a 3rd >>party >>can manage the MA and collect the MA's data, and have the MA in that case >>be able to get service attributes. This doesn't mean that I want there >>to be a >>BCP recommending this method. It doesn't mean it should preclude >>architectures where the access provider does data collection. It does >>mean >>that I don't think there is a "one size fits all" way to architect >>measurement >>collection that will be "the" right way for every provider and every >>government in the world. It means I want the mechanism to exist and be >>defined, and be available to whoever wants to implement it. >> >>I also think that providing an MA with service attributes is useful in >>the case >>where the end user just wants to run his/her own tests and not share the >>data with anybody. End users should be able to have access to their >>service >>attributes. >>Barbara > >Not sure we're disagreeing. > >I'm not precluding the MA reporting stuff. The report information model >may contain context information. Certainly any individual test result is >free to report whatever measured or local parameters it wants to. > >On getting service attributes to the MA, the only question is whether >there is a single standard way of doing that in LMAP. I'm not saying >there shouldn't be ways of doing it. Some ISPs might push this info to >the home gateway. Others might provide it on the customer web portal. > >Trevor. >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jason.weil@twcable.com Tue Apr 16 12:50: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 3783221F9721 for ; Tue, 16 Apr 2013 12:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.563 X-Spam-Level: X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_43=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 gPPrBCmn+8QN for ; Tue, 16 Apr 2013 12:50:15 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DB2BC21F9717 for ; Tue, 16 Apr 2013 12:50:14 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,487,1363147200"; d="scan'208";a="59929388" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Apr 2013 15:49:55 -0400 Received: from PRVPEXVS11.corp.twcable.com ([10.136.163.42]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 16 Apr 2013 15:50:14 -0400 From: "Weil, Jason" To: Shane Amante , "Bugenhagen, Michael K" Date: Tue, 16 Apr 2013 15:50:17 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac4625y3InASzKwWShGECEaI0lUpCg== Message-ID: In-Reply-To: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "trevor.burbridge@bt.com" , Juergen Schoenwaelder , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 19:50:16 -0000 I'm confused on why a distinction is needed between provisioned speed (user information rate) and link speed as well.How would bonded links be described by this link attribute? Jason On 4/16/13 10:42 AM, "Shane Amante" wrote: >Mike, > >On Apr 16, 2013, at 8:28 AM, "Bugenhagen, Michael K" > wrote: >> Shane - Nice start.. I tweaked changed, and added some >> >> This is the (Service attributes from the ISP to the MA context).. >> I think we'll need the MA to store more information about the Device >>it's in / or on in it's MIB itself... > >That could be useful. > > >> Suggested Tweaks - >> >> I split line rate and User information rate..., added PON, and tweaked >>Product name, and Unique ID (removed customer - we're identifying a >>access service link, not a person)... > >Can you clarify why you think splitting "line rate" and "user information >rate" is important? For example, are you trying to distinguish between >throughput with and without packet/framing overhead, (e.g.: PPPoA/PPPoE >overhead?) I was thinking and hoping to avoid that, because when we're >talking about _Internet_ network performance, we're talking about IP >throughput. Plus, IP is thee common denominator across every access >network technology. > > >> Service Attributes - >> - IP upload speed, (in Kbps) - aka User information rate up >> - IP download speed, (in Kbps) - aka User information rate down >> - Link speed upload, (in Kbps) >> - Link speed download, (in Kbps) > >Not sure I understand/agree with the above, yet, but I'm hoping you can >clarify. > > >> - ISP Product name, (i.e.: product/service-tier as sold) >> - ISP name >> - Access technology: PON, DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, >>Other? >> - Unique Line ID <-- note, this would have to be some pseudo-random >>identifier that associates this particular service to a particular >>broadband "line", but doesn't reveal anything else about the customer to >>ensure privacy/anonymity of the customer. > >I like the above modifications. > >Thanks! > >-shane > > >> Regards, >> Mike >> >> --------------------------------------- >> >> >> >> >> >> >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Tuesday, April 16, 2013 9:16 AM >> To: Juergen Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org; bs7652@att.com; Bugenhagen, >>Michael K >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >> >> >> On Apr 16, 2013, at 8:00 AM, Juergen Schoenwaelder >> wrote: >>> On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: >>>> Trevor, Barbara, >>>> >>>> On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >>>>>> -----Original Message----- >>>>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>>>> Sent: 16 April 2013 13:30 >>>>>> To: Burbridge,T,Trevor,TUB8 R; >>>>>> Michael.K.Bugenhagen@centurylink.com; >>>>>> shane@castlepoint.net >>>>>> Cc: lmap@ietf.org >>>>>> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >>>>> [snip] >>>>>> Trevor, do you object to lmap phase 1 consideration of potential >>>>>> mechanisms for supplying service attributes to MAs that do not send >>>>>> data to the access provider? >>>>> >>>>> As you suggest below, the correct question from a requirements >>>>>point-of-view is whether we include inter-domain service attribute >>>>>transfer in phase 1. I certainly wouldn't push for it. >>>> >>>> I think we need to be careful to separate out two aspects of the >>>>service attributes discussion: >>>> a) Representation of service attributes inside an XML schema. IMO, >>>>it seems this is the right thing to do regardless of whether this is >>>>"intra-" or "inter-"domain, since everyone who is going to >>>>programmatically interpret measurement results is going to want a >>>>standardized representation of "service attributes" to make it >>>>straightforward to parse them. >>> >>> How realistic is it that we can define a standard data model for >>> service attributes that matches a significant portion of the products >>> out there in the wild? >> >> I'm pretty confident it can be done, assuming we confine ourselves to >>representing the most common of service attributes: >> - Upload speed, (in Kbps) >> - Download speed, (in Kbps) >> - Service package 'name', (i.e.: product/service-tier as sold) >> - ISP name >> - Access technology: DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other? >> - Customer or Line ID <-- note, this would have to be some >>pseudo-random identifier that associates this particular service to a >>particular broadband "line", but doesn't reveal anything else about the >>customer to ensure privacy/anonymity of the customer. >> >> >> >>>> b) Transfer of the aforementioned "service attribute XML schema" >>>>from one host to another host and/or from one party to another party. >>>>For this I would ask the question of: why wouldn't we just use HTTP or >>>>HTTPS? In doing so, it would allow LMAP to leverage a variety of >>>>existing, already-specified & implemented authentication mechanisms >>>>for HTTP/HTTPS. And, for that matter, it could be up to ISPs to >>>>decide what they wanted to use, e.g.: simple username/password and/or >>>>SSL certificates. At that point, it's up to a bi-lateral negotiation >>>>between Party A to Party B, (in the context of inter-domain), at the >>>>time they stand up the capability to 'download' (or, upload) the XML >>>>service attribute schema. >>> >>> Securing the protocol is not the problem, it is key management that is >>> usually the problem. Do we expect an MA to have credentials that allow >>> it to fetch service attributes? How are those credentials managed >>> during the lifecycle of the MA? It may be much harder to manage the >>> necessary credentials on thousands of MAs compared to a solution where >>> a few data collector or a data analysis function fetch service >>> attributes. (Of course, this still requires proper authorization but >>> the key management problem seems to be at a very different order of >>> scale - at least if we can assume #controller << #MAs or >>> #data-analyzer << #MAs.) >> >> +1. Great points. Yet another reason to consider xfer'ing of XML >>service attribute schema on a "Network Parameter Server" on ISP A to, >>for example, Data Collector owned/operated by Entity B, combined with >>post-correlation of customer/line ID in the XML service attribute schema >>to measurement performance results. >> >> -shane >> >> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >> >> >> > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jason.weil@twcable.com Tue Apr 16 12:51: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 D56BE21F9742 for ; Tue, 16 Apr 2013 12:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 5sIT6UDpef2b for ; Tue, 16 Apr 2013 12:51:40 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id AEF2A21F972B for ; Tue, 16 Apr 2013 12:51:32 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,487,1363147200"; d="scan'208";a="58231684" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Apr 2013 15:51:11 -0400 Received: from PRVPEXVS11.corp.twcable.com ([10.136.163.42]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 16 Apr 2013 15:51:32 -0400 From: "Weil, Jason" To: "philip.eardley@bt.com" , "Michael.K.Bugenhagen@centurylink.com" , "bs7652@att.com" , "trevor.burbridge@bt.com" , "shane@castlepoint.net" Date: Tue, 16 Apr 2013 15:51:35 -0400 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: Ac4628rdH5xe25FRQxCfG6bPdkT+2Q== Message-ID: In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F9092@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 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] LMAP: situation: Q1-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: Tue, 16 Apr 2013 19:51:50 -0000 Phil, I agree, phase 1 scope should be limited to a single organization under control of the MA, Controller and Collector with the caveat that the MA in this set should be MA that resides within the end-user's environment. Jason As an aside, I see the argument for MA being a general term to cover both endpoints, On 4/16/13 12:08 PM, "philip.eardley@bt.com" wrote: >I think that lmap phase 1 should make the assumption that the measurement >system is under the control of a single organisation (the MA, controller >and collector) > >- the measurement peer may be under another org's control (eg DNS server) >- an MA can run tests if it wants and report results to whoever it wants >(cf. ookla speed tests). Lmap doesn't try to stop this happening (it's up >to customer) > >I think this assumption simplifies the security and policy considerations >a lot > >phil > > >> II) Inter-Domain testing classes - >> This could be multiple things - we need to define i= t. >> a) MA, Controller, and Collector in one do= main, >> but a second test MA is outside (no or partial results shared) - IN >> SCOPE >> b) MA, Controller, and 3rd party Collector= - OUT >> OF SCOPE >> c) 3rd party MA, 3rd party Controller, and= 3rd >> party Collector - IN SCOPE (supports customer conducting testing) >> >... >> -----Original Message----- >> From: STARK, BARBARA H [mailto:bs7652@att.com] >> Sent: Tuesday, April 16, 2013 7:30 AM >> To: trevor.burbridge@bt.com; Bugenhagen, Michael K; >> shane@castlepoint.net >> Cc: lmap@ietf.org >> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >> >> Trying to focus on what is in scope and not in scope for lmap phase >... >> >> "Out of scope" are mechanisms/protocols for intra-domain and inter- >> domain transfer of service attributes. >> >> So, Mike and Trevor, are you disagreeing with this "in scope" and "out >> of scope" characterization? Specifically... >> >> Mike, do you object to trying to come up with a holistic service >> attribute xml model, that considers the type of data needed by all of >> the various transfer usages? >> >> Trevor, do you object to lmap phase 1 consideration of potential >> mechanisms for supplying service attributes to MAs that do not send >> data to the access provider? I absolutely agree that sending service >> attributes to a system that also gets the collected data is a great way >> to go, and how I would recommend an access provider do things, where >> the access provider collects the data and has the service attributes. >> But I also have no desire to ask the IETF to recommend mechanisms for >> getting that data from one internal access provider IT system to >> another. Are you wanting IETF to define a mechanism for intra-domain >> transfer of service attributes? I'm also not keen on asking IETF to try >> to solve the inter-domain transfer problem in lmap phase 1, because I >> think it involves 3-way trust relationships, which can be difficult to >> manage. To be sufficiently robust and flexible, the end user must be >> able to grant and revoke authority for a 3rd party to receive that end >> user's service attri butes. The access provider has to trust the end >> user is the end user, that the end user has provided that >> authorization, and that the 3rd party is indeed the party that the end >> user has authorized. Somebody has to manage the trust relationship. >> Different regulators might want different ways to manage the trust >> relationship. It's complex. Are you wanting to put mechanisms for >> inter-domain service attribute transfer in lmap phase 1? >> >> Barbara >> >> _______________________________________________ >> lmap mailing list >> lmap@ietf.org >> https://www.ietf.org/mailman/listinfo/lmap >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From Michael.K.Bugenhagen@centurylink.com Tue Apr 16 13:04:22 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 A62E921F96C7 for ; Tue, 16 Apr 2013 13:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_91=0.6] 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 WdpaLnp7AxzS for ; Tue, 16 Apr 2013 13:04:21 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE9821F964F for ; Tue, 16 Apr 2013 13:04:21 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r3GK4GPM015511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 14:04:16 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 09DB81E005E; Tue, 16 Apr 2013 14:04:11 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id DE7511E0035; Tue, 16 Apr 2013 14:04:10 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r3GK4AoH001253; Tue, 16 Apr 2013 14:04:10 -0600 (MDT) Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.qintra.com [151.117.206.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id r3GK4A66001245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 14:04:10 -0600 (MDT) 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; Tue, 16 Apr 2013 15:04:09 -0500 From: "Bugenhagen, Michael K" To: "'Weil, Jason'" , Shane Amante Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgIAABJkAgAAR2ACAAALOgIAABHEA//+tAECAAFp2gIAAVfKA//+uO8A= Date: Tue, 16 Apr 2013 20:04:09 +0000 Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> 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 Cc: "trevor.burbridge@bt.com" , Juergen Schoenwaelder , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Tue, 16 Apr 2013 20:04:22 -0000 Jason, Short answer to why link rate & User info rate (IP throughput capacity). Some ISP's sell service at the link rate, others sell service as the IP th= roughput rate (only universal standards). So for a customer to identify what they bought and it's IP throughput capa= city (user info rate) they need both in order to relate that to the ISP ser= vice terms. Plus, IP throughput capacity is a big deal for the customer. Why did selling link rate happen (IMO) - Historically before IP was the universal protocol for User information r= ate the "access" link rate was standard and then what ever protocol or chan= nel partitioning impacted the actual user information rate. So when DSL wa= s created they followed the status Quo (not everyone but some) and sell "li= nk rate" or "train rate" - however given the IP was over ATM they had overh= ead, and the actual user information rate (IP rate) is lower than the link = rate. Mike =20 =20 -----Original Message----- From: Weil, Jason [mailto:jason.weil@twcable.com]=20 Sent: Tuesday, April 16, 2013 2:50 PM To: Shane Amante; Bugenhagen, Michael K Cc: trevor.burbridge@bt.com; Juergen Schoenwaelder; bs7652@att.com; lmap@ie= tf.org Subject: Re: [lmap] LMAP: situation: Q1-Use Cases I'm confused on why a distinction is needed between provisioned speed (user= information rate) and link speed as well.How would bonded links be describ= ed by this link attribute? Jason On 4/16/13 10:42 AM, "Shane Amante" wrote: >Mike, > >On Apr 16, 2013, at 8:28 AM, "Bugenhagen, Michael K" > wrote: >> Shane - Nice start.. I tweaked changed, and added some >> >> This is the (Service attributes from the ISP to the MA context).. >> I think we'll need the MA to store more information about the=20 >>Device it's in / or on in it's MIB itself... > >That could be useful. > > >> Suggested Tweaks - >> >> I split line rate and User information rate..., added PON, and=20 >>tweaked Product name, and Unique ID (removed customer - we're=20 >>identifying a access service link, not a person)... > >Can you clarify why you think splitting "line rate" and "user=20 >information rate" is important? For example, are you trying to=20 >distinguish between throughput with and without packet/framing=20 >overhead, (e.g.: PPPoA/PPPoE >overhead?) I was thinking and hoping to avoid that, because when we're=20 >talking about _Internet_ network performance, we're talking about IP=20 >throughput. Plus, IP is thee common denominator across every access=20 >network technology. > > >> Service Attributes - >> - IP upload speed, (in Kbps) - aka User information rate up >> - IP download speed, (in Kbps) - aka User information rate down >> - Link speed upload, (in Kbps) >> - Link speed download, (in Kbps) > >Not sure I understand/agree with the above, yet, but I'm hoping you can=20 >clarify. > > >> - ISP Product name, (i.e.: product/service-tier as sold) >> - ISP name >> - Access technology: PON, DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular,=20 >>Other? >> - Unique Line ID <-- note, this would have to be some pseudo-random=20 >>identifier that associates this particular service to a particular=20 >>broadband "line", but doesn't reveal anything else about the customer=20 >>to ensure privacy/anonymity of the customer. > >I like the above modifications. > >Thanks! > >-shane > > >> Regards, >> Mike >> >> --------------------------------------- >> >> >> >> >> >> >> -----Original Message----- >> From: Shane Amante [mailto:shane@castlepoint.net] >> Sent: Tuesday, April 16, 2013 9:16 AM >> To: Juergen Schoenwaelder >> Cc: trevor.burbridge@bt.com; lmap@ietf.org; bs7652@att.com;=20 >>Bugenhagen, Michael K >> Subject: Re: [lmap] LMAP: situation: Q1-Use Cases >> >> >> On Apr 16, 2013, at 8:00 AM, Juergen Schoenwaelder=20 >> wrote: >>> On Tue, Apr 16, 2013 at 07:50:02AM -0600, Shane Amante wrote: >>>> Trevor, Barbara, >>>> >>>> On Apr 16, 2013, at 6:46 AM, trevor.burbridge@bt.com wrote: >>>>>> -----Original Message----- >>>>>> From: STARK, BARBARA H [mailto:bs7652@att.com] >>>>>> Sent: 16 April 2013 13:30 >>>>>> To: Burbridge,T,Trevor,TUB8 R; >>>>>> Michael.K.Bugenhagen@centurylink.com; >>>>>> shane@castlepoint.net >>>>>> Cc: lmap@ietf.org >>>>>> Subject: RE: [lmap] LMAP: situation: Q1-Use Cases >>>>> [snip] >>>>>> Trevor, do you object to lmap phase 1 consideration of potential=20 >>>>>> mechanisms for supplying service attributes to MAs that do not=20 >>>>>> send data to the access provider? >>>>> >>>>> As you suggest below, the correct question from a requirements=20 >>>>>point-of-view is whether we include inter-domain service attribute=20 >>>>>transfer in phase 1. I certainly wouldn't push for it. >>>> >>>> I think we need to be careful to separate out two aspects of the=20 >>>>service attributes discussion: >>>> a) Representation of service attributes inside an XML schema. =20 >>>>IMO, it seems this is the right thing to do regardless of whether=20 >>>>this is "intra-" or "inter-"domain, since everyone who is going to=20 >>>>programmatically interpret measurement results is going to want a=20 >>>>standardized representation of "service attributes" to make it=20 >>>>straightforward to parse them. >>> >>> How realistic is it that we can define a standard data model for=20 >>> service attributes that matches a significant portion of the=20 >>> products out there in the wild? >> >> I'm pretty confident it can be done, assuming we confine ourselves to=20 >>representing the most common of service attributes: >> - Upload speed, (in Kbps) >> - Download speed, (in Kbps) >> - Service package 'name', (i.e.: product/service-tier as sold) >> - ISP name >> - Access technology: DSL, DOCSIS, FTTH, WiFi, Wireless/Cellular, Other? >> - Customer or Line ID <-- note, this would have to be some=20 >>pseudo-random identifier that associates this particular service to a=20 >>particular broadband "line", but doesn't reveal anything else about=20 >>the customer to ensure privacy/anonymity of the customer. >> >> >> >>>> b) Transfer of the aforementioned "service attribute XML schema" >>>>from one host to another host and/or from one party to another party. >>>>For this I would ask the question of: why wouldn't we just use HTTP=20 >>>>or HTTPS? In doing so, it would allow LMAP to leverage a variety of=20 >>>>existing, already-specified & implemented authentication mechanisms=20 >>>>for HTTP/HTTPS. And, for that matter, it could be up to ISPs to=20 >>>>decide what they wanted to use, e.g.: simple username/password=20 >>>>and/or SSL certificates. At that point, it's up to a bi-lateral=20 >>>>negotiation between Party A to Party B, (in the context of=20 >>>>inter-domain), at the time they stand up the capability to=20 >>>>'download' (or, upload) the XML service attribute schema. >>> >>> Securing the protocol is not the problem, it is key management that=20 >>> is usually the problem. Do we expect an MA to have credentials that=20 >>> allow it to fetch service attributes? How are those credentials=20 >>> managed during the lifecycle of the MA? It may be much harder to=20 >>> manage the necessary credentials on thousands of MAs compared to a=20 >>> solution where a few data collector or a data analysis function=20 >>> fetch service attributes. (Of course, this still requires proper=20 >>> authorization but the key management problem seems to be at a very=20 >>> different order of scale - at least if we can assume #controller <<=20 >>> #MAs or #data-analyzer << #MAs.) >> >> +1. Great points. Yet another reason to consider xfer'ing of XML >>service attribute schema on a "Network Parameter Server" on ISP A to,=20 >>for example, Data Collector owned/operated by Entity B, combined with=20 >>post-correlation of customer/line ID in the XML service attribute=20 >>schema to measurement performance results. >> >> -shane >> >> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >> >> >> > > >_______________________________________________ >lmap mailing list >lmap@ietf.org >https://www.ietf.org/mailman/listinfo/lmap This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From philip.eardley@bt.com Wed Apr 17 04:08: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 66EB521F894B for ; Wed, 17 Apr 2013 04:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 nlQ7Di2BatMl for ; Wed, 17 Apr 2013 04:08:18 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id CF1B621F8940 for ; Wed, 17 Apr 2013 04:08:17 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 17 Apr 2013 12:08:16 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 17 Apr 2013 12:08:16 +0100 From: To: , , Date: Wed, 17 Apr 2013 12:08:15 +0100 Thread-Topic: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-00.txt Thread-Index: Ac46HfZxV93nGr10TJWEA9O7xHBpogAhMigQAC4fSgA= Message-ID: <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net> References: <20130415191457.GA25223@elstar.local> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-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: Wed, 17 Apr 2013 11:08:19 -0000 I much prefer Juergen's suggestion of Measurement Agent and Measurement Pee= r. Thanks! two suggestions: 1. think worth the definitions saying, "Colloquially, a Measurement Agent (= /Peer) is a physical device that performs this function." 2.=20 > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. After the ; could we simply have "perhaps in concert with a Measurement Peer" Or do you have something else in mind? phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: 16 April 2013 14:28 > To: Brian Trammell; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] measurement agent terminology in draft-eardley- > lmap-terminology-00.txt >=20 > Juergen wrote: > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. >=20 > Brian wrote: > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > >=20 > This single name is closer to what I was thinking "terminologically" > last October. > There will be cases (I believe) where one MA is Instructed to perform > some measurements, but is simply a measurement peer for other > measurement sessions. >=20 > After initialization and instruction, different MAs can be > distinguished by the named roles of the measurement protocol they use > to execute the instructions. > Some MAs may only be initialized, then sit and wait to be contacted by > other MAs. >=20 > A small tweak at the end: > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. >=20 > (either MA can reject a test session, following the CAC discussion > yesterday) >=20 > Al >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Monday, April 15, 2013 5:12 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] measurement agent terminology in > > draft-eardley-lmap- terminology-00.txt > > > > Hi, Juergen, all. > > > > +1. Comments inline. > > > > On 16 Apr 2013, at 7:14, Juergen Schoenwaelder > > wrote: > > > > > Hi, > > > > > > I have an issue with the terms Measurement Agent, Remote > Measurement > > > Agent and Complete Measurement Agents as defined in the I-D. I do > > > not really see why we need all three and I am concerned that we > make > > > the most frequently needed term the most complex to write and spell > out. > > > > > > My understanding is that LMAP defines Control Protocol and a Report > > > Protocol between a Controller / Collector and - well the rather > ugly > > > term "Complete Measurement Agent". Note that these specifications > > > will have to talk a lot about this entity - which has the weirdest > > > and longest name. > > > > > > Furthermore, I see little value of the term Measurement Agent > > > because the Remote Measurement Agents and the Complete Measurement > > > Agents really do very different things from an LMAP protocol > > > perspective (The Remote Measurement Agent does not nothing, the > > > Complete Measurement Agent does all.) I also think the current > > > definition of Measurement Agent is likely misleading - instead of > > > 'performs' one should perhaps use 'is involved in'. (If I throw a > > > packet at a DNS server of an HTTP server, I consider this server to > > > be involved in the test, not to perform this test.) > > > > Agree completely. > > > > LMAP sits between the Controller and the measurement>. > > How that does measurement is _only_ in scope to the extent > > that a Controller has to know about it in order to coordinate its > > actions. I can't think of any arrangement of such components > requiring > > the Controller to manage distributed parts of a that is less > > complicated and more robust than one in which the Controller has a > > single part of the to which it delegates the distributed > arrangement. > > > > (There may be complexities of measurement device _management_ -- > > upgrading software, collecting load stats and other metadata, and so > > on -- that might be simplified by a Controller knowing about every > > subcomponent, but this is also questionably in scope.) > > > > > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > > > Best regards, > > > > Brian > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From sharam.hakimi@exfo.com Wed Apr 17 13:58: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 38A2821E80AB for ; Wed, 17 Apr 2013 13:58:13 -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 5AjSu6kVEw-y for ; Wed, 17 Apr 2013 13:58:12 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id B6FF721F86F4 for ; Wed, 17 Apr 2013 13:58:11 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 16:58:10 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 16:58:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Apr 2013 16:59:20 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt Thread-Index: Ac46HfZxV93nGr10TJWEA9O7xHBpogAhMigQAC4fSgAAFJI3gA== References: <20130415191457.GA25223@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net> From: "Sharam Hakimi" To: , , , X-OriginalArrivalTime: 17 Apr 2013 20:58:10.0176 (UTC) FILETIME=[449C3800:01CE3BAE] Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-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: Wed, 17 Apr 2013 20:58:13 -0000 I am going to through a little monkey wrench in this. I am going to suggest:=20 Measurement TEST Agent With the same definition as the Measurement Agent below and=20 Measurement Response Agent instead of Measurement Peer. Peering has specific meanings and any Measurement Test Agent can choose any Measurement Response agent to perform the required measurement. Thanks, Sharam=20 -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Wednesday, April 17, 2013 7:08 AM To: acmorton@att.com; trammell@tik.ee.ethz.ch; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt I much prefer Juergen's suggestion of Measurement Agent and Measurement Peer. Thanks! two suggestions: 1. think worth the definitions saying, "Colloquially, a Measurement Agent (/Peer) is a physical device that performs this function." 2.=20 > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. After the ; could we simply have "perhaps in concert with a Measurement Peer" Or do you have something else in mind? phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: 16 April 2013 14:28 > To: Brian Trammell; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] measurement agent terminology in draft-eardley- > lmap-terminology-00.txt >=20 > Juergen wrote: > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. >=20 > Brian wrote: > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > >=20 > This single name is closer to what I was thinking "terminologically" > last October. > There will be cases (I believe) where one MA is Instructed to perform > some measurements, but is simply a measurement peer for other > measurement sessions. >=20 > After initialization and instruction, different MAs can be > distinguished by the named roles of the measurement protocol they use > to execute the instructions. > Some MAs may only be initialized, then sit and wait to be contacted by > other MAs. >=20 > A small tweak at the end: > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. >=20 > (either MA can reject a test session, following the CAC discussion > yesterday) >=20 > Al >=20 > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Monday, April 15, 2013 5:12 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] measurement agent terminology in > > draft-eardley-lmap- terminology-00.txt > > > > Hi, Juergen, all. > > > > +1. Comments inline. > > > > On 16 Apr 2013, at 7:14, Juergen Schoenwaelder > > wrote: > > > > > Hi, > > > > > > I have an issue with the terms Measurement Agent, Remote > Measurement > > > Agent and Complete Measurement Agents as defined in the I-D. I do > > > not really see why we need all three and I am concerned that we > make > > > the most frequently needed term the most complex to write and spell > out. > > > > > > My understanding is that LMAP defines Control Protocol and a Report > > > Protocol between a Controller / Collector and - well the rather > ugly > > > term "Complete Measurement Agent". Note that these specifications > > > will have to talk a lot about this entity - which has the weirdest > > > and longest name. > > > > > > Furthermore, I see little value of the term Measurement Agent > > > because the Remote Measurement Agents and the Complete Measurement > > > Agents really do very different things from an LMAP protocol > > > perspective (The Remote Measurement Agent does not nothing, the > > > Complete Measurement Agent does all.) I also think the current > > > definition of Measurement Agent is likely misleading - instead of > > > 'performs' one should perhaps use 'is involved in'. (If I throw a > > > packet at a DNS server of an HTTP server, I consider this server to > > > be involved in the test, not to perform this test.) > > > > Agree completely. > > > > LMAP sits between the Controller and the measurement>. > > How that does measurement is _only_ in scope to the extent > > that a Controller has to know about it in order to coordinate its > > actions. I can't think of any arrangement of such components > requiring > > the Controller to manage distributed parts of a that is less > > complicated and more robust than one in which the Controller has a > > single part of the to which it delegates the distributed > arrangement. > > > > (There may be complexities of measurement device _management_ -- > > upgrading software, collecting load stats and other metadata, and so > > on -- that might be simplified by a Controller knowing about every > > subcomponent, but this is also questionably in scope.) > > > > > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > > > Best regards, > > > > Brian > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap From acmorton@att.com Wed Apr 17 14:35:45 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 5A4E721E80EA for ; Wed, 17 Apr 2013 14:35:45 -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 T3Q13Qb-NpWZ for ; Wed, 17 Apr 2013 14:35:44 -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 2237821E80E9 for ; Wed, 17 Apr 2013 14:35:44 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 077041207AF; Wed, 17 Apr 2013 17:36:12 -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 93D57E36FE; Wed, 17 Apr 2013 17:26:56 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 17 Apr 2013 17:35:43 -0400 From: "MORTON JR., ALFRED C (AL)" To: Sharam Hakimi , "philip.eardley@bt.com" , "trammell@tik.ee.ethz.ch" , "j.schoenwaelder@jacobs-university.de" Date: Wed, 17 Apr 2013 17:35:42 -0400 Thread-Topic: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-00.txt Thread-Index: AQHOO7ODlwAB1c60QUu1imcIgRskJg== Message-ID: References: <20130415191457.GA25223@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net>, <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] measurement agent terminology in draft-eardley-lmap-terminology-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: Wed, 17 Apr 2013 21:35:45 -0000 Thanks for your suggestion Sharam, but: =20 - we were trying to avoid using "test" at first, and now we're reserving it= for a specific type of metric with binary outcome. - the measurement "peer" might be controling certian aspects of the measure= ment according to the active measurement protocol in use, so it's better to keep names as g= eneric as possible in the LMAP space and let the supporting protocols decide the roles. anyway, there's my thoughts on the proposed names, Al ________________________________________ From: lmap-bounces@ietf.org [lmap-bounces@ietf.org] On Behalf Of Sharam Hak= imi [sharam.hakimi@exfo.com] Sent: Wednesday, April 17, 2013 4:59 PM To: philip.eardley@bt.com; MORTON JR., ALFRED C (AL); trammell@tik.ee.ethz.= ch; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardl= ey-lmap-terminology-00.txt I am going to through a little monkey wrench in this. I am going to suggest: Measurement TEST Agent With the same definition as the Measurement Agent below and Measurement Response Agent instead of Measurement Peer. Peering has specific meanings and any Measurement Test Agent can choose any Measurement Response agent to perform the required measurement. Thanks, Sharam -----Original Message----- From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: Wednesday, April 17, 2013 7:08 AM To: acmorton@att.com; trammell@tik.ee.ethz.ch; j.schoenwaelder@jacobs-university.de Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt I much prefer Juergen's suggestion of Measurement Agent and Measurement Peer. Thanks! two suggestions: 1. think worth the definitions saying, "Colloquially, a Measurement Agent (/Peer) is a physical device that performs this function." 2. > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. After the ; could we simply have "perhaps in concert with a Measurement Peer" Or do you have something else in mind? phil > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > MORTON JR., ALFRED C (AL) > Sent: 16 April 2013 14:28 > To: Brian Trammell; Juergen Schoenwaelder > Cc: lmap@ietf.org > Subject: Re: [lmap] measurement agent terminology in draft-eardley- > lmap-terminology-00.txt > > Juergen wrote: > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. > > Brian wrote: > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > > > This single name is closer to what I was thinking "terminologically" > last October. > There will be cases (I believe) where one MA is Instructed to perform > some measurements, but is simply a measurement peer for other > measurement sessions. > > After initialization and instruction, different MAs can be > distinguished by the named roles of the measurement protocol they use > to execute the instructions. > Some MAs may only be initialized, then sit and wait to be contacted by > other MAs. > > A small tweak at the end: > Measurement Agent: A function that receives Instructions from a > Controller, performs Measurement Tasks and reports Measurement > Results > to a Collector; perhaps in concert with other components > distributed > throughout the observed network, with which it coordinates as > needed. > > (either MA can reject a test session, following the CAC discussion > yesterday) > > Al > > > -----Original Message----- > > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf > > Of Brian Trammell > > Sent: Monday, April 15, 2013 5:12 PM > > To: Juergen Schoenwaelder > > Cc: lmap@ietf.org > > Subject: Re: [lmap] measurement agent terminology in > > draft-eardley-lmap- terminology-00.txt > > > > Hi, Juergen, all. > > > > +1. Comments inline. > > > > On 16 Apr 2013, at 7:14, Juergen Schoenwaelder > > wrote: > > > > > Hi, > > > > > > I have an issue with the terms Measurement Agent, Remote > Measurement > > > Agent and Complete Measurement Agents as defined in the I-D. I do > > > not really see why we need all three and I am concerned that we > make > > > the most frequently needed term the most complex to write and spell > out. > > > > > > My understanding is that LMAP defines Control Protocol and a Report > > > Protocol between a Controller / Collector and - well the rather > ugly > > > term "Complete Measurement Agent". Note that these specifications > > > will have to talk a lot about this entity - which has the weirdest > > > and longest name. > > > > > > Furthermore, I see little value of the term Measurement Agent > > > because the Remote Measurement Agents and the Complete Measurement > > > Agents really do very different things from an LMAP protocol > > > perspective (The Remote Measurement Agent does not nothing, the > > > Complete Measurement Agent does all.) I also think the current > > > definition of Measurement Agent is likely misleading - instead of > > > 'performs' one should perhaps use 'is involved in'. (If I throw a > > > packet at a DNS server of an HTTP server, I consider this server to > > > be involved in the test, not to perform this test.) > > > > Agree completely. > > > > LMAP sits between the Controller and the measurement>. > > How that does measurement is _only_ in scope to the extent > > that a Controller has to know about it in order to coordinate its > > actions. I can't think of any arrangement of such components > requiring > > the Controller to manage distributed parts of a that is less > > complicated and more robust than one in which the Controller has a > > single part of the to which it delegates the distributed > arrangement. > > > > (There may be complexities of measurement device _management_ -- > > upgrading software, collecting load stats and other metadata, and so > > on -- that might be simplified by a Controller knowing about every > > subcomponent, but this is also questionably in scope.) > > > > > > > Bottom line is that I think we simplify the terminology a lot if we > > > remove the current definition of a Measurement Agent, a Complete > > > Measurement Agent, and Remote Measurement Agent and instead use > this: > > > > > > Measurement Agent: A function that receives Instructions from a > > > Controller, performs Measurement Tasks and reports Measurement > > > Results to a Collector. > > > > > > Measurement Peer: A function that receives control messages and > > > test packets from a Measurement Agent and may reply to the > > > Measurement Agent as defined by the Measurement Method. > > > > > > Well, Measurement Peer is a new invention and not necessarily the > > > best term one could come up with. In other contexts, this has been > > > called a measurement server (I tried to avoid 'server'). The key of > > > this note, however, is to just have to two simple to understand and > > > use terms and to avoid a generalization that I do not see useful > for writing specs. > > > > Yep. As far as I'm concerned we could blend the two into one, to > > further underscore the fact that we _really don't care_ how a > > Measurement Agent performs the measurements it does: > > > > Measurement Agent: A function that receives Instructions from a > > Controller, performs Measurement Tasks and reports Measurement > Results > > to a Collector; perhaps in concert with other components > distributed > > throughout the observed network, which it itself controls. > > > > Best regards, > > > > Brian > > _______________________________________________ > > lmap mailing list > > lmap@ietf.org > > https://www.ietf.org/mailman/listinfo/lmap > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap _______________________________________________ lmap mailing list lmap@ietf.org https://www.ietf.org/mailman/listinfo/lmap= From j.schoenwaelder@jacobs-university.de Wed Apr 17 22:47: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 6935221F8F44 for ; Wed, 17 Apr 2013 22:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.113, 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 7sANOmqugnE1 for ; Wed, 17 Apr 2013 22:47:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11BE721F8F40 for ; Wed, 17 Apr 2013 22:47:26 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4A5820C0E; Thu, 18 Apr 2013 07:47:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fVaJ5oqsxJ8R; Thu, 18 Apr 2013 07:47:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C3C820C0C; Thu, 18 Apr 2013 07:47:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3CAED25B6DD2; Thu, 18 Apr 2013 07:47:24 +0200 (CEST) Date: Thu, 18 Apr 2013 07:47:24 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130418054724.GA2180@elstar.local> Mail-Followup-To: Sharam Hakimi , lmap@ietf.org References: <20130415191457.GA25223@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net> <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt 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, 18 Apr 2013 05:47:27 -0000 On Wed, Apr 17, 2013 at 04:59:20PM -0400, Sharam Hakimi wrote: > I am going to through a little monkey wrench in this. I am going to > suggest: > > Measurement TEST Agent With the same definition as the Measurement > Agent below and > > Measurement Response Agent instead of Measurement Peer. Peering has > specific meanings and any Measurement Test Agent can choose any > Measurement Response agent to perform the required measurement. > I do not see that Measurement Peer can be confused with Peering. The noun peer is already heavily used in contexts that have nothing to do with peering (e.g. Peer-to-Peer networks). I also do not see that TEST adds anything relevant to Measurement Agent. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Thu Apr 18 00:48:20 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 3A9C621F89A5 for ; Thu, 18 Apr 2013 00:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 W+MgLyFxJEW2 for ; Thu, 18 Apr 2013 00:48:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96F21F8673 for ; Thu, 18 Apr 2013 00:48:19 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 18 Apr 2013 08:48:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 18 Apr 2013 08:48:17 +0100 From: To: , Date: Thu, 18 Apr 2013 08:48:16 +0100 Thread-Topic: [lmap] Measurement Cycle term for draft-eardley-lmap-terminology-00.txt Thread-Index: Ac454OspKsZ4tnNZRnq+Y2gnt0iSXgCJcIQQ Message-ID: <9510D26531EF184D9017DF24659BB87F34565F9848@EMV65-UKRD.domain1.systemhost.net> References: <20130415135536.GA23933@elstar.local> In-Reply-To: <20130415135536.GA23933@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: lmap@ietf.org Subject: Re: [lmap] Measurement Cycle term for draft-eardley-lmap-terminology-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: Thu, 18 Apr 2013 07:48:20 -0000 I quite like Measurement Cycle. Seems it could be a useful approach > > > Measurement Cycle: A collection of Measurement Results collected > > > for over a given time period and/or for a specific purpose, > > > typically with a consistent set of measurement parameters and a > > > consistent Measurement Schedule. Is it best to define Measurement Cycle as - a set of Measurement Tasks (which are expected to produce comparable resu= lts, most likely because they all use the same Measurement Method with the = same parameters) - a collection of Measurement Results produced by those Tasks - a tag, which is attached to all those Results inside the Report (the tag = earlier being set in an Instruction) I attempted to include a bit of all 3... Measurement Cycle: A collection of Measurement Tasks that are expected to p= roduce comparable Measurement Results, which are all tagged with the same "= cycle identifier" in Report(s). Typically the Measurement Tasks all operate= the same Measurement Method with the same values for its parameters. > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: 15 April 2013 14:56 > To: MORTON JR., ALFRED C (AL) > Cc: lmap@ietf.org > Subject: Re: [lmap] Measurement Cycle term for draft-eardley-lmap- > terminology-00.txt >=20 > On Mon, Apr 15, 2013 at 09:27:47AM -0400, MORTON JR., ALFRED C (AL) > wrote: > > Hi Juergen, > > > > Thanks for your comments on the Terminology draft. > > One clarification I'd like to ask (changing subject line): > > > > you wrote: > > > l) We found it very useful to talk about something we call a > > > Measurement Cycle. > > > > > > Measurement Cycle: A collection of Measurement Results collected > > > for over a given time period and/or for a specific purpose, > > > typically with a consistent set of measurement parameters and a > > > consistent Measurement Schedule. > > > > > > We found it very helpful to have data tagged with a Measurement > > > Cycle identifier when it is received by the collector. This > allows > > > to filter out data easily during data analysis without having to > > > track when an updated was actually pushed to an MA. > > > > (in the last line above, what was updated? the definition of the > > Cycle?) > > > > It seems that the Measurement Cycle refers only to a set of Results > > which are the product of an Instruction (as we've currently defined > it): > > > > Instruction: The description of Measurement Tasks to perform and > the > > details of the Report to send; a specific instance of the Data > Model. > > The Instruction is sent by a Controller to a Complete-MA. > > > > So, if there was a unique identifier for each Instruction, and all > MAs > > operating that Instruction tagged their results with that same > > identifier when reporting to the Collector, would it satisfy the goal > > for a Measurement Cycle identifier? > > > > Alternatively, we could re-name the term Instruction as Measurement > > Cycle, if that's more descriptive. >=20 > I think Instruction is a good term, I would not rename it. The way we > use a Measurement Cycle it is really a tag carried with an Instruction > to a device. Now, if a device restarts and looses context, it will get > a new Instruction to reinstall the state driving the measurements - > however as long as we are in the same measurement cycle, this new > Instruction will carry the same tag. There might also be Instruction > within the same Measurement Cycle that reschedule measurements without > really affecting the measurement itself (e.g. you move tests forward or > backward in the schedule to make room for other measurements). > Hence, I think a Measurement Cycle has not a 1:1 relationship to an > Instruction but is really a tag carried in an Instruction and echoed > back to the Collector. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From j.schoenwaelder@jacobs-university.de Thu Apr 18 00:51: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 7CBC721F8F5C for ; Thu, 18 Apr 2013 00:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=0.082, 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 UWGud5NdkBWl for ; Thu, 18 Apr 2013 00:51:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 155FC21F8F63 for ; Thu, 18 Apr 2013 00:50:48 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79CB820C07; Thu, 18 Apr 2013 09:50:47 +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 fSsfasggnjnR; Thu, 18 Apr 2013 09:50:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B17220C06; Thu, 18 Apr 2013 09:50:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1141525B77DA; Thu, 18 Apr 2013 09:50:45 +0200 (CEST) Date: Thu, 18 Apr 2013 09:50:45 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130418075044.GC2591@elstar.local> Mail-Followup-To: philip.eardley@bt.com, acmorton@att.com, lmap@ietf.org References: <20130415135536.GA23933@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9848@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F9848@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: acmorton@att.com, lmap@ietf.org Subject: Re: [lmap] Measurement Cycle term for draft-eardley-lmap-terminology-00.txt 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, 18 Apr 2013 07:51:05 -0000 On Thu, Apr 18, 2013 at 08:48:16AM +0100, philip.eardley@bt.com wrote: > I quite like Measurement Cycle. Seems it could be a useful approach > > > > > Measurement Cycle: A collection of Measurement Results collected > > > > for over a given time period and/or for a specific purpose, > > > > typically with a consistent set of measurement parameters and a > > > > consistent Measurement Schedule. > > Is it best to define Measurement Cycle as > - a set of Measurement Tasks (which are expected to produce comparable results, most likely because they all use the same Measurement Method with the same parameters) > - a collection of Measurement Results produced by those Tasks > - a tag, which is attached to all those Results inside the Report (the tag earlier being set in an Instruction) > > I attempted to include a bit of all 3... > > Measurement Cycle: A collection of Measurement Tasks that are expected to produce comparable Measurement Results, which are all tagged with the same "cycle identifier" in Report(s). Typically the Measurement Tasks all operate the same Measurement Method with the same values for its parameters. > Works for me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Thu Apr 18 01:29: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 975B021F8E3C for ; Thu, 18 Apr 2013 01:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 wMaYA9jNMlLp for ; Thu, 18 Apr 2013 01:29:29 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6B221F8E06 for ; Thu, 18 Apr 2013 01:29:29 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Apr 2013 09:29:28 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 18 Apr 2013 09:29:28 +0100 From: To: , Date: Thu, 18 Apr 2013 09:29:27 +0100 Thread-Topic: [lmap] comments on draft-eardley-lmap-terminology-00.txt Thread-Index: Ac45zuvh/e4F+CySR+KOlboZPKC7cACOjquQ Message-ID: <9510D26531EF184D9017DF24659BB87F34565F98C5@EMV65-UKRD.domain1.systemhost.net> References: <20130415114651.GA23837@elstar.local> In-Reply-To: <20130415114651.GA23837@elstar.local> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lmap] comments on draft-eardley-lmap-terminology-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: Thu, 18 Apr 2013 08:29:30 -0000 Thanks Juergen, very useful improvements. I basically agree with them all > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: 15 April 2013 12:47 > To: lmap@ietf.org > Subject: [lmap] comments on draft-eardley-lmap-terminology-00.txt ... >=20 > c) End of section 2: You seem to put JSON and YANG into the same bin > but I think they are not. YANG is traditionally used to describe > the structure of data that is serialized in XML. (There is also > some work to also serialize YANG specified data into JSON.) In > other words, YANG is a data modeling language, JSON is an encoding > format and so you would need to talk about a JSON schema language > here. So where S2 says <> How should do you suggest this is re-phrased? [I suppose just deleting "JSO= N or" is one answer] >=20 > d) Definition of Active Measurement Method: should we not replace > "two" with "at least two"? Section 4 has already some examples > why more than two MAs may be involved in an Active Measurement > Task. Assuming we change to Measurement Agent and Measurement Peer, this needs so= me re-phrasing anyway. Not sure whether we should take account of possibly more than two Measureme= nt being involved - at least I don't yet understand how this wou= ld really work (would the generator of cross-traffic just be at the MA?) - = so am inclined to modify later. Also, am I right in thinking that an Active Measurement Method (Task) alway= s involves a Measurement Agent and a Measurement Peer?=20 (ie it never involves two Measurement Agents; ie for a particular Task, the= same entity always gets the Instruction and sends the Report.) >=20 > e) Does it make sense to introduce abbreviations for at least some of > the terms? This way, we could write MA in emails like this and be > sure everybody reads that as Measurement Agent. "MA" is in the terminology.=20 Think other abbreviations should be introduced later, when the terms have e= mbedded in our brains. Otherwise too much potential for confusion! >=20 =20 > Finally, should we also define the terms Measurement Parameters and > Environmental Constraints? They are part of the Instruction according > to section 2 but not covered by the terms defined. Prefer to add terms as we're sure we need them. Suggest that we see how the= Information Models progress - will probably then become clearer which term= s are needed (I guess it quite likely that something like Task Parameters w= ill be useful - not sure about environmental constraints) Thanks Phil Ps separate emails about measurement cycle and bootstrap protocol From philip.eardley@bt.com Thu Apr 18 01:35:56 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 AA94121F8F0E for ; Thu, 18 Apr 2013 01:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DuPBfUoXW3Ic for ; Thu, 18 Apr 2013 01:35:56 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id DB73321F8F0C for ; Thu, 18 Apr 2013 01:35:55 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 18 Apr 2013 09:35:55 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 18 Apr 2013 09:35:54 +0100 From: To: , Date: Thu, 18 Apr 2013 09:35:53 +0100 Thread-Topic: Bootstrap protocol (was RE: [lmap] comments on draft-eardley-lmap-terminology-00.txt) Thread-Index: Ac48DvIw4Y2E1cmYQLe0O3BY2vqlsw== Message-ID: <9510D26531EF184D9017DF24659BB87F34565F98D6@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lmap] Bootstrap protocol (was RE: comments on draft-eardley-lmap-terminology-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: Thu, 18 Apr 2013 08:35:56 -0000 >=20 > k) I think the last paragraph in section 4 should not be there. In > fact, I likely won't agree to it as it goes far beyond talking > about terminology. So I propose to remove this paragraph and > instead to define the term Bootstrap Protocol, e.g. like this: >=20 > Bootstrap Protocol: A protocol that initializes a Complete-MA > with the information necessary to talk to a Controller. >=20 > If you want to keep text in section 4, you may mention that there > might be different bootstrap protocols and that organizations other > than the IETF might design their own bootstrap protocols (e.g., BBF > based on TR-069). >=20 Should standardising a Bootstrap Protocol be outside lmap wg's initial scop= e? I tend to think it should be outside. For many types of device, as you say = there'll be other organisations that define their own bootstrap protocols.= =20 There may well be some types of device that need the ietf to define a boots= trap protocol, but I think that can be a phase 2 activity, so that in the i= nitial work we concentrate on things that are required for all devices. Ps your definition of Bootstrap Protocol works for me. Thanks phil=20 From j.schoenwaelder@jacobs-university.de Thu Apr 18 02:05: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 C577321F8E7E for ; Thu, 18 Apr 2013 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 5sVKSklBla35 for ; Thu, 18 Apr 2013 02:05:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EB70921F8E4C for ; Thu, 18 Apr 2013 02:05:15 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 286DE20C04; Thu, 18 Apr 2013 11:05:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5mAawdARIt9l; Thu, 18 Apr 2013 11:05:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B95E820BFE; Thu, 18 Apr 2013 11:05:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74E7D25B7DE7; Thu, 18 Apr 2013 11:05:12 +0200 (CEST) Date: Thu, 18 Apr 2013 11:05:12 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130418090508.GC2821@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <9510D26531EF184D9017DF24659BB87F34565F98D6@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F98D6@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] Bootstrap protocol (was RE: comments on draft-eardley-lmap-terminology-00.txt) 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, 18 Apr 2013 09:05:17 -0000 On Thu, Apr 18, 2013 at 09:35:53AM +0100, philip.eardley@bt.com wrote: > > > > k) I think the last paragraph in section 4 should not be there. In > > fact, I likely won't agree to it as it goes far beyond talking > > about terminology. So I propose to remove this paragraph and > > instead to define the term Bootstrap Protocol, e.g. like this: > > > > Bootstrap Protocol: A protocol that initializes a Complete-MA > > with the information necessary to talk to a Controller. > > > > If you want to keep text in section 4, you may mention that there > > might be different bootstrap protocols and that organizations other > > than the IETF might design their own bootstrap protocols (e.g., BBF > > based on TR-069). > > Should standardising a Bootstrap Protocol be outside lmap wg's initial scope? > I tend to think it should be outside. For many types of device, as you say there'll be other organisations that define their own bootstrap protocols. > There may well be some types of device that need the ietf to define a bootstrap protocol, but I think that can be a phase 2 activity, so that in the initial work we concentrate on things that are required for all devices. I assume there will be multiple different Bootstrap Protocols since they tend to be specific to certain deployments. As such, I am fine to leave Bootstrap Protocols out of the first phase of LMAP. However, LMAP should clearly define in the first phase what a Bootstrap Protocols needs to deliver for LMAP to work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From acmorton@att.com Thu Apr 18 04:37: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 E70CA21F8ECC for ; Thu, 18 Apr 2013 04:37:53 -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 p0mqCVKiRnRT for ; Thu, 18 Apr 2013 04:37:53 -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 4F72C21F8ECB for ; Thu, 18 Apr 2013 04:37: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 195D91208D6; Thu, 18 Apr 2013 07:38:22 -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 47C93E3724; Thu, 18 Apr 2013 07:29:04 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 18 Apr 2013 07:37:52 -0400 From: "MORTON JR., ALFRED C (AL)" To: Juergen Schoenwaelder , "philip.eardley@bt.com" Date: Thu, 18 Apr 2013 07:37:51 -0400 Thread-Topic: [lmap] Bootstrap protocol (was RE: comments on draft-eardley-lmap-terminology-00.txt) Thread-Index: Ac48E+IqzEQoPT0mQVOKH6pbvQlcbAAE8c/A Message-ID: References: <9510D26531EF184D9017DF24659BB87F34565F98D6@EMV65-UKRD.domain1.systemhost.net> <20130418090508.GC2821@elstar.local> In-Reply-To: <20130418090508.GC2821@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lmap@ietf.org" Subject: Re: [lmap] Bootstrap protocol (was RE: comments on draft-eardley-lmap-terminology-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: Thu, 18 Apr 2013 11:37:54 -0000 reply at the bottom... > -----Original Message----- > From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of > Juergen Schoenwaelder > Sent: Thursday, April 18, 2013 5:05 AM > To: philip.eardley@bt.com > Cc: lmap@ietf.org > Subject: Re: [lmap] Bootstrap protocol (was RE: comments on draft-eardley= - > lmap-terminology-00.txt) >=20 > On Thu, Apr 18, 2013 at 09:35:53AM +0100, philip.eardley@bt.com wrote: > > > > > > k) I think the last paragraph in section 4 should not be there. In > > > fact, I likely won't agree to it as it goes far beyond talking > > > about terminology. So I propose to remove this paragraph and > > > instead to define the term Bootstrap Protocol, e.g. like this: > > > > > > Bootstrap Protocol: A protocol that initializes a Complete-MA > > > with the information necessary to talk to a Controller. > > > > > > If you want to keep text in section 4, you may mention that there > > > might be different bootstrap protocols and that organizations othe= r > > > than the IETF might design their own bootstrap protocols (e.g., BB= F > > > based on TR-069). > > > > Should standardising a Bootstrap Protocol be outside lmap wg's initial > scope? > > I tend to think it should be outside. For many types of device, as you > say there'll be other organisations that define their own bootstrap > protocols. > > There may well be some types of device that need the ietf to define a > bootstrap protocol, but I think that can be a phase 2 activity, so that i= n > the initial work we concentrate on things that are required for all > devices. >=20 > I assume there will be multiple different Bootstrap Protocols since > they tend to be specific to certain deployments. As such, I am fine to > leave Bootstrap Protocols out of the first phase of LMAP. However, > LMAP should clearly define in the first phase what a Bootstrap > Protocols needs to deliver for LMAP to work. >=20 > /js >=20 Perhaps we could define the more generic "Bootstrap Process" and identify the information other LMAP protocols need (as Juergen said).=20 This could be loaded at manufacture, updated locally via USB port,=20 or orchestrated via a protocol in some cases, so it need not always be a protocol (as we define protocol here in IETF).=20 This way, we can recognize the process and put the exact definition of one or more protocols aside, too. Al From sharam.hakimi@exfo.com Thu Apr 18 06:10:10 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 8B44B21F8E97 for ; Thu, 18 Apr 2013 06:10:10 -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 i+aXGX3Yp1a4 for ; Thu, 18 Apr 2013 06:10:09 -0700 (PDT) Received: from smtpinqc.exfo.com (smtpinqc.exfo.com [206.162.164.97]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6F21F8E94 for ; Thu, 18 Apr 2013 06:10:09 -0700 (PDT) Received: from spqcexc04.exfo.com ([172.16.48.171]) by smtpinqc.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Apr 2013 09:10:08 -0400 Received: from spboexc01.exfo.com ([10.10.10.16]) by spqcexc04.exfo.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Apr 2013 09:10:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Apr 2013 09:11:20 -0400 Message-ID: <084CDC75FEC1E640B60338273BEACDFA0249F172@spboexc01.exfo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt Thread-Index: Ac47+ljVHvcyZGCvQ7eX46J8QjXezgAOb+yw References: <20130415191457.GA25223@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net> <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> <20130418054724.GA2180@elstar.local> From: "Sharam Hakimi" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 18 Apr 2013 13:10:08.0230 (UTC) FILETIME=[0CE11060:01CE3C36] Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-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: Thu, 18 Apr 2013 13:10:10 -0000 The point would be that a Measurement Agent can comprise of a "Test" and/or a "Response" Agent. As mentioned here before a responder is called a server in many other areas. =20 The TEST agent would be the test initiator and test data collector for the specific measurement and the RESPONDER would be the equivalent of a server. This way there is no confusion as to who initiates the measurement and who is the Responder for that measurement. That was my thought. Sharam =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, April 18, 2013 1:47 AM To: Sharam Hakimi Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt On Wed, Apr 17, 2013 at 04:59:20PM -0400, Sharam Hakimi wrote: > I am going to through a little monkey wrench in this. I am going to > suggest:=20 >=20 > Measurement TEST Agent With the same definition as the Measurement > Agent below and=20 >=20 > Measurement Response Agent instead of Measurement Peer. Peering has > specific meanings and any Measurement Test Agent can choose any > Measurement Response agent to perform the required measurement. >=20 I do not see that Measurement Peer can be confused with Peering. The noun peer is already heavily used in contexts that have nothing to do with peering (e.g. Peer-to-Peer networks). I also do not see that TEST adds anything relevant to Measurement Agent. /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 Apr 18 07:31:57 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 5765621F8F6F for ; Thu, 18 Apr 2013 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 pPI5ERUMvEG2 for ; Thu, 18 Apr 2013 07:31:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F021F8F2E for ; Thu, 18 Apr 2013 07:31:56 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05CD920BF6; Thu, 18 Apr 2013 16:31:56 +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 MX7gSQWYxxi6; Thu, 18 Apr 2013 16:31:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9109E20BE5; Thu, 18 Apr 2013 16:31:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 32EE925B9311; Thu, 18 Apr 2013 16:31:53 +0200 (CEST) Date: Thu, 18 Apr 2013 16:31:52 +0200 From: Juergen Schoenwaelder To: Sharam Hakimi Message-ID: <20130418143149.GE3925@elstar.local> Mail-Followup-To: Sharam Hakimi , lmap@ietf.org References: <20130415191457.GA25223@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F9410@EMV65-UKRD.domain1.systemhost.net> <084CDC75FEC1E640B60338273BEACDFA0249F123@spboexc01.exfo.com> <20130418054724.GA2180@elstar.local> <084CDC75FEC1E640B60338273BEACDFA0249F172@spboexc01.exfo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <084CDC75FEC1E640B60338273BEACDFA0249F172@spboexc01.exfo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] measurement agentterminology in draft-eardley-lmap-terminology-00.txt 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, 18 Apr 2013 14:31:57 -0000 On Thu, Apr 18, 2013 at 09:11:20AM -0400, Sharam Hakimi wrote: > The point would be that a Measurement Agent can comprise of a "Test" > and/or a "Response" Agent. As mentioned here before a responder is > called a server in many other areas. > > The TEST agent would be the test initiator and test data collector for > the specific measurement and the RESPONDER would be the equivalent of a > server. > > This way there is no confusion as to who initiates the measurement and > who is the Responder for that measurement. But that assumption may not necessarily always true. The MA might engage in other protocols with peer(s) such as OWAMP or TWAMP. And by the very definition, the MA is the one that interacts with the Controller and Collector, the MP does not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Apr 18 07:37: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 4384F21F8FAA for ; Thu, 18 Apr 2013 07:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 nOb1HxBFHE9a for ; Thu, 18 Apr 2013 07:37:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1D21F8F62 for ; Thu, 18 Apr 2013 07:37:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEE9720BE5; Thu, 18 Apr 2013 16:37:10 +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 AMS5sb8UWc9F; Thu, 18 Apr 2013 16:37:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D38F20BF6; Thu, 18 Apr 2013 16:37:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0C3DF25B946A; Thu, 18 Apr 2013 16:37:07 +0200 (CEST) Date: Thu, 18 Apr 2013 16:37:06 +0200 From: Juergen Schoenwaelder To: "MORTON JR., ALFRED C (AL)" Message-ID: <20130418143705.GG3925@elstar.local> Mail-Followup-To: "MORTON JR., ALFRED C (AL)" , "philip.eardley@bt.com" , "lmap@ietf.org" References: <9510D26531EF184D9017DF24659BB87F34565F98D6@EMV65-UKRD.domain1.systemhost.net> <20130418090508.GC2821@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "philip.eardley@bt.com" , "lmap@ietf.org" Subject: Re: [lmap] Bootstrap protocol (was RE: comments on draft-eardley-lmap-terminology-00.txt) 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, 18 Apr 2013 14:37:12 -0000 On Thu, Apr 18, 2013 at 07:37:51AM -0400, MORTON JR., ALFRED C (AL) wrote: > > Perhaps we could define the more generic "Bootstrap Process" > and identify the information other LMAP protocols need (as Juergen said). > This could be loaded at manufacture, updated locally via USB port, > or orchestrated via a protocol in some cases, so it need not always > be a protocol (as we define protocol here in IETF). > > This way, we can recognize the process and put the exact definition > of one or more protocols aside, too. > Works for me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Thu Apr 18 11:38: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 85B4D21F8C98 for ; Thu, 18 Apr 2013 11:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 5WCjpPuqEQnV for ; Thu, 18 Apr 2013 11:38: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 4A0BF21F8AE8 for ; Thu, 18 Apr 2013 11:38:46 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8604C20C10; Thu, 18 Apr 2013 20:38:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TpCegUKlBtnE; Thu, 18 Apr 2013 20:38:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 050A220C0C; Thu, 18 Apr 2013 20:38:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E07ED25BA1CB; Thu, 18 Apr 2013 20:38:44 +0200 (CEST) Date: Thu, 18 Apr 2013 20:38:44 +0200 From: Juergen Schoenwaelder To: philip.eardley@bt.com Message-ID: <20130418183844.GC4997@elstar.local> Mail-Followup-To: philip.eardley@bt.com, lmap@ietf.org References: <20130415114651.GA23837@elstar.local> <9510D26531EF184D9017DF24659BB87F34565F98C5@EMV65-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F34565F98C5@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: lmap@ietf.org Subject: Re: [lmap] comments on draft-eardley-lmap-terminology-00.txt 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, 18 Apr 2013 18:38:47 -0000 On Thu, Apr 18, 2013 at 09:29:27AM +0100, philip.eardley@bt.com wrote: > > > > c) End of section 2: You seem to put JSON and YANG into the same bin > > but I think they are not. YANG is traditionally used to describe > > the structure of data that is serialized in XML. (There is also > > some work to also serialize YANG specified data into JSON.) In > > other words, YANG is a data modeling language, JSON is an encoding > > format and so you would need to talk about a JSON schema language > > here. > > So where S2 says <> > > How should do you suggest this is re-phrased? [I suppose just deleting "JSON or" is one answer] Several options are possible: ... in a particular data modeling language such as YANG ... in a particular data modeling language such as a JSON schema language or YANG ... in a particular data modeling language. > > > > d) Definition of Active Measurement Method: should we not replace > > "two" with "at least two"? Section 4 has already some examples > > why more than two MAs may be involved in an Active Measurement > > Task. > > Assuming we change to Measurement Agent and Measurement Peer, this > needs some re-phrasing anyway. Not sure whether we should take > account of possibly more than two Measurement being > involved - at least I don't yet understand how this would really > work (would the generator of cross-traffic just be at the MA?) - so > am inclined to modify later. As long as there is not a strong reason why a MA can not talk to multiple MPs, I would allow this. Consider an MA that sends out a multicast and has multiple MPs echo results back. How do I look at an MA that does a traceroute? Are all the routers on the path sending ICMP packets acting as MPs in this case? I would prefer to keep the definition flexible - narrowing it down is easy, widening it later on may be much harder. > Also, am I right in thinking that an Active Measurement Method > (Task) always involves a Measurement Agent and a Measurement Peer? > (ie it never involves two Measurement Agents; ie for a particular > Task, the same entity always gets the Instruction and sends the > Report.) This is a tough one. Making this assumption clearly simplifies things a lot. > > e) Does it make sense to introduce abbreviations for at least some of > > the terms? This way, we could write MA in emails like this and be > > sure everybody reads that as Measurement Agent. > > "MA" is in the terminology. > Think other abbreviations should be introduced later, when the terms > have embedded in our brains. Otherwise too much potential for > confusion! Oops, started to use MP above - sorry for that. ;-) > > Finally, should we also define the terms Measurement Parameters and > > Environmental Constraints? They are part of the Instruction according > > to section 2 but not covered by the terms defined. > > Prefer to add terms as we're sure we need them. Suggest that we see > how the Information Models progress - will probably then become > clearer which terms are needed (I guess it quite likely that > something like Task Parameters will be useful - not sure about > environmental constraints) I am almost 100% sure we need Measurement Task Parameters and somewhat confident about Environmental Constraints. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From philip.eardley@bt.com Fri Apr 19 03:29: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 D49FB21F8ED5 for ; Fri, 19 Apr 2013 03:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 h0yIBcdVUUol for ; Fri, 19 Apr 2013 03:29:43 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 04DAB21F8EB2 for ; Fri, 19 Apr 2013 03:29:43 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 19 Apr 2013 11:29:41 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.216]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 19 Apr 2013 11:29:41 +0100 From: To: , , Date: Fri, 19 Apr 2013 11:29:40 +0100 Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgIAABJkAgAAR2ACAAALOgIAABHEA//+tAECAAFp2gIAAVfKA//+uO8CAA+8ncA== Message-ID: <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, bs7652@att.com, lmap@ietf.org Subject: Re: [lmap] LMAP: situation: Q1-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: Fri, 19 Apr 2013 10:29:44 -0000 Since Benoit probably won't read all 44 emails in this thread, I tried to d= raft an answer to his original question. Is it a fair summary of the consensus? > Question 1. Use cases > Do we agree that we want to focus on the Internet Service Provider and > the End User Network Diagnostics use cases for now? As a phase 2, we > could focus on the 3rd party use case: multi-provider, regulator, over > the top > Question: in the End User Network Diagnostics use case, I'm unclear if > the user initiated measurement is included? Here's a proposed answer:- In order to simplify the security and policy considerations, we propose tha= t LMAP phase 1 should make the assumption that the measurement system is un= der the control of a single organisation. 'Measurement system' refers to th= e Measurement Agent, Controller and Collector. There is likely to be intere= st in LMAP phase 2 in scenarios where the measurement system is not under t= he control of a single organisation. Note that the Measurement Peer may be under another organisation's control = (for example, the Measurement Peer might be in example.com, with the Measur= ement Task to download example.com's homepage or to send a request to its D= NS server). However, this doesn't affect LMAP's 'single organisation' assum= ption since the job of defining Measurement Tasks is left to IPPM. =09 So in terms of Benoit's questions: - The Internet Service Provider use case is in scope, assuming that the ISP= controls the functions for the Measurement Agent, Controller and Collector - The regulator use case is in scope, assuming that the regulator controls = the functions for the Measurement Agent, Controller and Collector - The End User Network Diagnostics use case is not directly in scope. Howev= er, the end user can get its MA to run Measurement Tasks if it wants and re= port results to whoever it wants; LMAP doesn't try to stop this happening. On separate topics (but should be mentioned somewhere in reply to Benoit) Discussion has revealed one new capability that may be required. Before a M= easurement Task actually runs, the Measurement Agent may need to check that= the Peer can carry out the Task. If one considers this as an initial stage= of the Task, then it would be something for IPPM to define. We have also discussed about the bootstrapping of a Measurement Agent (for = example, about what Controller to contact). Here the consensus is to define= the process but not a protocol. Because bootstrapping could be done in dif= ferent ways, depending on the device and the measurement system, for instan= ce: loaded at manufacture, updated locally via USB port, or orchestrated vi= a a protocol. From Michael.K.Bugenhagen@centurylink.com Fri Apr 19 05:36:22 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 462B021F95B4 for ; Fri, 19 Apr 2013 05:36:22 -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 W7j7aP5OQyOH for ; Fri, 19 Apr 2013 05:36:21 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 994FD21F941F for ; Fri, 19 Apr 2013 05:36:21 -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 r3JCaDGt003147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 07:36:13 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 2869F1E0049; Fri, 19 Apr 2013 06:36:08 -0600 (MDT) Received: from sudnp797.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 0BA711E0035; Fri, 19 Apr 2013 06:36:08 -0600 (MDT) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3JCa70G019831; Fri, 19 Apr 2013 06:36:07 -0600 (MDT) Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.qintra.com [151.117.206.27]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r3JCa72d019828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 06:36:07 -0600 (MDT) 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; Fri, 19 Apr 2013 07:36:07 -0500 From: "Bugenhagen, Michael K" To: "'philip.eardley@bt.com'" , "jason.weil@twcable.com" , "shane@castlepoint.net" Thread-Topic: [lmap] LMAP: situation: Q1-Use Cases Thread-Index: AQHOOgmit4FWJELoV06Ixy2FBlqnHZjXv1XggAC9zoCAAJ7AgIAABJkAgAAR2ACAAALOgIAABHEA//+tAECAAFp2gIAAVfKA//+uO8CAA+8ncIAAS8xg Date: Fri, 19 Apr 2013 12:36:06 +0000 Message-ID: References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> 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 Cc: "trevor.burbridge@bt.com" , "j.schoenwaelder@jacobs-university.de" , "bs7652@att.com" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q1-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: Fri, 19 Apr 2013 12:36:22 -0000 Phil,=20 Thanks! That's a nice summation IMO. The added points of "MA registration," and MA to MA capability resolution i= s also critical. Regards, Mike -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Friday, April 19, 2013 5:30 AM To: Bugenhagen, Michael K; jason.weil@twcable.com; shane@castlepoint.net Cc: trevor.burbridge@bt.com; j.schoenwaelder@jacobs-university.de; bs7652@a= tt.com; lmap@ietf.org Subject: RE: [lmap] LMAP: situation: Q1-Use Cases Since Benoit probably won't read all 44 emails in this thread, I tried to d= raft an answer to his original question. Is it a fair summary of the consensus? > Question 1. Use cases > Do we agree that we want to focus on the Internet Service Provider and=20 > the End User Network Diagnostics use cases for now? As a phase 2, we=20 > could focus on the 3rd party use case: multi-provider, regulator, over=20 > the top > Question: in the End User Network Diagnostics use case, I'm unclear if=20 > the user initiated measurement is included? Here's a proposed answer:- In order to simplify the security and policy considerations, we propose tha= t LMAP phase 1 should make the assumption that the measurement system is un= der the control of a single organisation. 'Measurement system' refers to th= e Measurement Agent, Controller and Collector. There is likely to be intere= st in LMAP phase 2 in scenarios where the measurement system is not under t= he control of a single organisation. Note that the Measurement Peer may be under another organisation's control = (for example, the Measurement Peer might be in example.com, with the Measur= ement Task to download example.com's homepage or to send a request to its D= NS server). However, this doesn't affect LMAP's 'single organisation' assum= ption since the job of defining Measurement Tasks is left to IPPM. =09 So in terms of Benoit's questions: - The Internet Service Provider use case is in scope, assuming that the ISP= controls the functions for the Measurement Agent, Controller and Collector - The regulator use case is in scope, assuming that the regulator controls = the functions for the Measurement Agent, Controller and Collector - The End User Network Diagnostics use case is not directly in scope. Howev= er, the end user can get its MA to run Measurement Tasks if it wants and re= port results to whoever it wants; LMAP doesn't try to stop this happening. On separate topics (but should be mentioned somewhere in reply to Benoit) Discussion has revealed one new capability that may be required. Before a M= easurement Task actually runs, the Measurement Agent may need to check that= the Peer can carry out the Task. If one considers this as an initial stage= of the Task, then it would be something for IPPM to define. We have also discussed about the bootstrapping of a Measurement Agent (for = example, about what Controller to contact). Here the consensus is to define= the process but not a protocol. Because bootstrapping could be done in dif= ferent ways, depending on the device and the measurement system, for instan= ce: loaded at manufacture, updated locally via USB port, or orchestrated vi= a a protocol. From bclaise@cisco.com Fri Apr 19 07:53: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 91EE121F8F9D for ; Fri, 19 Apr 2013 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 jApQZKXEDVax for ; Fri, 19 Apr 2013 07:53:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4FB21F8F6E for ; Fri, 19 Apr 2013 07:53:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JErNlI013702; Fri, 19 Apr 2013 16:53:23 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JEqgdW011174; Fri, 19 Apr 2013 16:52:52 +0200 (CEST) Message-ID: <51715A39.4070002@cisco.com> Date: Fri, 19 Apr 2013 16:52:41 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: philip.eardley@bt.com, acmorton@att.com, trammell@tik.ee.ethz.ch, bs7652@att.com, lmap@ietf.org References: <2D09D61DDFA73D4C884805CC7865E611302A3DB4@GAALPA1MSGUSR9L.ITServices.sbc.com> <20EEC334-35BE-4859-96C3-E80D88F58671@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3456559C92@EMV65-UKRD.domain1.systemhost.net> <20130412145922.GA15943@elstar.local> In-Reply-To: <20130412145922.GA15943@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lmap] LMAP: situation: Q2-IPv4/6 - conclusion 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, 19 Apr 2013 14:53:51 -0000 Dear all, So it seems clear from the answer that we want both IPv4 and IPv6 supports. Regards, Benoit From bclaise@cisco.com Fri Apr 19 07:57: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 2FC2C21F8FAC for ; Fri, 19 Apr 2013 07:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 R3vMP+fAvWA8 for ; Fri, 19 Apr 2013 07:57:07 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id AF07821F8FED for ; Fri, 19 Apr 2013 07:56:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JEusad014027; Fri, 19 Apr 2013 16:56:54 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JEuSBx018524; Fri, 19 Apr 2013 16:56:39 +0200 (CEST) Message-ID: <51715B1C.50000@cisco.com> Date: Fri, 19 Apr 2013 16:56:28 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "MORTON JR., ALFRED C (AL)" References: <2D09D61DDFA73D4C884805CC7865E611302A3E9F@GAALPA1MSGUSR9L.ITServices.sbc.com> <9510D26531EF184D9017DF24659BB87F3456559C94@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "philip.eardley@bt.com" , "STARK, BARBARA H" , "lmap@ietf.org" Subject: Re: [lmap] LMAP: situation: Q5-Gaming the system - conclusion 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, 19 Apr 2013 14:57:09 -0000 Dear all, From the answers, I understand that there are so many ways to game the system, that this group should not focus on technical solutions to all these problems. However, obvious (easy) cases might be in scope. For example, quoting Barbara: "If the original person had a 20Mbps service, and the friend had a 6Mbps service, then the result interpretation would show that the measurement service was performing very poorly against the 20Mpbs benchmark." Regards, Benoit From bclaise@cisco.com Fri Apr 19 07:59: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 A6DFA21F93E2 for ; Fri, 19 Apr 2013 07:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 B9+IyYOKJU0u for ; Fri, 19 Apr 2013 07:59:33 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 04D9921F93DA for ; Fri, 19 Apr 2013 07:59:32 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JExPjW014307; Fri, 19 Apr 2013 16:59:25 +0200 (CEST) Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3JEwdrW022216; Fri, 19 Apr 2013 16:58:49 +0200 (CEST) Message-ID: <51715B9F.4010706@cisco.com> Date: Fri, 19 Apr 2013 16:58:39 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Bugenhagen, Michael K" References: <2D09D61DDFA73D4C884805CC7865E611302A3DCE@GAALPA1MSGUSR9L.ITServices.sbc.com> , <1D65E908-932A-405E-85FB-9641B17FE4AE@tik.ee.ethz.ch> <9510D26531EF184D9017DF24659BB87F3456559C93@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bs7652@att.com" , "'philip.eardley@bt.com'" , "lmap@ietf.org" , "acmorton@att.com" , "trammell@tik.ee.ethz.ch" Subject: Re: [lmap] LMAP: situation: Q3-Passive/Active measurements - conclusion 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, 19 Apr 2013 14:59:33 -0000 Dear all, From the answers, it seems obvious that both active and passive measurements should be in scope. Regards, Benoit From trammell@tik.ee.ethz.ch Sun Apr 21 14:32:38 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 C682421F929E for ; Sun, 21 Apr 2013 14:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3FYN4joqJnlv for ; Sun, 21 Apr 2013 14:32:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id E24B821F9265 for ; Sun, 21 Apr 2013 14:32:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 142ACD9305; Sun, 21 Apr 2013 23:32:35 +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 eNBIGItAw7ea; Sun, 21 Apr 2013 23:32:35 +0200 (MEST) Received: from wifi-172-23-11-84.uoa-wifi.auckland.ac.nz (wireless-nat-3.auckland.ac.nz [130.216.30.114]) (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 9CD03D9304; Sun, 21 Apr 2013 23:32:32 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Trammell In-Reply-To: <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 22 Apr 2013 09:32:38 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <26EB498B-77FE-4DE5-8B83-28EE54244BD3@tik.ee.ethz.ch> References: <9F0B5658-05CE-4264-85F6-A517827FAB2E@castlepoint.net> <9510D26531EF184D9017DF24659BB87F34566A4302@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1503) Cc: lmap@ietf.org, trevor.burbridge@bt.com, j.schoenwaelder@jacobs-university.de, Michael.K.Bugenhagen@centurylink.com, jason.weil@twcable.com, shane@castlepoint.net, bs7652@att.com Subject: Re: [lmap] LMAP: situation: Q1-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: Sun, 21 Apr 2013 21:32:38 -0000 Phil, Thanks for the summation! Summary reads good to me (as an interested = lurker in this thread)... Cheers, Brian On 19 Apr 2013, at 22:29, wrote: > Since Benoit probably won't read all 44 emails in this thread, I tried = to draft an answer to his original question. > Is it a fair summary of the consensus? >=20 >> Question 1. Use cases >> Do we agree that we want to focus on the Internet Service Provider = and >> the End User Network Diagnostics use cases for now? As a phase 2, we >> could focus on the 3rd party use case: multi-provider, regulator, = over >> the top >> Question: in the End User Network Diagnostics use case, I'm unclear = if >> the user initiated measurement is included? >=20 > Here's a proposed answer:- >=20 > In order to simplify the security and policy considerations, we = propose that LMAP phase 1 should make the assumption that the = measurement system is under the control of a single organisation. = 'Measurement system' refers to the Measurement Agent, Controller and = Collector. There is likely to be interest in LMAP phase 2 in scenarios = where the measurement system is not under the control of a single = organisation. >=20 > Note that the Measurement Peer may be under another organisation's = control (for example, the Measurement Peer might be in example.com, with = the Measurement Task to download example.com's homepage or to send a = request to its DNS server). However, this doesn't affect LMAP's 'single = organisation' assumption since the job of defining Measurement Tasks is = left to IPPM. >=20 > =09 > So in terms of Benoit's questions: > - The Internet Service Provider use case is in scope, assuming that = the ISP controls the functions for the Measurement Agent, Controller and = Collector > - The regulator use case is in scope, assuming that the regulator = controls the functions for the Measurement Agent, Controller and = Collector > - The End User Network Diagnostics use case is not directly in scope. = However, the end user can get its MA to run Measurement Tasks if it = wants and report results to whoever it wants; LMAP doesn't try to stop = this happening. >=20 >=20 >=20 > On separate topics (but should be mentioned somewhere in reply to = Benoit) >=20 > Discussion has revealed one new capability that may be required. = Before a Measurement Task actually runs, the Measurement Agent may need = to check that the Peer can carry out the Task. If one considers this as = an initial stage of the Task, then it would be something for IPPM to = define. >=20 > We have also discussed about the bootstrapping of a Measurement Agent = (for example, about what Controller to contact). Here the consensus is = to define the process but not a protocol. Because bootstrapping could be = done in different ways, depending on the device and the measurement = system, for instance: loaded at manufacture, updated locally via USB = port, or orchestrated via a protocol. > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap From johnsonhammond1@hushmail.com Sat Apr 27 14:57: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 CD6B121F98C0 for ; Sat, 27 Apr 2013 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 Rg27Bw5JZKd3 for ; Sat, 27 Apr 2013 14:57:24 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 01A4721F983A for ; Sat, 27 Apr 2013 14:57:22 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id D1C601B533C for ; Sat, 27 Apr 2013 17:42:51 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:42:51 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 9DF69E6736; Sat, 27 Apr 2013 17:42:51 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:42:51 -0400 To: lmap@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174251.9DF69E6736@smtp.hushmail.com> Subject: [lmap] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 21:57:24 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.