Re: [lmap] Feedback on draft-eardley-lmap-terminology
Paul Aitken <paitken@cisco.com> Wed, 24 July 2013 13:06 UTC
Return-Path: <paitken@cisco.com>
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 E0C0011E80E4 for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 06:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Level:
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAu-T1tuER6F for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 06:06:42 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id AA35011E80E0 for <lmap@ietf.org>; Wed, 24 Jul 2013 06:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28091; q=dns/txt; s=iport; t=1374671202; x=1375880802; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Rq64AY/BtTvOkh+Lz+g4kbGuko8IhSb0YobJU+js+RI=; b=jxvIhaE5Em+OxNR+vYl7s825kEFKTQ01bQC2CWO2Q6A8GMLhlL+iFkpb xRLgjdN/1OcnwIqXEA0TnpKytRf1ajj+mARhcVhMOKaD5Wv4L6ql7lnU9 SbZfNSKd0LrS4e0aJ/DbZBiUE2dwdymYCp/gdJEES1iG06+RD5Oe77Ipq w=;
X-IronPort-AV: E=Sophos; i="4.89,729,1367971200"; d="scan'208,217"; a="15932093"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 24 Jul 2013 13:06:41 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6OD6cVQ003872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 13:06:38 GMT
Received: from [144.254.153.45] (dhcp-144-254-153-45.cisco.com [144.254.153.45]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6OD6bBk013764; Wed, 24 Jul 2013 14:06:38 +0100 (BST)
Message-ID: <51EFD15E.1050804@cisco.com>
Date: Wed, 24 Jul 2013 14:06:38 +0100
From: Paul Aitken <paitken@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: philip.eardley@bt.com
References: <51ED59B3.3040701@cisco.com> <9510D26531EF184D9017DF24659BB87F35B7CD1AF5@EMV65-UKRD.domain1.systemhost.net> <51EF90E4.6000907@cisco.com> <9510D26531EF184D9017DF24659BB87F35B7CD1D59@EMV65-UKRD.domain1.systemhost.net>
In-Reply-To: <9510D26531EF184D9017DF24659BB87F35B7CD1D59@EMV65-UKRD.domain1.systemhost.net>
Content-Type: multipart/alternative; boundary="------------020808030205020907010202"
Cc: bclaise@cisco.com, lmap@ietf.org
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lmap>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 13:06:51 -0000
Phil, I've been reviewing the drafts, and these are all points I planned to raise. Inline: > Ok, this should be mentioned in the Use case doc as well as in the > framework. > > incidentally, although the measurement functionality would be in lots > of MAs I wouldn't expect them all to run all the tests at the same > time -- for the regular tests, I think you'd use a subset as a panel, > and over the course of a few weeks say the panel would rotate round > the different end hosts > What I read so far seems to focus on the singular test case, whereas in reality there may be many MAs performing the same test, even at the same time. > I agree that the measurement functionality has the potential to be > abused as a DDOS attack and we need mechanisms to alleviate it. > +1. Similar the reporting infra, if 1,000's of MAs are told to send reports to www.bt.com. > Perhaps too early for specific proposals, but I'd suggest a > combination of: > > -Security on the Control Protocol (to stop rogue controller asking MAs > to launch a DDoS) > +1. > -Some individual tests to include an initial phase where they check > that the Measurement Peer has capacity (especially for tests that > create a significant load on the Measurement Peer) > That might not be possible, eg if the test is a DNS lookup or web page retrieval, the peer may have no knowledge that it's involved in an LMAP measurement. > -Ability for Controller to send a "suppress" msg -- so lots of MAs can > be told to stop sending test pkts, if there's some problem > Also to stop sending reports. This needs to be similarly secure so a rogue controller can't suppress sections of the LMAP network. > -Perhaps some guidance on best practice (don't kill bt.com -- try > cisco.com instead!!) > :-) P. > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* 24 July 2013 09:32 > *To:* Eardley,PL,Philip,TUB8 R > *Cc:* lmap@ietf.org > *Subject:* Re: [lmap] Feedback on draft-eardley-lmap-terminology > > Phil, > > ** > > *<<*I'm not too clear if the Measurement Peer are dedicated test > server, or real server (google.com, SIP server, youtube)>> > > *The Measurement Peer could be either. It's up to the operator of the > measurement system to decide what Measurement Methods the Measurement > Peer needs and exactly how they're implemented.* > > Sure, but what if I point all my 100.000 MAs to constantly ping > http://home.bt.com/news-01363796671918. Not sure if BT will be happy. > I could take a different example with DNS, NTP, CDN, ... > That might be a point for an applicability section somewhere. > > Regards, Benoit > > ** > > Thanks > > phil > > *From:*lmap-bounces@ietf.org <mailto:lmap-bounces@ietf.org> > [mailto:lmap-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* 22 July 2013 17:12 > *To:* lmap@ietf.org <mailto:lmap@ietf.org> > *Subject:* [lmap] Feedback on draft-eardley-lmap-terminology > > Dear authors, > > A couple of high level points. > One of the goal behind this email is to generate discussions, either > on the list, or during the IETF meeting next week. > > - > > The consensus is that the LMAP working group should assume that a > Measurement Agent receives Instruction from only a single Controller > at any point in time (however it may Report to more than one > Collector). > > Instead of consensus, I would use "a key assumption" > The charter says: > > A key assumption constraining the initial work is that the measurement > system is under the control of a single organization (for example, an > Internet Service Provider or a regulator). > > - > Same remark for the term "consensus" in > > The job of a Bootstrap Protocol is to provide an automated way to > associate a Measurement Agent to its Controller, including > authentication credentials. Similarly, there should be a way to pull > the plug on rogue Measurement Agents. The current consensus on the > LMAP mailing list is that the working group should define the > bootstrap process but not a protocol. > > The charter mentions: > > "The management protocol to bootstrap the MAs in measurement devices > is out of scope of the LMAP charter." > > - > I would like to draw your attention to > claise-ippm-perf-metric-registry > <http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry>, > which will be presented in IPPM. > > - > I'm not too clear if the Measurement Peer are dedicated test server, > or real server (google.com, SIP server, youtube) > Do the Measurement Peer need the functionality of an IP SLA responder > or a TWAMP controller? > This might be clarified in the use case draft. > > - > This draft is good shape, but it's really a mix of terminology and > framework concepts. > I'm glad that there is a single delivery in the charter for both: > "1. The LMAP Framework - provides common terminology, basic > architecture elements, and justifies the simplifying constraints" > > > Regards, Benoit > > > > _______________________________________________ > lmap mailing list > lmap@ietf.org > https://www.ietf.org/mailman/listinfo/lmap
- [lmap] Feedback on draft-eardley-lmap-terminology Benoit Claise
- Re: [lmap] Feedback on draft-eardley-lmap-termino… philip.eardley
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Benoit Claise
- Re: [lmap] Feedback on draft-eardley-lmap-termino… philip.eardley
- Re: [lmap] Feedback on draft-eardley-lmap-termino… MORTON JR., ALFRED C (AL)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Paul Aitken
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Romascanu, Dan (Dan)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… MORTON JR., ALFRED C (AL)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Paul Aitken
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder
- Re: [lmap] Feedback on draft-eardley-lmap-termino… marcelo bagnulo braun
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Paul Aitken
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Paul Aitken
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Romascanu, Dan (Dan)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Romascanu, Dan (Dan)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Romascanu, Dan (Dan)
- Re: [lmap] Feedback on draft-eardley-lmap-termino… philip.eardley
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Paul Aitken
- Re: [lmap] Feedback on draft-eardley-lmap-termino… Juergen Schoenwaelder