Subject: [ippm] draft-ionta-new-multiparty-metrics-framework-00

From: Al Morton <[email-masked]>
Date: Tue, 17 Jan 2012 11:17:54 -0500

Hi Tiziano,

I've just now made time to type-up my comments on your draft.

Some of this is what we discussed in Taipei following the mboned
session,

but I've repeated it here for everyone's benefit.

I'm pleased to see an effort that would help to complete the

memos envisioned under RFC 5835 framework, and will review this

draft further in the future. I hope others will consider this
too.

regards,

Al

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

General

Although the current text and title indicates the concepts here are
new,

this draft actually describes one of the three types of metrics

envisioned in [RFC5835] (Morton, A., Van den Berghe, S.,

"Framework for metric composition", RFC5835, April 2010).

http://tools.ietf.org/html/rfc5835#section-5.2 defines Spatial
Aggregation:

Aggregation in space is defined as the combination of
metrics of the

same type and different scope, in order to estimate the
overall

performance of a larger network.  This combination may
involve

weighing the contributions of the input metrics.

This definition matches the metrics you've defined in the current
draft.

Thus, I think you should consider how to align this draft with the

existing framework for composition, and concentrate on defining the

metrics with weighting factors (section 5).  It should not be very
difficult

to do this, since you have already used definitions from the
framework

RFC 5835 in your terminology section (this makes it a normative
reference,

incidentally). The new title might be:

Spatial Aggregation Metrics for Multiparty Services

Also, I think this memo lends itself to passive measurement as well as

active measurement (with dedicated test traffic). In reality, if the

service provider is in control of the Source traffic on the tree, and

knows and/or can arrange the traffic headers to be suitable for
measurement,

then it blurs the lines quite a bit between passive and active.

The Source's inter-packet sending time distribution comes into focus
as

the main difference - it will not be Poisson and may not be
Periodic,

but it certainly has a "Bias of Interest" as described in RFC
3432.

This is a key area to address further.

The Introduction first mentions the weights for metrics:

...In particular two needs raise:

- widening the aggregation concepts in RFC 5835 [RFC5835], assign a

sort of weight, specific, and different for each link, to the PLR

measured over it, in order to take into account the impact of the PLR

on the service.
s/raise/arise/

There's more Discussion of weights in Section 5.3, including the

"Overlapping Factor".

Bandwidth is one source of weights, but are there others with
objective

derivation (deterministically related to a property of the
link)?

Sec 2.4

...The numbering of the links composing the multiparty tree is free,

provided that:

- the link numbering remains univocal with respect to the multicast

tree.
^^^^^^^^
Do you mean unique here, as in not repeated?

<that's all for now>