Fairness of Adaptive Multimedia Applications - Semantic Scholar

Fairness of Adaptive Multimedia Applicationsy Dorgham Sisalem GMD-Fokus Kaiserin-Augusta-Allee 31 10589 Berlin Germany Tel.: ++49 30 34 63 71 70 Fax.: ++49 30 34 63 81 70 sisalem@fokus.gmd.de

Technical Subject Area:

Multimedia Communications

Abstract In this study, we present a new scalable scheme for adapting the transmission rate of multimedia applications to the congestion level of the network. The scheme is based on the end-to-end Real Time transport protocol (RTP). Results achieved through simulations and measurements suggest the efficiency of the scheme in utilizing the network resources and decreasing the loss rates. However, with no support from the network, adaptive applications tend to be unfair towards long distance connections and lead to the starvation of competing TCP connections.

This work was funded in part by the BMBF (German Ministry of Education and Research) and

the DFN (German Research Network). y In case of acceptance the paper will be presented by Dorgham Sisalem

1

Sisalem: Fairness of Adaptive Multimedia Applications

1

1 Introduction The vast majority of multimedia applications used currently in the Internet, such as VIC [14], VAT [13], N E V O T [2] and N E V I T [22] are based on the UDP and RTP transport protocols. However, both UDP and RTP offer no means of quality of service control and can not thereby guarantee any level of QoS. Due to the fluctuations in the network conditions, the inability of those protocols to support QoS control renders multimedia applications, often, useless. Two main approaches were introduced in the past to overcome this problem: resource reservation [3] and application control [7]. Reserving enough resources for supporting a certain QoS level in advance guarantees this quality level and would be the most straight forward approach for handling the problem. However, as it is usually impossible to know the exact characteristics of a certain stream in advance one would tend to over reserve resources to guarantee the requested QoS level. This would, however, lead to under utilizing the network and would get costly if one has to pay for the reserved but unused resources. By trading off temporal and spatial quality to available bandwidth or manipulating the playout time of continuous media in response to variations in delay, multimedia flows can keep an acceptable QoS level at the end systems without necessarily requiring any changes in the network [5]. However, such an approach requires the exchange of state information between the source end system and the network as it is the case for the available bit rate service of ATM [17] or between the sender and the receivers as its is the case for TCP [23] and the scheme presented here. As these state information have to traverse at least a part of the network, the source will not be able to change its sending rate immediately after a change in the


2

congestion state of the network. In Sec. 2, we present a new scheme called the loss based adjustment algorithm (LBA) for adapting the transmission rate of multimedia applications to the congestion level of the network. The LBA scheme is an enhancement of a scheme that we previously presented in [18]. In Sec. 3, we test the performance of the scheme in terms of bandwidth utilization. Fairness aspects and interoperability of the scheme with TCP are presented in Sec. 4 and Sec. 5.

2 The Loss Based Adjustment Algorithm (LBA) The loss based adjustment algorithm is based upon the Real Time transport Protocol (RTP) [16] designed within the Internet Engineering Task Force (IETF). Note that RTP is not a transport protocol in the common sense. That is, it offers no reliability mechanisms, has no notion of a connection and is usually implemented as part of the application and not the operating system kernel. Instead, RTP offers the application the capability of distinguishing between different media streams and keeping track of various statistics describing the quality of the session as seen by other members of the session. RTP sessions consist of two lower-layer data streams, namely a data stream for, say, audio or video and a stream of control packets (RTCP). Using the control protocol (RTCP), each session member periodically multicasts control packets to all other session members. The control packets contain information about the received and transmitted data rates, delay jitter and packet losses. The desire for up-to-date control information has to be balanced against the desire to limit control traffic to a small percentage of data traffic even with sessions


3

consisting of several hundred members. Therefore, the control traffic is scaled with the data traffic so that it makes up a certain percentage of the data rate (usually 5% ). This design implies that the number of RTCP packets sent by all members of a session should stay constant for sessions of different sizes. However, as the minimum interval between two RTCP packets is limited to 5 seconds, it is possible that a certain number of members does not consume all the bandwidth available for RTCP. Hence, increasing the number of members results in an increase in the number of RTCP packets sent. Actually, the scaling schemes of RTCP start showing effect only for sessions with a higher number of members than a scaling threshold

thscale ) approximately specified as follows:

(

thscale =

min. Interval BRTCP RTCP Packet size

(1)

with the minimum interval set to 5 seconds and BRTCP as the bandwidth dedicated for RTCP. Detailed analysis of this issue can be found in [8]. During a conferencing session each receiver reports in its control packets the percentage of lost data noticed since sending the last control packet. At the sender site, the RTCP packets are processed and depending on the loss values reported within the RTCP packets, the sender can increase, decrease or keep its current sending rate, see Figure 1. The decision of how to change the sending rate is taken according to the following rules:

A source starts sending data with a pre-defined rate

Initially, the sender is in the non-congested state. During this state the sender increases its transmission rate additively with a pre-defined additive increase


4

factor (AIF) divided by (min [members; thscale ]) for each received RTCP message indicating losses below a pre-defined loss threshold (lossth ). The number of members is determined through the RTCP protocol and the scaling threshold (thscale ) can be calculated as in Eqn. 1. rate

=

sending rate + AIF m

When receiving a control message with loss ratio

(2)

lossth , the sender goes

into the congested state and the sending rate is reduced as follows: rate = sending rate (1 ? loss ratio + lossth )

(3)

the identity of the member reporting this loss is noted as the losing member and the reported loss value is saved as highest loss.

After entering the congested state, the sender waits for one of the following cases: – Until another RTCP packet from the receiver, who reported the loss is received. Depending on the loss report of the new RTCP packet the sender either goes into the non-congested state or reenters the congested state. – Control messages received from members other than the losing member with loss values higher than the highest loss lead to an additional rate reduction as follows: rate = rate (1 ? loss ratio + highest loss)

(4)


5

highest loss is then set to this new loss value and the losing member is set to the identity of the member reporting this new loss. In this case, the sender reenters the congested state. – If neither of the above cases is valid, all RTCP packets are ignored for five seconds, to allow for the reduction to take effect. This time period is approximately the minimum interval between the sending of two consecutive RTCP packets. Additionally, the user can specify a minimum rate threshold below which the sender should not reduce its rate. To prevent rapid changes in the sending rate and accommodate temporal loss peaks the loss ratios used for determining the congestion state and the sending rate should be determined as smoothed ratios and not the actual loss ratios reported in the RTCP packets. That is, for each receiver

i the sender should calculate a

smoothed loss ratio losssmoothed i as follows: losssmoothed i

= (1

? ) loss

smoothed i

+

lossi

with lossi as the loss value reported in the last received RTCP message from member i and is a smoothing factor set to of 0.5. This value was chosen based on the different simulation studies run for the LBA algorithm [18].

3 Measurement of the Performance of the LBA Algorithm To verify the performance of the LBA algorithm we ran a simple experiment over our local ATM network. As Fig. 2 depicts, we connected two workstations over a


6

M = member Ml = losing member L = loss Lh = highest loss R = transmission rate AIF = Additive Increase Factor LT = Loss Threshold NM = number of members

L>Lh

(M!=M l )&&(LLh )

R=R + AIF/NM Lh= 0

R=R

LL h) (M=M l )&&(L