Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

"STARK, BARBARA H" <bs7652@att.com> Thu, 05 June 2014 12:35 UTC

Return-Path: <bs7652@att.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D480A1A00BA for <lmap@ietfa.amsl.com>; Thu, 5 Jun 2014 05:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.25
X-Spam-Level:
X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPsYSy2tFEIZ for <lmap@ietfa.amsl.com>; Thu, 5 Jun 2014 05:35:17 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B201A0097 for <lmap@ietf.org>; Thu, 5 Jun 2014 05:35:16 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ef360935.2ae61ce9a940.9607309.00-2452.26441407.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Thu, 05 Jun 2014 12:35:10 +0000 (UTC)
X-MXL-Hash: 539063fe07fd8f22-b9a7f90ce81dec6df27efec5a5dc1d4cd0ae04f6
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 6f360935.0.9607183.00-2370.26440990.nbfkord-smmo06.seg.att.com (envelope-from <bs7652@att.com>); Thu, 05 Jun 2014 12:35:03 +0000 (UTC)
X-MXL-Hash: 539063f76afadac5-c33a472d562554d8356bfc62410d13bd6693a8d0
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s55CZ1Ag016533; Thu, 5 Jun 2014 08:35:02 -0400
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s55CYpj9016466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2014 08:34:57 -0400
Received: from GAALPA1MSGHUBAC.ITServices.sbc.com (GAALPA1MSGHUBAC.itservices.sbc.com [130.8.218.152]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 5 Jun 2014 12:34:40 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.142]) by GAALPA1MSGHUBAC.ITServices.sbc.com ([130.8.218.152]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 08:34:39 -0400
From: "STARK, BARBARA H" <bs7652@att.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "KEN.KO@adtran.com" <KEN.KO@adtran.com>, "gregimirsky@gmail.com" <gregimirsky@gmail.com>
Thread-Topic: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt
Thread-Index: AQHPfojkbNHfyGX67kmnH/9tHgk7xZthWtoAgAASfQCAAGr5AIAAqnaA///1EuA=
Date: Thu, 05 Jun 2014 12:34:38 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130DE6768@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <A2E337CDB7BC4145B018B9BEE8EB3E0D40F4A8D457@EMV67-UKRD.domain1.systemhost.net> <CA+RyBmW_2H+QXM-iz5=dN6Q_PnjMEnAfZ4CLnnqLHJ07H6jevQ@mail.gmail.com> <A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C415@EMV67-UKRD.domain1.systemhost.net> <CA+RyBmVHE9ijCPuvod1ihbJjJnTo47Vmz-hgAq2ysDw7W0b4Wg@mail.gmail.com>, <D14B7E40AEBFD54EA3AD964902DD7CB77756DA4D@ex-mb1.corp.adtran.com> <A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419@EMV67-UKRD.domain1.systemhost.net>
In-Reply-To: <A2E337CDB7BC4145B018B9BEE8EB3E0D40F4B6C419@EMV67-UKRD.domain1.systemhost.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.133.103]
Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61130DE6768GAALPA1MSGUSRBF_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=Kpj6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=4KGvShVWWqUA:10 a=ofMgfj31e3cA:10 a=5J7jPVQL82wA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=e9qsufxtAAAA:8 a=eJNrpioGAAAA:8 a=pGLkceISAAAA:8 a]
X-AnalysisOut: [=NmISpzTwwaaKqYbtOcgA:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:1]
X-AnalysisOut: [0 a=W1qU_X6G3J8A:10 a=DvnSUQUdWHYA:10 a=MSl-tDqOz04A:10 a=]
X-AnalysisOut: [g_6aMhtE2xKt82-O:21 a=qlHzduURJfAf4PKC:21 a=yMhMjlubAAAA:8]
X-AnalysisOut: [ a=SSmOFEACAAAA:8 a=7d2Vj_3sIuZxsLWZw4gA:9 a=gKO2Hq4RSVkA:]
X-AnalysisOut: [10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a]
X-AnalysisOut: [=y7O5xpnRk5HfBnHj:21 a=lUKifvgFQO8DIiSh:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.229.23]
Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/jKHrJyNQm2PmC0QL4HJwIczBV0k
Cc: "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Jun 2014 12:35:20 -0000

+1
Barbara

From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Thursday, June 05, 2014 5:13 AM
To: KEN.KO@adtran.com; gregimirsky@gmail.com
Cc: lmap@ietf.org
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

i think this is a very good suggestion. i agree this is the right way of separating policy and protocol

as a side benefit, we can then drop the active vs passive distinction (and terminology) (and do some slight rephrasing in the privacy section, which is the main place that uses the terms)

thanks
phil

________________________________
From: KEN KO [KEN.KO@adtran.com]
Sent: 05 June 2014 00:03
To: Greg Mirsky; Eardley,PL,Philip,TUB8 R
Cc: lmap@ietf.org<mailto:lmap@ietf.org>
Subject: RE: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt
As I read this email thread which is similar to earlier ones discussing active vs. passive, I keep thinking about the only place the distinction is being used in the lmap framework, which is for suppression. And, I keep thinking that we are creating a distinction the details of which we cannot agree on, and that different test system operators  intend to use in different ways. And this leads me to think that there is a better way to provide the agreed suppression behavior while allowing test system operators to modify it as they wish.

Default suppression behavior, as specified in framework-05:

“Suppression means that the MA does not begin any new
Active Measurement Task. The impact on other Measurement Tasks is
not defined by LMAP; since they do not involve the MA creating any
Active Measurement Traffic there is no need to suppress them, however
it may be simpler for an implementation to do so.”

We have arrived at this point because stakeholders could not agree on how to treat Passive Tasks. As a result, some operators may suppress Passive Tasks by default and others may let them continue, with variations between those two extremes. And yet, since we are still debating where to draw the line between Active and Passive, the matter is not settled.

There is a better way. Simply add a field – a Boolean true/false flag is all that is required – to the Measurement Task Configuration indicating whether that Task is to be suppressed by default. It shortcuts the Active Passive arguments (at least, in lmap) and gives operators complete freedom over default suppression behavior.

The description of a Measurement Method in a registry could contain a recommended value for the flag. However, operators would be free to use that value or override it in their deployments.

Comments?

Ken


From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Wednesday, June 04, 2014 10:40 AM
To: philip.eardley@bt.com<mailto:philip.eardley@bt.com>
Cc: lmap@ietf.org<mailto:lmap@ietf.org>
Subject: Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

Hi Phil,
thank you for your prompt response to my comments.
if I compare common interpretations of "observe" and "collect":
ob·serve verb \əb-ˈzərv\

: to watch and sometimes also listen to (someone or something) carefully

: to see and notice (someone or something)
: to make a comment about something you notice
vs.
col·lect verb \kə-ˈlekt\

: to get (things) from different places and bring them together

: to get (one or more things) from a place
: to get (similar things) and bring them together as a hobby
the latter seems as more suitable in characterization of role of MA(s) in executing Passive Measurement methods.
RE: Measurement Domain. Given earlier discussion and suggestion to take holistic approach to MA/MP role, I believe we are at the point where discussion of Measurement Domain's definition and use is timely and appropriate.
Regards,
Greg

On Wed, Jun 4, 2014 at 8:34 AM, <philip.eardley@bt.com<mailto:philip.eardley@bt.com>> wrote:


Proposal:-

In the Intro, add to the paragraph about Active & Passive Tasks:

There may also be Measurement Tasks that are intermediate between Passive and Active ones; consideration is outside the initial LMAP work scope.



In terminology, tweak the definitions:-

Passive Measurement Task: A Measurement Task in which a Measurement Agent observes existing traffic but does not inject Active Measurement Traffic.

GIM>> I think that "observes" is not the same as "collect information off". Can it be "... in which a Measurement Agent collects information off existing traffic ..."? I think that a Measurement Agent may coordinate its actions in performing Passive Measurement Task with other Measurement Agents/Peers. More on it below.

[phil] I don't really understand what difference you're getting at - what meaning do you want to convey with "collect information" that differs from "observes"?



Active Measurement Task: A Measurement Task in which a Measurement Agent sends Active Measurement Traffic to, or receives it from, one or more other Measurement Agents or Measurement Peers, and perhaps coordinates with them using protocols outside the initial LMAP work scope

GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And I'd like to discuss new Measurement Domain object defined as:

The community of Measurement Agents and Measurement Peers that cooperate in performing a Measurement Task, whether Active or Passive, present a Measurement Domain. Coordination protocol(s) used within Measurement Domain are outside of the initial LMAP work scope.
Then in definitions of Active/Passive Measurement Task in the LMAP Framework we can use the Measurement Domain like:
Passive Measurement Task: A Measurement Task in which a Measurement Agent collects information off existing traffic within its Measurement Domain.

[phil] yes, Active Measurement Traffic is what you could call test traffic ["Active Measurement Traffic: the packet(s) generated in order to execute an Active Measurement Task."]

[phil] re measurement domain - i can see this may be a useful concept, but i don't think we've needed this term yet in lmap. given how tricky agreeing terminology is, can we delay defining this term until we're sure we need it.

thanks
phil