Subject: Re: [ippm] Proposed new work items for the group

From: Al Morton <[email-masked]>
Date: Thu, 14 Apr 2005 09:04:59 -0400

At 01:26 PM 03/08/2005, Henk Uijterwaal wrote:
>Following the discussion at our meeting yesterday, we would like to ask
>the group if
>  * draft-stefan-ippm-multimetrics-00.txt
>...
>should become working group items.

I looked at the draft on spatial and multicast metrics again,
and it seems to be worthwhile to take up as a work item.

I understand that these two metric categories were once in separate
drafts, but IMO they might be unified somewhat more
by using a general selection convention.
Something like a list of "measurement points-of-interest"
could serve both the spatial metrics and one-to-group metrics,
and facilitate collecting both types at once.
(I'll take this point up off-list with the authors).

A couple of comments so far:

On Type-P-Spatial-One-way-Delay-Stream (and the other Spatial
metrics), I think you could drop "Stream" for consistency with
earlier sample metrics (for example, where a Poisson Stream
of packets produced the sample).
Although this metric produces multiple values (see section 4.1.4),
I think this is really the -Spatial-One-way-Delay *Singleton*.
A packet traversing the Src-Dst path results in a set of delays
as defined here, including the Type-P-One-way-Delay singleton, dT.
This seems to be the "atomic" level of spatial metrics.

I understand that the spatial and multicast metrics have a
single Source packet in common.  However, there are
other widely used topologies, such as group-to-one and
group-to-group, and they require multiple Source packets
(potentially launched at different times). There would be
a set of "derived metrics" (as RFC 2330 defined) to address
the other topologies.

So, a different draft & proposal would be needed to address
other multi-point topologies, right?

Al

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Lei Liang <[email-masked]>
Date: Thu, 14 Apr 2005 15:11:02 +0100

Dear Al, 
  Thank you very much for your comments. The "measurement
points-of-interest" could be a good idea to summarize the comment parts
between the spatial and multicast metrics. We will be very happy to hear
your further comments on it. 
Regarding the comments on topologies, as you said, we might add a
section in the draft to indicate the possible solutoins with concern of
the multiparty communications. 

Best regards,
Lei Liang

---

From: Lei Liang <[email-masked]>
Date: Wed, 27 Apr 2005 17:04:21 +0100

Hi, Al,
  Thank you very much for your email. I was actually out of office in
last week. So it is very in time.
  Regarding the measurement point, it is a very interesting topic.
Considering both the measurement and calculation aspect, the measurement
point could be critical w.r.t the fact that not all users can be
practical measurement point in the implementation. So when we talk about
one-to-group, we imply that the topology of the communication group is
centre-distributed or server-client topology. the centre or the server
that is controlled by network operators can be the very good reference
point while calculation will be carried out although the actual
measurements have to be carried out at all clients. This reference point
will make the measurement points definition more clear, i.e., the
measurement points will be all clients/receivers while the reference
point acts as source for the one-to-group metric. Or, the reference
point is the measurement point when all clients/receivers act as sources
for group-to-one metric. So we can define the reference point as the
host while the statistic calculation will be done.

some comments in line.

On Fri, 2005-04-22 at 22:29, Al Morton wrote: 
> At 10:11 AM 04/14/2005, you wrote:
> >Dear Al,
> Sorry for the delay, I had to service a priority interrupt,
> and it took me some time to get back to this...
> 
> Briefly, here's the concept:
> 
> The measurement points of all multi-point metrics can be
> defined as a list of points-of-interest.
> So, MP1, MP2, MP3, ... MPn  may be along a single path,
> or they may be at the endpoints of a multicast tree.
> 
> One question is, what's the best way to indicate measurement
> points without ambiguity, using the RFC 2330 Framework?
> A path is composed of hosts and links:
> < h0, l1, h1, l2, h2, ... ln, hn >
> The path definition notes that hosts h1 through hn-1 are routers.
> 
> A multicast tree has many similar paths, and in the
> one to group direction, the measurements terminate in many different hosts.
> 
> So, if we equate measurement points to hosts, then we might have
> something like this:
> 
> (Just a suggestion, not the final text!)
> 
> 2.  Terminology
> 
> 2.1  Multiparty metric
> 
>     A metric is said to be multiparty if it defines more than two hosts
>     as measurement points. All multiparty measurements define a set of hosts
>     called "points of interest", where one host is the source and other hosts
>     are the measurement collection points.  For example, if the set of
>     points of interest is < ha, hb, hc, ... hn >, where ha is the source,
>     then measurements may be conducted between <ha, hb>, <ha, hc>, etc.
> 
a metric is said to be multiparty if it defines more than two sources or
destinations in the measurements. (we don't use measurement point in
order to avoid ambiguity)

> 2.2  Spatial metric points of interest
> 
>     The points of interest can be selected to define a spatial metric.
>     A metric is said to be spatial if one of the hosts involved is
>     neither the source nor the destination of the metered packet.
>     In this case, the useful points of interest are the routers in the
>     path between source and destination (in addition to the source itself).
> 
> 2.3  One-to-group metric points of interest
> 
>     Points of interest can also be selected to define a One-to-group metric.
>     A metric is said to be one-to-group if the measured packet is sent by
>     one source and received by several destinations.
>     In this case, the points of interest are the set of host destinations
>     receiving packets from the source (in addition to the source itself).
> 
> 2.4  Other measurement topologies defined by points of interest
> 
>     We note that points of interest can also be selected to define
>     Group-to-one and Group-to-group topologies. These topologies are
>     currently beyond the scope of this memo, because they would involve
>     multiple packets launched from different sources, and therefore they
>     are simply collections of many point-to-point metrics.
> 
the measurement for group-to-one scenario can be easily derived from the
one-to-group measurement. The measurement point is the same host with
reference point. 
For the group-to-group topology, I think there is a big problem to
define measurement point and reference point. however, no matter how the
users are connected, we can always treat them as one-to-many
connections.