Subject: [ippm] why no considerations on the multi-to-multi measurement Metrics?

From: Lei Liang <[email-masked]>
Date: Mon, 26 Jul 2004 13:07:06 +0100 (BST)

Dear all,
  Following the IPPM group for more than 3 years, I have been  doing some
research on the performance measurement. Currently I am doing some thing
about multiparty communications and found there are some thing not covered
by this group. Seems no one say anything about measurement metrics for
multiparty communication that is not completely the same as end-to-end
communication. I had something ready to define more measurement and
parameter metrics for the new coming multiparty communication. However, I
have to know if this is the place to discuss this issue. Any reply will be
much appreciated.
Regards,
Lei Liang

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

---

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Mon, 26 Jul 2004 16:25:07 +0200 (CEST)

Lei,

>From the charter: The IPPM WG will develop a set of standard metrics that
can be applied to the quality, performance, and reliability of Internet
data delivery services.

In first order, your proposed work seems to be within the charter.  I
suggest that you list the issues that you want to discuss in more detail
and/or submit an individual draft.  If this is suitable for IPPM, we can
pick it up as a work item, if not we can always move it elsewhere,

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Process and Procedure are the last hiding place of people without the wit
and wisdom to do their job properly.                          (David Brent).

---

From: Lei Liang <[email-masked]>
Date: Wed, 28 Jul 2004 16:32:18 +0100 (BST)

Dear Henk and all,
  Further to my first email about the consideration of the multiparty
communication parameter metrics, you can find the enclosed a very draft
suggesting more effort on this topic.
 The basic consideration is that in the multiparty communication, we have
a group of people envoled in the action rather than two, which is the
end-to-end situation. One may say that no matter how many people join the
communication, the connections can still be treated as a set of
end-to-end connection. However, we might not describe a multiparty
communication by a set of end-to-end measurement metrics  both because of
the difficulty for understanding and the lack of convenience. for
instance, an engineer might not discribe the connections of a multiparty
online conference in terms of one-way delay for user A and B, B and C, and
C and A because people might be confused. and he might use the worst and
the best metrics to give users an idea how good or bad the service they
are provided. But it's not clear enough and might not be accurate in a big
multiparty communication. My suggestion is to use a more sophisticated way
after reasonable mathematic deriving, i.e. mean, variation etc. the new
metrics will be more efficient and accurate to express the connection
situation among a group of users.
>From the QoS point of view, the multiparty communication services not
only require the absolute QoS support but also the relative QoS. the
relative QoS means the difference between absolute QoS of all users.
Directly using the end-to-end metric can't not present the relative QoS
situation. However, if we use the variations of all users end-to-end
parameters, we can have new metrics to measure the difference of the
absolute QoS and hence provide the threshold value of relative QoS that a
multiparty service might demands. A very good example of the high
relative QoS requirement is the online gaming. a very light worse delay
will result in failure in the game. We have to use the new metrics to
define exactly how small the relative delay the online gaming requires.
there are many other services, e.g. online biding, online stock market,
etc., need a rule to judge the relative QoS requirement. Therefore, we can
see the importance of new metrics to feed this need.
The enclosed document shows some intitial thoughts on this issue. I will
be very glad to hear any comments regarding this consideration.

Best regards,
Lei Liang