Network Working Group Lei Liang
Internet Draft Zhili Sun
Expiration Date: February 2005 UniS
September 2004
Multiparty Communication Parameters and Metrics
<draft-liang-multiparty-para-00.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Other groups may also distribute working documents as Internet-Drafts
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
2. Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
3. Abstract
The purpose of this memo is to highlight the new QoS requirements of
the multiparty communication services in terms of measurement
parameters. It tries to derive a set of parameter metrics from the
existing one-way metrics in IP Performance metrics IPPM [2] [3] [4]
for the multiparty communications to present these new requirements.
These parameter metrics are supposed to provide methods and rules for
engineers to measure and judge the QoS of the multiparty
communications.
4. Overview
Liang et al. [Page 1]
INTERNET-DRAFT Multiparty Communication parameters August 2004
The structure of the memo is as follows:
+ We discuss the new QoS requirements of the multiparty
communications and point out the weakness of using one-way
metrics in these communications.
+ Then we will propose a set of parameters and their metrics for
multiparty communication based on the one-way metrics defined in
IPPM.
+ We will further discuss the possible usage of these proposed
metrics.
5. Motivation
All IPPM QoS parameter metrics are defined for one-to-one
connections. These metrics provide very good guide in the pair
communications. However, further attention should be put on the
multiparty communications, which might use multicast routing
protocols, e.g. the IP conferencing services, online gaming, online
stock market and etc..
The basic consideration is that in the multiparty communication, we
have a group of people involved in the communication rather than two.
Simple one-way parameter metrics cannot describe the multi-connection
situation. One may say that no matter how many people join the
communication, the connections can still be treated as a set of
one-to-one connection. However, we might not describe a multiparty
communication by a set of one-way measurement metrics because of
the difficulty for understanding and the lack of convenience. For
instance, an engineer might not describe 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. If there
are more users in the same communication, the description might be
very long. And he might use the one-way metrics with worst and the
best value to give users an idea of the QoS range of the service they
are provided. But it's not clear enough and might not be accurate in
a large multiparty communication scenario. The new suggestion is to
use the one-way parameters in 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 one-way metrics cannot present the relative QoS
situation. However, if we use the variations of all users one-way
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 demand. A very good example of the
Liang et al. [Page 2]
INTERNET-DRAFT Multiparty Communication parameters August 2004
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. Two groups of parameter are proposed in this stage.
6. Parameters and Metrics for Multiparty Communication
To conveniently define new metrics, we call all of the users in the
same multiparty communication a user group. This user group should
not be mixed with the multicast user group conception. Group
members could use either pure unicast or multicast to communicate or
mixed, i.e. some of the users in the group could use unicast while
others use multicast.
When talking about a new metrics we always have an observation
point that is one of the users in the group. We classify the new
metrics into two groups based on the fact that one user could be
either a source or a receiver. Therefore, one group metrics will
describe the QoS going out from the group to one particular user and
another group describe the QoS coming into the group. We name them
as one-to-group parameter metrics and group-to-one parameter metrics.
In the document,both of two group parameters are called multiparty
communication parameters.
These new proposed metrics are established on the base of the one-way
metrics defined in the corresponding RFCs in the IPPM working group.
And no modification should be added to those one-way metrics in any
aspects. This memo only describes the basic aspect of the proposed
metrics. Any aspect that is not mentioned in this memo can be
found in the corresponding one-way metric RFCs.
6.1 One-to-group Parameters and Metrics
One-to-group parameters are defined to measure the QoS in the view of
a group user. Two subset parameters are introduced:
1. One-to-group (algorithm) mean
a. One-to-group mean delay
b. One-to-group mean jitter
c. One-to-group mean packet lost rate
2. One-to-group variation
a. One-to-group delay variation
b. One-to-group jitter variation
c. One-to-group packet loss rate variation
Liang et al. [Page 3]
INTERNET-DRAFT Multiparty Communication parameters August 2004
The one-to-group parameters are measured based on only one source in
a multiparty communication group. Whenever we say one-to-group
parameter, we should associate it with a source. The Figure 1 shows
this concept.
+---------+
| User B |
+---------+
^
|
IP Network
|
+--------+ +---------+ +--------+
| User C |<-IP Network--| User D |--Satellit link->| User A |
+--------+ +---------+ +--------+
|
|
LAN
|
v
+---------+
| User E |
+---------+
Figure 1 One-to-group measurement scenario example
In Figure 1, user A, B, C, D and E belong to the same multiparty
communication group. User D is the only active source in the
group when measuring the one-to-group parameters. User
B and C are connected with user D through terrestrial IP network,
user E are in the same LAN with user D. User A are connected with
user D using a satellite network. The one-to-group parameters
measured in this scenario should be associated with user D.
6.1.1 One-to-group (Arithmetic) Mean
One-to-group mean parameters are trying to measure the overall
QoS for a multiparty communication group. The definition of the
One-to-group mean is the mean of a one-way parameter, such as
one-way delay, one-way jitter and packet loss rate, measured
simultaneously on all of the group members except of the active
source. The word "simultaneously" implies the one-way parameter
should be measured based on the same sample interval at each user.
The One-to-group mean parameter can be calculated as:
P_ogm_para = SUM (Pi)/ N ( i = 1, 2, 3, ... N) (Equation 1)
where P_ogm_para is the One-to-group mean parameter, Pi is the
corresponding one-way parameter. N is the number of the users
except the active user in the group during the sampling
interval.
Liang et al. [Page 4]
INTERNET-DRAFT Multiparty Communication parameters August 2004
"para" means the one-way parameter's name such as
delay, jitter and packet loss rate.
6.1.1.1 Metric Name:
Type-P-One-to-group-Mean-Parameter
The "Parameter" could be any one of the one-way parameter defined
in IPPM including delay, jitter and packet loss rate.
6.1.1.2 Metric Parameters:
+ Src, the IP address of a source
+ Grp, the multicast group address is multicast or empty for
non-multicast
+ M, a derived value corresponding to one-way parameter
6.1.1.3 Metric Units:
The value of a Type-P-One-to-group-Mean-Parameter is depends on
what one-way parameter is used. It should be the same
corresponding to the one-way metrics defined in IPPM.
6.1.1.4 Methodologies:
As the metric is derived from the corresponding one-way metric,
the methodology to obtain those one-way parameters can be refer to
the corresponding RFCs. We only discuss the methodology to derive
One-to-group mean metric from one-way parameter without consideration
of details on synchronization, test packetizing, time and etc..
1. Simultaneously measure the interested one-way parameters, one-way
delay, one-way jitter or packet loss, on all of the receivers in
a multiparty communication group when there is only one source
active.
2. Calculate the mean of one-way metric value using equation 1 to
obtain the One-to-group mean metric for this source. The
question of when to calculate the One-to-group mean metric will
be discussed in 6.1.1.5.
3. Change the active source and repeat the step 1 and 2 until all
of the group members have been active as sources.
Liang et al. [Page 5]
INTERNET-DRAFT Multiparty Communication parameters August 2004
6.1.1.5 Discussion:
In the second step of methodology part, we have to decide when to
do the One-to-group mean metric calculation. Basically, there are
three ways to do so. The first way is to do the calculation based
on each packet arrival. The active source sends packet one by one
with sequence number in the packet headers so that all receiver
could identify each packet. The One-to-group mean calculation is
executed for each packet received by all receivers. The resulted
metric is similar to the singleton metrics defined for one-way
parameters corresponding to every packet received by all users. It
will provide the most accurate record of the group mean during a
sampling interval with the heaviest calculation overhead.
The second way to calculate the One-to-group mean is to use the
mean of one-way parameter rather than the parameter itself. The
calculation could be scheduled to be executed periodically. For
instance, it can be triggered for every T seconds. During the T
seconds, all one-way parameters measured have to be recorded at
each receiver. At each T second, the mean of the recorded
parameter will be calculated first at each receiver and used as in
equation 1 to calculate the One-to-group mean metric value. This
way can reduce the heavy calculation overhead required by the first
one. However, it would provide less detailed information and need
more storage space to record one-way parameters for more than one
packet.
The third way to calculate the One-to-group mean metric is to mix
the previous two ways together. We periodically calculate the
One-to-group mean parameter using directly the corresponding
one-way parameter metric value rather than using its mean. For
instance, the calculation can be prearranged to be triggered for
every T seconds. The receivers don't need to record the one-way
metric value for all of the packets received during each T seconds.
we would calculate the One-to-group mean metric value at each T
second using the corresponding one-way parameter of the latest
received packet. Therefore, the One-to-group mean metrics of all
receivers calculated at the same time would not be for the same
packet. However, that would not affect engineers to use these
metrics because they can still present the network situation at
each T second without regarding to packets. Hence, the sequence
number seems not necessary for One-to-group mean delay and jitter
metrics. However, it still has to been added to the test packets
to notify the packet loss. By calculating the One-to-group mean
metrics in this way, we can overcome the requirement of big
storage space on each receiver and the calculation overhead.
One point has to be mentioned here is the calculation of the
One-to-group mean packet loss rate. Because the packet loss rate
itself is a statistic parameter for a certain measurement interval,
Liang et al. [Page 6]
INTERNET-DRAFT Multiparty Communication parameters August 2004
we have to use the second way to calculate the One-to-group mean
packet loss rate.
Clearly, the One-to-group mean calculation period T is a very
important factor in the implementation of the measurement. If it
is too small, we will not save any calculation overhead. If it is
too big, we might loss most of the network situation information.
And it might be different for various applications as well.
However, how to find a proper T is outside the scope of this
document. {Comment: We plan to document elsewhere our own work in
describing such more detailed implementation techniques and we
encourage others to as well.}
6.1.2 One-to-group Variation
One-to-group variation metrics are trying to measure how the QoS
varies among all of the users in a multiparty communication group
relative to one source. The word "variation" in this document is
the population standard deviation. The definition of the
One-to-group variation is the population standard deviation of a
one-way parameter, such as one-way delay, one-way jitter and packet
loss rate, measured simultaneously at all of the group members
except of the active source. Therefore, we can have One-to-group
delay variation, One-to-group jitter variation and One-to-group
packet loss rate variation. The word "simultaneously" implies the
one-way parameter should be measured based on the same sample
interval at each user. Considering the case shown in Figure 1 as
an example, when D is active, we simultaneously monitor a set of
packets from P1 to Pn on all of the rest 4 users respectively.
Then, the interested one-way parameter of these packets is
calculated for each of user. The corresponding One-to-group mean
metric could be calculated based on the one-way parameter.
Finally, we calculate the variation of these 4 values of the
one-way parameter measured on 4 receivers as the One-to-group
variation parameter for this scenario. The One-to-group variation
parameter can be denoted by P_ogv_para, where the symbol "para"
means the one-way parameter's name such as delay, jitter and
packet loss rate, and calculation should be:
P_ogv_para = ((SUM((Pi-P_ogm_para)^2))/N)^(1/2)
(i = 1, 2, 3,...N) (Equation 2)
where Pi is the one-way parameter value (delay, jitter and packet
loss rate) and P_ogm_para is the corresponding One-to-group mean
parameter value. N is the number of the receivers.
6.1.2.1 Metric Name:
Liang et al. [Page 7]
INTERNET-DRAFT Multiparty Communication parameters August 2004
Type-P-One-to-group-Variation-Parameter
The "Parameter" could be any one of the one-way parameter defined
in IPPM including delay, jitter and packet loss rate.
6.1.2.2 Metric Parameters:
+ Src, the IP address of a source
+ Grp, the multicast group address is multicast or empty for
non-multicast
+ V, a derived value corresponding to one-way parameter
6.1.2.3 Metric Units:
The value of a Type-P-One-to-group-Variation-Parameter is depends
on what one-way parameter is used. It should be the same
corresponding to the one-way metrics defined in IPPM.
6.1.2.4 Methodologies:
As the One-to-group variation parameter metric has to be derived
on the base of the group mean metric, we have to calculate the
One-to-group mean metric first. So the methodology become simple
inheriting from the one defined for the One-to-group mean metric.
1. Find out the One-to-group mean parameters
2. Calculate the One-to-group variation parameters using the
equation 2.
3. Repeat the step 1 and 2 for all users in the same multiparty
communication group.
6.1.2.5 Discussion:
As the One-to-group variation parameters must be derived based on
the One-to-group mean parameter, its calculation must be
corresponding to the one of the One-to-group mean parameter
described in section 4.1.1.5. I.e., for each One-to-group mean
parameter calculation, we can have the corresponding One-to-group
variation parameter calculation.
6.2 Group-to-one Parameter Metrics
Liang et al. [Page 8]
INTERNET-DRAFT Multiparty Communication parameters August 2004
Group-to-one parameters are defined to measure the QoS in the view
of one multiparty communication user with respect to the fact that
this user is receiving from more than one source in the group.
Similar to the one-to-group parameters, two subset parameters are
proposed:
1. Group-to-one member (arithmetic) mean
a. Group-to-one mean delay
b. Group-to-one mean jitter
c. Group-to-one mean packet loss rate
2. Group-to-one variation
a. Group-to-one delay variation
b. Group-to-one jitter variation
c. Group-to-one packet loss rate variation
The group-to-one parameters are measured based on only one receiver
in a multiparty communication group. Whenever we say group-to-one
parameter, we should associate it with the receiver. The Figure 2
shows this concept.
+---------+
| User B |
+---------+
|
IP Network
|
v
+--------+ +---------+ +--------+
| User C |--IP Network->| User D |<-Satellit link--| User A |
+--------+ +---------+ +--------+
^
|
LAN
|
|
+---------+
| User E |
+---------+
Figure 2 Group-to-one measurement scenario example
Figure 2 shows almost the same information as Figure 1. The
difference is, in Figure 4, user D is the receiver who received
data from all of the rest group members simultaneously or
consequently. The group-to-one parameters measured in this
scenario should be measured and associated with user D.
In the following sections, we will define these parameters and
their metrics. You will find the definitions are very similar
to one-to-group parameters. One might question on if we need to
have separately definitions of one-to-group and group-to-one
Liang et al. [Page 9]
INTERNET-DRAFT Multiparty Communication parameters August 2004
parameters. The answer is positive and we will discuss it after
the definition.
6.2.1 Group-to-one (arithmetic) Mean
Group-to-one mean parameters are trying to measure the QoS of
a multiparty communication group received by one user. The
definition of the Group-to-one mean parameter of a user is the
mean of a one-way parameter, such as one-way delay, one-way
jitter and packet loss rate, measured on that user when it
simultaneously receiving data from all the rest users in the
group. The word "simultaneously" implies the one-way parameter
should be measured based on the same sample interval on the
measured user. The Group-to-one mean parameter can be calculated
as:
P_gom_para = SUM (Pi)/N (i = 1,2,3,...N) (Equation3)
where P_gom_para is the Group-to-one mean parameter, Pi is the
corresponding one-way parameter from each of the source to the
measured user. N is the number of the users except the measured
user in the group during the sampling interval. "para" means the
one-way parameter's name such as delay, jitter and packet loss
rate.
6.2.1.1 Metric Name:
Type-P-Group-to-one-Mean-Parameter
The "Parameter" could be any one of the one-way parameter defined
in IPPM including delay, jitter and packet loss rate.
6.2.1.2 Metric Parameters:
+ Dst, the IP address of a receiver
+ Grp, the multicast group address is multicast or empty for
non-multicast
+ M, a derived value corresponding to one-way parameter
6.2.1.3 Metric Units:
The value of a Type-P-Group-to-one-Variation-Parameter is depends
on what one-way parameter is used. It should be the same
corresponding to the one-way metrics defined in IPPM.
Liang et al. [Page 10]
INTERNET-DRAFT Multiparty Communication parameters August 2004
6.2.1.4 Methodologies:
As the group-to-one mean parameter metric also derived on the base
of the corresponding one-way parameter metric, we still only
discuss the methodology to derive Group-to-one mean metric from
one-way metric without consideration of details on synchronization,
test packetizing, time and etc..
1. Simultaneously measure the interested one-way parameters,
one-way delay, one-way jitter or packet loss, on the measured
user while all of the rest of users in the multiparty
communication group sending data to it. All the one-way
parameter should be measured based on the source and
destination pair.
2. Calculate the mean of one-way metric value using equation 3 to
obtain the Group-to-one mean metric for the measured user. The
question of when to calculate the group-to-one mean metric will
be discussed in 4.2.1.5.
3. Change the active source and repeat the step 1 and 2 until all
of the group members have been measured.
6.2.1.5 Discussion:
As we did to the One-to-group mean parameter, we should determine
when to calculate the Group-to-one parameter here. Clearly we can
use the three ways proposed for the One-to-group mean parameter to
calculate the Group-to-one mean parameter. The only difference is
the former has many measurement points and calculation has to be
done with the information provided by all of these measurement
points while for the later all information needed for the
group-to-one parameter can be provided by a single measurement
point.
6.2.2 Group-to-one Variation
Group-to-one variation metrics are trying to measure how the QoS
varies at one user in the multiparty communication group when the
rest of users sending data to it. The definition of the
Group-to-one variation is the population standard deviation of a
one-way parameter, such as one-way delay, one-way jitter and
packet loss rate, measured at one user in a multiparty
communication group while all of the rest group members sending
data simultaneously to it. Therefore, we can have Group-to-one
delay variation, Group-to-one jitter variation and Group-to-one
packet loss rate variation. The word "simultaneously" implies
Liang et al. [Page 11]
INTERNET-DRAFT Multiparty Communication parameters August 2004
the one-way parameter should be measured based on the same sample
interval at the measured user. Considering the case shown in
Figure 2 as an example, when D is chose as the measured user, we
simultaneously monitor a set of packets from P1 to Pn sent by each
of the rest 4 users respectively. Then, the interested one-way
parameter of these packets is calculated for each pair of users,
i.e., D and A, D and B, D and C and D and E. The corresponding
Group-to-one mean metric could be calculated based on the one-way
parameter. Finally, we calculate the variation of these 4 values
as the Group-to-one variation parameter for this scenario. The
One-to-group variation parameter can be denoted by P_gov_para,
where the symbol "para" means the one-way parameter's name such
as delay, jitter and packet loss rate, and calculation should be:
P_gov_para = ((SUM((Pi-P_gom_para)^2))/N)^(1/2)
(i = 1, 2, 3,...N) (Equation 4)
N is the total user number in the multiparty communication except
the measured one and pi is the one-way parameter for each of the N
users.
6.2.2.1 Metric Name:
Type-P-Group-to-one-Variation-Parameter
The "Parameter" could be any one of the one-way parameter defined
in IPPM including delay, jitter and packet loss rate.
6.2.2.2 Metric Parameters:
+ Dst, the IP address of a receiver
+ Grp, the multicast group address is multicast or empty for
non-multicast
+ V, a derived value corresponding to one-way parameter
6.2.2.3 Metric Units:
The value of a Type-P-Group-to-one-Variation-Parameter is depends
on what one-way parameter is used. It should be the same
corresponding to the one-way metrics defined in IPPM.
6.2.2.4 Methodologies:
Liang et al. [Page 12]
INTERNET-DRAFT Multiparty Communication parameters August 2004
The methodology can be simply inherited from the one defined for
the Group-to-one mean metric as:
1. Find out the Group-to-one mean parameters
2. Calculate the Group-to-one variation parameters using the
equation 4
3. Repeat the step 1 and 2 for all users in the same multiparty
communication group
6.2.2.5 Discussion:
As the Group-to-one variation parameters must be derived based on
the Group-to-one mean parameter, its calculation must be
corresponding to the one of the Group-to-one mean parameter
described in section 4.2.1.5. I.e., for each Group-to-one mean
parameter calculation, we can have the corresponding Group-to-one
variation parameter calculation.
6.3 Reasons for Two groups of similar parameters
As we mentioned in the beginning of section 4.2, the definitions
of One-to-group parameters and Group-to-one parameters are very
similar. There are reasons we should separately define them.
Firstly it is because of the metric parameter definition. The
One-to-group metrics have a common parameter, Src, the IP
address of the active source during the measurement interval.
It must be changed to Dst parameter for the Group-to-one metrics
to present the measured user. It's not like the case for the
one-way parameter measurement where the destination and the
source are single host in the same level. They can be exchanged
in the measurement without any difficulty. Therefore one metric
is enough for measurement between one pair of hosts. In the
multiparty communication, the source and the destination cannot
be exchanged because one of them presents more than one user. We
have to define two metrics for the measurement for two directions.
For instance, if user A and user B communicates with each other,
the one-way delay metric can be used for both direction traffics
by exchanging the Src and Dst parameter [3]. However, if user C
joins their communication, we have to user the proposed new
metrics to measure the QoS for the multiparty communication. The
One-to-group mean delay metric and the One-to-group delay
variation can show clearly the QoS received by user A and user B
in the group relative to user C. We cannot use the same metrics
to measure the QoS received by C relative to both user A and user
B by simply exchanging the Src and Grp parameter in the metric
because of the methodology described for One-to-group parameter.
Liang et al. [Page 13]
INTERNET-DRAFT Multiparty Communication parameters August 2004
Secondly, we should define Group-to-one and One-to-group
separately because of the transporting technologies used for
multiparty communications. There might be the coexistence of
both unicast and multicast. One host in a multiparty
communication group might use unicast to receive data from
other hosts and user multicast to send data to the others. The
delay of each direction would be different due to the
difference of the transport technologies. If we can say that
for one-to-one communications, delays for both directions can be
approximately the same, we might not have the same conclusion
for the multiparty communications. Therefore, we need two
groups of metric to describe the network situation regarding
the traffic direction.
7. Relative QoS and the Proposed Metrics
There is an interesting point in the methodologies for obtaining
the Group-to-one parameters that we have all of the rest users
sending data simultaneously rather than let them work separately
in order. The same question can also be asked for the
methodology of the One-to-group parameter. As we discussed in
the motivation part that the second reason we propose these new
parameters and their metrics is that the multiparty communication
have extra requirements on the relative QoS beside the absolute
QoS. These proposed metrics could be used to describe and
measure the relative QoS, which implies that all the one-way
parameters needed to derive the Group-to-one and One-to-group
parameters have to be measured in the same measurement interval
rather than separately in an order. We cannot describe the
relative QoS by compare the same parameter for different
connection in different time.
Here we have some example to show how to use the proposed metrics
to describe and measure the relative QoS. For instance, the
relative delay can be measured by using the Group-to-one and
One-to-group delay variation metric. Group-to-one delay
variation measures the difference of delays received by one
user in a multiparty communication group relative to the rest
sources. A centralized multiparty communication where all
clients have to communicate with the rest group members through
a central server might require the transmission delays from all
clients to the server satisfy a Group-to-one delay variation
threshold to guarantee that no clients suffer much bigger delay
than others or enjoy much smaller delay than others. Typical
examples are the services that need their users to compete with
each other. The One-to-group delay variation measures how
different for each user to receive data from one source in a
multiparty communication group, which is another a relative QoS
issue. No matte what topology the multiparty communication
Liang et al. [Page 14]
INTERNET-DRAFT Multiparty Communication parameters August 2004
service uses, it might need one One-to-group delay variation
threshold to ensure that all group members can have the close
priority to make further move to response to any source in the
group.
An example of the use of the proposed metrics might be the
adaptable priority optimisation algorithm. The basic idea is to
dynamically change the priority for each group member according
to the network situation to guarantee that all members in the
group have close QoS. In another word, the Group-to-one
variation and One-to-group variation parameter should be kept
under a certain threshold to satisfy the relative QoS
requirements for various applications. The detail of this
adaptable priority optimisation algorithm is out of the scope
of this document.
8. Errors
We are not going to discuss errors caused by the measurement of
the one-way parameters in this document because they can be found
in the corresponding RFCs. We have to discuss the errors
introduced by the proposed metrics in this document. The reason
of these errors is the packet loss in the network. When a packet
never arrive its destination, its delay might be hidden from the
result.
When we discussed about when to calculate the proposed metrics,
we gave three ways. The first way proved one-way parameter
metrics corresponding to packets. That means for each packet
we can find one metric for it. Then error caused by packet loss
can then be easily sorted out before we calculate the
Group-to-one and One-to-group parameters.
However, for the other two ways, we either use a mean to present
the interested one-way parameter or the last packet received by
the measurement point during a period of time. If there are
any packets lost in the period of time, they will be ignored by
the calculation of the multiparty communication parameters. For
instance, we do the calculation of the multiparty communication
parameters for every T seconds. Then for the second way, the
mean of the one-way delay in a T second could be infinity if any
packets lost during that T second and infinity is a valid metric
value for the one-way delay metric. Then our Group-to-one and
One-to-group mean parameters and variation parameters could be
infinity after calculation. This infinity doesn't mean anything
in terms of relative delay for multiparty communication. We
should not have the conclusion that during that T seconds, users
in the group suffered significantly different delay.
Liang et al. [Page 15]
INTERNET-DRAFT Multiparty Communication parameters August 2004
For the third way where we only use the latest packet received
during a T seconds, if all of the packets were lost during the T
seconds, which is quite possible since T could be a very short
time, the one-way metric value we use to calculate the multiparty
communication parameters will be the one for the latest packet
receiver in last T seconds. Clearly, the result will not reflect
any information of the network situation during this T seconds
and therefore, it becomes an error.
The possible calibration can be done by using more sophisticated
way to calculate the multiparty communication parameters. For
instance, we can ignore all the one-way metrics with infinity
value when we calculate the multiparty communication parameters
for the second calculation way. We can find out which T seconds
suffers from the packet lost and do not calculate the multiparty
communication parameter for it in the third way. There might be
other methods to calibrate the errors, which we did not discuss
here. As long as they can avoid leading us to the wrong
analysis, they can be implemented in the application.
9. References
[1] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework
for IP Performance Metrics", RFC 2330, May 1998.
[2] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[3] G. Almes, S. Kalidindi, and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[4] C. Demichelis, and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
8. Authors' Addresses
Lei Liang <l.liang@eim.surrey.ac.uk>
Zhili Sun <z.sun@eim.surrey.ac.uk>
Expiration date: February 2005