Re: [lmap] Feedback on draft-eardley-lmap-terminology

"MORTON JR., ALFRED C (AL)" <acmorton@att.com> Wed, 24 July 2013 13:04 UTC

Return-Path: <acmorton@att.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 EB93511E80E6 for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 06:04:48 -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=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 wHOjNw3ycvqP for <lmap@ietfa.amsl.com>; Wed, 24 Jul 2013 06:04: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 D7D0111E8210 for <lmap@ietf.org>; Wed, 24 Jul 2013 06:04:43 -0700 (PDT)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 7CD891204FC; Wed, 24 Jul 2013 09:04:40 -0400 (EDT)
Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-green.research.att.com (Postfix) with ESMTP id 72C05E037F; Wed, 24 Jul 2013 09:04:20 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg1.research.att.com ([fe80::58ce:ca01:5d18:db01%13]) with mapi; Wed, 24 Jul 2013 09:04:42 -0400
From: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "bclaise@cisco.com" <bclaise@cisco.com>
Date: Wed, 24 Jul 2013 09:04:41 -0400
Thread-Topic: [lmap] Feedback on draft-eardley-lmap-terminology
Thread-Index: Ac6ISEypJJA759Q0QNmvxWMfGSmlewAGaYjgAAJvJNA=
Message-ID: <F1312FAF1A1E624DA0972D1C9A91379A1CA4F50061@njfpsrvexg7.research.att.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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F1312FAF1A1E624DA0972D1C9A91379A1CA4F50061njfpsrvexg7re_"
MIME-Version: 1.0
Cc: "odonoghue@isoc.org" <odonoghue@isoc.org>, "lmap@ietf.org" <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:04:49 -0000

Hi Phil and Benoit,

Even dedicated test server capacity can be overrun at large scale.

Case in point:
A manufacturer of consumer WLAN access points sold in the US
coded the IP of a single NTP server in every device, and rather
suddenly the US Naval Observatory NTP server they chose
had >10k clients they didn't plan on serving
(I've cc'd Karen O'Donoghue who may clarify or add to this story).
IIRC, this was a case where IETF guidance
(ask permission before adding someone's NTP server to your list,
and use DNS names instead of IP addresses) was ignored.

The two points above apply to LMAP, especially for tests
involving DNS servers, and we can add them to Phil's list below.

Al

From: lmap-bounces@ietf.org [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Wednesday, July 24, 2013 7:46 AM
To: bclaise@cisco.com
Cc: lmap@ietf.org
Subject: Re: [lmap] Feedback on draft-eardley-lmap-terminology

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

I agree that the measurement functionality has the potential to be abused as a DDOS attack and we need mechanisms to alleviate it.
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)

-       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)

-       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

-       Perhaps some guidance on best practice (don't kill bt.com - try cisco.com instead!!)

Thanks
phil

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