Network Working Group Lei Liang Internet Draft Zhili Sun Expiration Date: February 2005 UniS September 2004 Multiparty Communication Parameters and Metrics 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 Zhili Sun Expiration date: February 2005