Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Feb 2013 11:56:49 +0100

Hi,

Following Dan's comments, we have tried to explore how IPFIX can be used 
to report test results from the measurement agent to the collector.
Please find it described in the following draft.
Comments are welcome.

Regards, marcelo

-------- Mensaje original --------
Asunto: 	I-D Action: draft-bagnulo-lmap-ipfix-00.txt
Fecha: 	Fri, 08 Feb 2013 02:54:29 -0800
De: 	[email-masked]
Responder a: 	[email-masked]
Para: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : An LMAP application for IPFIX
	Author(s)       : Marcelo Bagnulo
                           Brian Trammell
	Filename        : draft-bagnulo-lmap-ipfix-00.txt
	Pages           : 9
	Date            : 2013-02-08

Abstract:
    This document explores the possibility of using IPFIX to report test
    results from a Measurement Agent to a Collector, in the context of a
    large measurement platform.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bagnulo-lmap-ipfix

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bagnulo-lmap-ipfix-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Tue, 12 Feb 2013 12:14:23 -0500

Hi Marcelo and Brian,

This is a good initial examination of the 
reporting problem seen through IPFIX-glasses, 
and it seems to be a decent match.

A couple of comments below,
Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Friday, February 08, 2013 5:57 AM
> To: [email-masked]
> Subject: [lmap] Fwd: I-D Action: draft-bagnulo-lmap-ipfix-00.txt
> 
> Hi,
> 
...

In section 2:
   Part of the information can be conveyed using the fields in the IPFIX
   header, namely:

   o  Information about the MA: In order to convey the MA identifier we
      can use the Observation Domain field present in the IPFIX header.
      This would allow to have up to 2^32 MA, which seems sufficient.

Although the 32-bit identifier range is huge, it may be helpful in the
long term to structure the MA identifiers in one way, so they can convey 
some limited info about the MA beyond unique identity. 
MAC addresses provide one example structure http://en.wikipedia.org/wiki/MAC_address
I suggest the MA Identifier format goes on the to-standardize list
(which seems to be section 5).

more section 2:
   o  An identifier of the scheduling strategy used to perform the test.
      Again, this will be a new IE, called testSchedule and its values
      will be the values defined in the Scheduling registry of
      [I-D.bagnulo-ippm-new-registry-independent].  The potential input
      parameters for the schedule, such as the rate, we probably need a
      new IE for each of these.  Usual scheduling distributions only
      require a rate, so we can define a new IE called scheduleRate
      which value will contain the rate for the requested distribution.

While rate fit Poisson and Periodic very well, some test streams require
as many as three stream specifications:
  + a rate for sending ensembles of packets
  + a rate for sending packets within each ensemble
  + the number of packets in each the ensemble
so it seems these are all potential IE, if I understand how it will work.

section 3:
This is a useful example, and at the same time
I'm sure many readers will think there are many IE repeated here 
to convey each singleton of UDP Latency. The observation simply
encourages the investigation of a more compact option under
IPFIX rules - something to think about.  And section 4 seems
to describe exactly that, so to clarify:

section 4:
Would use of the Options Template mean that all these:
      metricIdentifier = UDP_Latency as per
      [I-D.bagnulo-ippm-new-registry-independent]
      testSchedule = Periodic as per
      [I-D.bagnulo-ippm-new-registry-independent]
      scheduleRate = 1
      outputType = Raw as per
      [I-D.bagnulo-ippm-new-registry-independent]
      testEnvironment = No-cross-traffic as per
      [I-D.bagnulo-ippm-new-registry-independent]
      sourceIPv4Address = 192.0.2.1
      destinationIPv4Address = 203.0.113.1
      sourceTransportPort = 23677
      destinationTransportPort = 34567

would appear only once in the exchange that describes a finite-length test?

---

From: Brian Trammell <[email-masked]>
Date: Wed, 13 Feb 2013 09:56:25 +0100

hi, Al,

Thanks for the comments! Comments/questions inline.

> (which seems to be section 5).

Yep. We could certainly define a 32-bit MAID with structure, then say "an MA is coterminous with an IPFIX Observation Domain" in the lmap-ipfix binding. Will 32 bits be enough?

> so it seems these are all potential IE, if I understand how it will work.

Will we ever (realistically) have nesting of ensembles?

(e.g. pattern-1 = 3ms delay 200 packets/3ms; pattern 2 = 10 ms delay pattern-1 4ms delay pattern-1)

> to describe exactly that, so to clarify:

There's a couple of reasons to start from here.

First of all, Options (as below) are essentially an on-wire way to compress scoped values; the API at the MA and at the Collector should give you access to those values as if they are properties of the record anyway. So this view looks like the the resulting data received by the collector, if not precisely how it will be represented.

Second, I'm a little skeptical of the true cost-benefit of compressing things this way. If you're dealing with a federated system in which each measurement may be forwarded / correlated / aggregated / transformed by different mediators (collectors which process and re-export information -- in the LMAP case, think intermediate collectors at each POP), then scoping things to sessions so as to reduce redundancy means you need to keep those sessions separate across mediation sessions, or have those mediators do something like remap re-exported sessions to a commonPropertiesId (see RFC 5473). The tradeoff here is on-wire efficiency for complexity.

At high degrees of aggregation and low rates of export, you end up with almost every record having all the values anyway: the channel from the MA to the first level collector might send one message every second, the channel from that collector back to central reporting would have one record per MA per second, bundled together into messages. Now you have to export the parameters for each MA (or find properties common to all MAs, and split the common properties into MA, sub-global, and global), and so on.

The math changes depending on how much information is common to each record from an MA (test conditions) how much information is different (test results), and how it will be aggregated as it moves toward the center; we should actually do an analysis based on expected measurement traffic load to see what we should recommend sticking in options and what not. What seems self-evident looking at a single record has to be considered in the context of how it will scale up and out.

> would appear only once in the exchange that describes a finite-length test?

That's the idea. Options in this case bind values to sessions, which is essentially a way of compressing the data at the IPFIX level by making it implicit.

Cheers,

Brian

> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Thu, 14 Feb 2013 18:30:17 -0500

Hi Brian,

Thanks for your questions to further discussion, and especially for
your detailed reply revealing some of the complexities of scale
when intermediate collectors and re-exporting are necessary.
Very thoughtful stuff: I sense you have already been living in the
world of Large-Scale.

Regarding MA Identification, 32 bits will certainly get us started,
but we don't need to set a limit this week :-) . The main point is to 
get the MAID format on our to-do list for standardization, and we've 
begun the discussion with 3 messages. Since you mentioned a possible 
proliferation of collectors, maybe we should be considering more than
Mas when assigning ID...

"Would we ever have Nesting of ensembles?"
I never say never, but I actually thought of a legitimate use case.
One would pre-load the test path with one type of ensemble rate & length,
then perform the measurement with another ensemble, different rate and length.
The same thing could be handled with a form of multi-stage scheduling,
which a few of us discussed last week, and I'll repeat some of what
I wrote for everyone here:

... it seems fairly simple to use
the current registries for metric, scheduling, output and (desired?) environment
to indicate the specifications that will likely change from test to test.
Plus, we need two more specifications:

+ pause time following a measurement of a set of singletons (sample)
+ indicator that the *following* test specification is to run concurrently (& below)

So, an AA0000001 test series could be registered and used to perform
(this is for a latency test performed on its own, 
environment_1 allows cross traffic, then a BTC test
with concurrent latency, no cross traffic other than test traffic):

 - UDP Latency_1, Poisson_3, output_4, environment_1, pause=5000ms,
 & BulkTransCap_1, LocalCtrl, output_1, environment_0, pause=1000ms,
 - UDP Latency_1, Poisson_3, output_4, environment_0, pause=1000ms,
 - END

There are many specs that don't change from test to test, 
like Source address, Dest address, overall test sequence start time,
measurement points (mp100, mp150), so one view of the test schedule
would simply list these factors and "test sequence=AA0000001".

Al

> From: Brian Trammell [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2013 3:56 AM
> To: MORTON JR., ALFRED (AL)
> Cc: marcelo bagnulo braun; [email-masked]
> Subject: Re: [lmap] I-D Action: draft-bagnulo-lmap-ipfix-00.txt
> 
> hi, Al,
> 
> Yep. We could certainly define a 32-bit MAID with structure, then say "an
> MA is coterminous with an IPFIX Observation Domain" in the lmap-ipfix
> binding. Will 32 bits be enough?
> 
> > more section 2:
> First of all, Options (as below) are essentially an on-wire way to
> compress scoped values; the API at the MA and at the Collector should give
> you access to those values as if they are properties of the record anyway.
> So this view looks like the the resulting data received by the collector,
> if not precisely how it will be represented.
> 
> Second, I'm a little skeptical of the true cost-benefit of compressing
> things this way. If you're dealing with a federated system in which each
> measurement may be forwarded / correlated / aggregated / transformed by
> different mediators (collectors which process and re-export information --
> in the LMAP case, think intermediate collectors at each POP), then scoping
> things to sessions so as to reduce redundancy means you need to keep those
> sessions separate across mediation sessions, or have those mediators do
> something like remap re-exported sessions to a commonPropertiesId (see RFC
> 5473). The tradeoff here is on-wire efficiency for complexity.
> 
> At high degrees of aggregation and low rates of export, you end up with
> almost every record having all the values anyway: the channel from the MA
> to the first level collector might send one message every second, the
> channel from that collector back to central reporting would have one
> record per MA per second, bundled together into messages. Now you have to
> export the parameters for each MA (or find properties common to all MAs,
> and split the common properties into MA, sub-global, and global), and so
> on.
> 
> The math changes depending on how much information is common to each
> record from an MA (test conditions) how much information is different
> (test results), and how it will be aggregated as it moves toward the
> center; we should actually do an analysis based on expected measurement
> traffic load to see what we should recommend sticking in options and what
> not. What seems self-evident looking at a single record has to be
> considered in the context of how it will scale up and out.
> 
> > section 4:
> That's the idea. Options in this case bind values to sessions, which is
> essentially a way of compressing the data at the IPFIX level by making it
> implicit.
> 
> Cheers,
> 
> Brian
>

---

From: Brian Trammell <[email-masked]>
Date: Fri, 15 Feb 2013 15:48:39 +0100

hi Al, all,

a couple of brief points inline (will have to think more about the ensemble nesting thing)...

> proliferation of collectors, maybe we should be considering more than

Indeed. If a mediator (collector and re-exporter with some intermediate process that correlates/aggregates/filters/etc the records sent across it) generates substantially new data records (i.e., by deriving a new metric through spatial or temporal composition), it's generally considered a new Observation Domain. 

So we probably want to identify anything that sends reports with a MAID.

> would simply list these factors and "test sequence=AA0000001".

Then we probably want to use an explicit test sequence identifier, and use options records to define the test sequence parameters. We may also want to have two sequence identifiers, one for metrics-registry keys representing the environment, test schedule, etc., and one representing test parameters like the source, destination, etc...

Cheers,

Brian