Re: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt

"MORTON, ALFRED C (AL)" <acmorton@att.com> Fri, 30 May 2014 13:51 UTC

Return-Path: <acmorton@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 B8A171A08AB; Fri, 30 May 2014 06:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level:
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] 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 sFRJQ2FlT54F; Fri, 30 May 2014 06:51:55 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4811A090F; Fri, 30 May 2014 06:51:55 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 278E0120CBE; Fri, 30 May 2014 09:54:08 -0400 (EDT)
Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 3817FF03CB; Fri, 30 May 2014 09:51:51 -0400 (EDT)
Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 30 May 2014 09:51:51 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: 邓灵莉/Lingli Deng <denglingli@chinamobile.com>, 'Nalini Elkins' <nalini.elkins@insidethestack.com>, 'Vero Zheng' <vero.zheng@huawei.com>
Date: Fri, 30 May 2014 09:51:49 -0400
Thread-Topic: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
Thread-Index: AQHPe19m4ogsNcYgEECVMd9hDcgkN5tYIWOA//+zJkCAAD4IF4AAvPUggABJgFA=
Message-ID: <2845723087023D4CB5114223779FA9C8017992C8F1@njfpsrvexg8.research.att.com>
References: <CA+RyBmV-QbPwQAFinYvNKGJR-Jnp_roG=wAs7yAuhcObtSRuMA@mail.gmail.com> <A2E337CDB7BC4145B018B9BEE8EB3E0D40F406DE56@EMV67-UKRD.domain1.systemhost.net> <2EEA459CD95CCB4988BFAFC0F2287B5C5C8441BF@SZXEMA504-MBS.china.huawei.com> <20140529121607.GA82518@elstar.local> <1401366760.51380.YahooMailNeo@web125104.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D70E@GAALPA1MSGUSR9L.ITServices.sbc.com> <1401367762.8149.YahooMailNeo@web125105.mail.ne1.yahoo.com> <2D09D61DDFA73D4C884805CC7865E6113043D765@GAALPA1MSGUSR9L.ITServices.sbc.com> <20140529130345.M94452@mail.usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043D987@GAALPA1MSGUSR9L.ITServices.sbc.com> <D14B7E40AEBFD54EA3AD964902DD7CB77756AD0C@ex-mb1.corp.adtran.com> <20140529164842.M20408@usj.edu.lb> <2D09D61DDFA73D4C884805CC7865E6113043DA2B@GAALPA1MSGUSR9L.ITServices.sbc.com>, <D14B7E40AEBFD54EA3AD964902DD7CB77756AD3C@ex-mb1.corp.adtran.com> <2845723087023D4CB5114223779FA9C80178E0CD93@njfpsrvexg8.research.att.com> <017a01cf7bf1$644daa60$2ce8ff20$@com>
In-Reply-To: <017a01cf7bf1$644daa60$2ce8ff20$@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/lmap/-ohAaukrqfFsLU_ITsFoUhELTJc
Cc: "ippm@ietf.org" <ippm@ietf.org>, "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] [ippm] I-D Action: 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: Fri, 30 May 2014 13:51:58 -0000

Hi Lingli,

For a long time, we've had an enormous number of 
measurement system implementations
that were either purely active or purely passive.
In a real way, active and passive are at opposite
ends of a continuum**, where you have the 

- all the problems of disturbing the network conditions
- all the advantages of knowing what was sent and when

with injected traffic, what we call active metrics and measurement,
and the exact opposite situation with passive (none of 
the problems and none of the advantages).

Recently there are new techniques like Nalini and Mike's PDM
which you cite below (and I find very interesting).
I believe these techniques, and others folks have mentioned,
lie somewhere between pure active and pure passive.

It's important to me (and possibly others) to anchor our 
terminology with both common use and dictionary meaning,
so I use the term "observe" with the pure passive category.
If your technique does more than observe (and analyze, where 
you could combine observations from multiple points, etc.) 
then the technique is in-between the extremes, IMO.

regards,
Al

** we might draw this as a 2D-space, active and passive would be
at opposite corners.


> -----Original Message-----
> From: 邓灵莉/Lingli Deng [mailto:denglingli@chinamobile.com]
> Sent: Friday, May 30, 2014 6:25 AM
> To: MORTON, ALFRED C (AL); 'KEN KO'; STARK, BARBARA H; 'marc.ibrahim';
> 'Nalini Elkins'; 'Juergen Schoenwaelder'; 'Vero Zheng';
> trevor.burbridge@bt.com; philip.eardley@bt.com
> Cc: lmap@ietf.org; ippm@ietf.org
> Subject: RE: [lmap] [ippm] I-D Action: draft-ietf-lmap-framework-05.txt
> 
> Hi Al,
> 
> I agree with you on all your points, except the use of the word
> "observation" for passive measurement.
> More inline.
> 
> > The key factor in determining the type of measurement in this RFC was
> the
> > a priori knowledge of the packet (or stream) from the source.
> [邓灵莉/Lingli Deng] Support. From the perspective of an MP performing a
> passive task, it has to do the measurement without any reliance on the
> prior knowledge from the source about the targeted traffic (when to expect
> it, how long and how large it would be, etc.). While in contrast, there is
> an active traffic generator in any active measurement task acting as the
> source, to ensure the participating MPs measures metrics for targeted
> traffic with known characteristics.
> 
> > Packet loss could be measured at  mid-point  "C"(and subsequent points)
> > because the measurement system knew when packets were sent from "A"
> > could distinguish between different packets of the same stream, and knew
> > how long to wait for them.
> [邓灵莉/Lingli Deng] There are also passive measurement methods, which can
> measure packet loss at mid-point by doing a little more than pure
> observation.
> Examples include http://tools.ietf.org/html/draft-elkins-ippm-pdm-metrics-
> 04 and http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-
> framework-01 (where the IP header is being marked/appended by an upstream
> MP to coordinate with the downstream MP for measurement on existing
> traffic and no traffic is injected for the purpose of measurement
> therefore no prior knowledge other than the appended/markded information
> piggybacked to the targeted traffic can be assumed for any participating
> MP).
> >
> > Once we are satisfied that the Information Model allows the needed
> flexibility
> > for control, it would be good to take another step: The Information
> Model
> > depends on the Performance Metrics Registry, which we have split into
> > active and passive sub-registries. If the observations you want to make
> at
> > mid-point "C" can be supported with a metric from the passive registry,
> > that's input to the measurement categorization. If not, try the active
> registry.
> > If the active and/or passive registries support some important
> scenarios,
> > then we've come a long way.
> [邓灵莉/Lingli Deng] I would like it more if the word "observation" is
> replaced by "measurement".
> It gives two implications which I think Vero and Nalini wanted to avoid by
> raising the discussion in the first place.
> 1, It gives one the impression that a passive measurement task is always
> performed by an individual MP and does not need any coordination from
> outside.
> 2, An MP doing passive measurement is not supposed to "touch" the traffic,
> but only "observes" them, in which case packet loss can hardly be
> measured.
> >
> 
> Given the fact that "passive measurement" has a lot of possibilities more
> than pure observation, I echo Vero and Nalini that one should cease using
> "observation" as an synonym for passive measurement.
> 
> Lingli
> 
> 
>