Explicit rate adjustment for multi-rate multicast ... - Semantic Scholar

1 downloads 0 Views 393KB Size Report
of MR-MCC using explicit rate.adjustment based on TCP throughput equation and Packet-pair Probe. The design . goals are: scalability, resporkiveness, fast ...
Explicit Rate Adjustment For Multi-Rate Multicast Congestion Control Using TCP Throughput Equation And Packet-Pair Probe '

Somnuk Puangpronpitag School of Co.mputing . University of Leeds E-mail: [email protected]

~-

.

.

,

Keywords-. Mufti-rate Multicast. Congestion .Control, ns2, Packet-pair probe, TCP-friendliness,TCP throughput equation ,~

I. INTRODUCTION

.T

~

~

1

..,

Absfract-The. Multi-rate Multicast Congestion Control (MR-MCC) scheme has been considered as a suitable scheme for multicasting, for .a very large heterogeneous group of receivers. In.this work, we propose- a new design of MR-MCC using explicit rate.adjustment based on TCP throughput equation and Packet-pair Probe. The design .goals are: scalability, resporkiveness, fast convergence, fairness (including inter-protocol fairness, intra-protocol fairness, intra-session fairness and TCP-friendliness) and feasibility. We have implemented our design into a network simulator (ns2) and undertake a p e r f o y n c e evaluation to investigate it. The results show that our . protocol holds good prope&es of the design goal.

.

Suhaidi Hassan School of Information Technology Universiti Utara Malaysia E-mail: [email protected]

.

'

HERE are two directions of mul;icast congestion control

our new MR-MCC protocol are proposed in Section V. Section VI shows the performance evaluation of our protocol using a network simulator (ns2). Finally, in Section VII, the conclusions of this work are given. 11. BACKGROUND A. Layered Encoding

Layered Encoding was first proposed in [ 121. It is based on the ability of a sender to generate the same data at different rates over^ multiple multicast streams. The sender organizes multiple multicast groups into logical layers. For multimedia applications, the encoding is done in such a way that each layer has the same. content, but with an increase in quality. The base layer contains the obligatory data for decoding, and the extended layers provide more information. This information, when combined with the base layer's data, results in improved quality. The more layers subscribed, the more bandwidth is consumed, and the better quality received. For reliable delivery applications, each. layer is encoded using Forward Error Correction (FEC) to provide reliability for data transport. The details can be found in [lo]. The base layer provides the crucial data for decoding, while the extended layers provide the increased rates to reduce the overall transfer time. The more layers subscribed, the morc bandwidth is consumed, and the qdcker the transfer rate.

schemes proposed so fa?, namely Single-rate Multicast Congestion Control (SR-MCC). and Multi-rate, Multicast Congestion Control (MR-MCC).To achieve the scalability for a ye& large. heterogeneous group of receivers over the Intemet, MR-MCC is a better choice as giving,more flexibility in ahocating of bandwidth along different network paths. Recently, several studies (such as-[121, [l?],[Z], [16]) have focused on the design of MR-MCC protocols: However, all of B. TCP-friendliness them have some: drawbacks. Some designs cause overMore than 90% of today's Internet trafic is TCP-based [6] subscription and high packet losses. Some are slow convergent To protect this majority population from aggressive traffic, t k -~ and unresponsive. Some are TCP-unfriendly. Some designs Internet community [5] suggests that new congestion contrc are too complex and infeasible: mechanisms for traffic likely to compete with best-effort TC: Hence; in this paper, we propose a new design of MR- traffic should be TCP-friendly. MCC, which has -the following properties: scalability, TCP-friendliness is actually. the inter-protocol fairnea: responsiveness, fast-convergence, TCP-friendliness, efficiency towards TCP. The TCP-friendliness definition [I I] demand: in 'network utilization, and simplicity to implement. Our that a TCP flow and a non-TCP flow should receive simildesign is based on an estimation of an explicit target rate using steady-state bandwidth shares, if they traverse the same paii a Packet-pair Probe (PP) and TCP throughput equation. and thus face similar round trip delays and packet loss rates. Combining this estimation technique with ,the receiver-driven layered multicast approach and our new framework for the 111. DESIGN GOALS AND PRINCIPLES . cooperation 'between the sender and the receiver, we .. A. Design Goals conhibute a new MR-MCC protocol, called Explicit Rate Our goal is to create a layered muiticast congestion contrc ~' 'Adjustment (ERA). The reqinder of~thispaper .is organized as follows. We protocol that has the following properties: begin in Section 11 discussing some related background. In Scalability: The IP Multicasting model provided by RFC . Section 111, we describe our design goals and principles. 11 12 [4] is largely scalable as a sender can send data to . .' Section IV explains the environmental requirements and nearly unlimited number of receivers. Therefore, the transpo~ assumptions of oUr protocol. The framework and algorithms of protocol should be designed carefully to avoid sevti 0-7803-8114-9/03/$17.00 02003 IEEE: 797 '

~

'

,

--.~

i

~

scalability degradation. in particular, our design avoids feedbacks from the receivers back to the sender or any messages between rcccivcrs, which may ' cause scidability problems. Responsiveness: A good protocol should be able to detect congestion signals quickly and reduce its transmission rate before causing congestion collapse. Instead of fixing congestion after packet lost, our protocol adjusts the rate according to the available bandwidth and the TCP friendly rate, which is explicitly measured. So, it can react to the congestion at the incipient state. On the other hands, if the bandwidth becomes more available, our protocol can quickly detect this availability and utilize it efficiently. Inter-protocol fairness (particularly TCP-friendliness): When several connections of different protocols compete for bandwidth, they should be able to share it fairly. In particular, TCP-friendliness paradigm forces that the new congestion control mechanisms should maintain fairness towards TCP. To maintain the fairness towards TCP, we calculate the explicit rate using TCP throughput equation. Intra-session fairness and the coordination of downstream receivers: Intra-session fairness is fairness among the receivers of the same multicast session, and the coordination of downstream receivers is necessary to obtain the intrasession fairness. As revealed in [12], the co-ordination among receivers behind the same router is significant for MR-MCC. Uncoordinated subscription can cause inefficiency of bandwidth utilization, and uncoordinated unsubscription can zause congestion persistence. Our protocol provides the ;oordination by relying on Session Announcement Message :SAM) and Rate Adaptation Interval (MI)(details in3ection V). According to our algorithms, if the receivers are under the e bottleneck link, and traverse the same path, they would w e the same target rate from the estimation of the available randwidth and TCP throughput rate. :igh network utilization: When the network bandwidth necomes available, 'our protocol can quickly detect the wailable bandwidth and subscribe to more layers. .ow Packet Loss Rate (PLR): Packet loss.is a waste of mdwidth and can lead to the quality of service degradation. *iccordingto [I], the effect of PLR on multimedia applications such as MPEG video sent over the Internet) can he huge. It mas been shown that a PLR of 3% can cause 30% of a video kaam to be unusable. So, low PLR is one of our goals. Our cotocol uses an explicit rate adjustment, which handles the mdwidth consumption according to the available bandwidth nd the TCP friendly rate. By this technique, we cause very JWPLR. 'easibility: The mechanism used~in the design must be not aly efficient but also feasible to implement. Compared our :sign with other MR-MCC algorithms, ours is one of the nost simple and very feasible. while 'having all mentioned sod properties. B. Key Concepts To achieve the goals, we use the following key concepts to :sign and implement our protocols.

Layered coding and receiver-driven approaches: We base our protocols on these approaches to provide scalability for a very large heterogeneous group of receivers. Explicit rate notification: We believe that finding a simple mechanism for explicit rate notification would simplify the congestion control problem. In our algorithms, the suitable target rate is calculated by estimating 'the available bandwidth and the TCP friendly rate. By adapting the reception rate to . the estimated available bandwidth, our protocol would be able to utilize bandwidth efficiently, and cause no congestion and no packet loss from over-utilizing bandwidth: Furthermore, when congestion is detected (by packet' losses),. our target reception rate considers the TCP-friendly rate, which would make our protocol TCP friendly. This explicit rate scheme also makes our protocol fast convergent and responsive:The details of estimating the.,available bandwidth and the TCP friendly rate are described in Section V.

IV. ENVIRONMENTALREQUIREMENTS AND ASSUMPTIONS Our congestion control algorithms assume the following environment: Best Effort Service: An underlying network or transport service is a Best Effort service, which guarantees neither the packet delivery nor the quality of service. Multicast Support: The multicast support at the network layer is required. Unknown Network Topology: We assume no knowledge of the underlying physical network topology. Group Membership Management: Our congestion control algorithms use an implicit group management model and assume no knowledge of group member. This matches the way IP multicast model handles group membership and has better scalability properties than explicit group management. Single Data Source: We assume a one-to-many midticast transmission. All data are sent from a .single source. Congestion control is done per. source. However, multiple data sources can be supported by running multiple instances of our protocol. Target Applications: Our protocol is designed to 'support both reliable multicast applications (e.g. bulk file transfer) a i d multimedia applications (e.g. audiolvideo broadcasting).

v.

FRAMEWORK AM).

&cams

A. Sender Operation The sender has the responsibility to encode the data into multiple layers using the layered encoding approach. Then, the encoded data packets of each layer are sent as a pair to the receivers. This packet-pair will be used in order to istimate the available bandwidth later on. 1 ) Header Format The header format of each packet is shown in Table l.'OID identifies which object the packet contains data for. LID identifies' which layer the packet is a part of. PSN is used in order to detect packet losses. SCT indicates the time,when the packet is sent from the sender, and FPF indicates the first packet of the packet-pair.

798

Table 1: Packet header format

Name OID

'

,I

.I

Description Object Identifier

layers' ( i ) maintained at the receiver, and a data ra'te of each layer obtained from the session description. 4. The receiver estimates the target reception rate (RTARGm)

.

1

^^

LII,....".

a> I V L I V W D .

If (1 > 0) Then If (Rpp? 0 ) Then Sender Current Time

Set RTARG~= Min(RTcp,R p p1

Else If (R,

= -1)

Then

Set R T A R G'RTCP ~

2) Session Announcement Message. For every predefined Announcing Time (taniounce); the sender

EndIf Else . . , .

., .

advertises a Session Announcement Message (SAM) to the Set R T A R G=~RPP receivers. SAM provides a session description with the End if. following information: data rate of each layer, number of layers, IP address of the sender, IP address and port number of- 5. . The receiver subscribes to and unsubscribes from layers according to the RTARGm as follows: each layer, packet size, object. length and Rate Adaptation If (Ri > Rrmcm) Then . Interval (RAI). Repeat Until (Ri 5 RTARGm) 3) k y e r Organization I f i > 0 Then The layer organization is cumulative i.e.; all Unsubscribe'from a layer , receivers must subscribe to or unsubscribe from ,i = i -1

layers in a consecutive order. If Lj denotes the data rate of layerj, the cumulative rate (R;)of a receiver, which subscribes to layer i, can be calculated as:

Else EXIT the session EndIf' LOOP

(1) '

, B . Receiver Operation .; . The receiver must receive a SAM and interpret the session description before joining a session. After joining a session; the receiver has a role to decode and obtain the necessary data packets to reproduce thd object, Congestion control is also the receiver's responsibility: On entering a session, the receiver,immediately subscribes to the base- layer. Then, -the receiver tunes its reception rate according to the network condition by subxribing t o and unsubscribing from additional layers.' : '

.

.

C.. Rate Adaptation Scheme

For every arrival of packet-pair, the receiver estimates the mentioned in available bandwidth (R,) using the Section D. If the subscribed. rate is higher *an R,, ,the receiver will immediately adapi its reception rate down to avoid overloading the network. If the current subscribed rate is not higher than Rip, thk receiver will adapt its reception rate to the network conditions every RAI. For every "1, the rate adaptation algorithms can be described as follows: 1. The receiyer,calculates an estimated bandwidth Rppas the minimum R , during the last RAI. There may be a pathological case, when p3cket pairs are lost d*ng severe congestion. Then, we may not have enough R', to .&e a good estimation of avsiiabie bandwidth (R,). In this case, we set Rppto -1,to indicate severe.congestion. 2. The receiver calculates Packet ,Loss Rate (lJ, Round Trip . ~. Time (tRrJ and @e TCP-JCyieidly Rate (RTcp)using the techniques mehoned in Section E.G. 3. The receiver ialculates its current subscribed rate (Ri) using Eq: '(1) with'respect to the number of subsciibed

Else If (Ri < RTARGm) Do While (Ri+,

Suggest Documents