Docstoc

IP Multicast

Document Sample
IP Multicast Powered By Docstoc
					                              Congestion Control in IP Multicast
                                                      Sumitha Bhandarkar
                                               Department of Electrical Engineering
                                                     Texas A&M University
                                                      College Station, TX
                                                     Sumitha@cs.tamu.edu

ABSTRACT                                                                receivers, resulting in a possibility of “ack
IP Multicast has been proposed as a bandwidth-conserving
                                                                        implosion”. NACK based schemes on the other hand
solution for data transmission to several receivers                     do not provide fast enough response to alleviate the
simultaneously, over the internet. However, its implementation          congestion. Above all, the concept of “fairness” is
has been hindered by issues related to scalability, difficulty of       not even well defined in a multicasting environment.
providing congestion control, lack of suitable pricing models
and difficulty of incorporating security. In this paper we take a       The rest of the paper is organized as follows. In
look at the some of the multicast architectures and protocols,          section 2, we first look at the different architectures
discuss issues related to fairness in the context of multicasting       proposed for multicast implementation on the
and take a look at some proposed congestion control algorithms.
                                                                        internet. We then discuss some of the work on
1. INTRODUCTION                                                         “fairness” issues regarding multicast, followed by
Content can be distributed over the internet in                         the different proposals for congestion control
several different ways namely unicasting,                               schemes. In section 3, we have a brief discussion
broadcasting or multicasting. Different applications                    where we examine the limitations of these schemes.
benefit from using different models of data delivery.                   2. RELATED WORK
For applications like video conferencing, distance
                                                                        Three different architectures for implementing
learning, real-time event transmissions etc., in
                                                                        multicast on the internet are presented in [1], [2] and
particular, multicasting provides an elegant and
                                                                        [6]. The PIM-SM architecture presented in [1]
efficient solution.
                                                                        provides predefined rendezvous points (RPs) for
In multicasting, the source sends the data to a special                 each multicast group, so the cost of constructing a
kind of IP address called the multicast address                         distribution tree is reduced in a wide area network.
(Class D address space of the hierarchical address                      Once a packet delivery path is established between
model). All the receivers that are interested in                        the sender and the receiver via the RPs, the first hop
receiving this data can do so by informing the                          router of the receiver can decide whether to continue
routers that they would like to “join” the multicast                    in the group shared tree, or switch to the
group with this address. The multicast enabled                          conventional source-specific shortest path tree. The
routers in the network maintain the distributed trees                   Receiver Driven Layered Multicast (RLM)
and take care of forwarding packets to the receivers.                   architecture presented in [2] on the other hand, takes
The Internet Group Management Protocol (IGMP) is                        into account that media content can be encoded and
used to establish group membership of different                         transmitted in separate layers of different qualities.
receivers dynamically, so that the receiver can join                    The receivers probe the network to converge on the
or leave one or multiple groups as and when they                        best quality it can receive by conducting “join
need.                                                                   experiments”, on different layers. A completely
The basic architecture for multicasting allows data to                  different approach called EXPlicitly REquested
be transmitted at a single rate, irrespective of the                    Single Source (EXPRESS) multicast was provided
receiver or the application characteristics. Several                    in [6], which focused on making it possible to
different architectures have been proposed to extend                    implement a pricing model for multicast. In this
this mode. However, none of them provide any                            model, multicast “channels” identified by both the
implicit mechanism for responding to congestion.                        sender‟s source address and the channel destination
Conventional      ack-based     congestion    control                   address replaces the conventional concept of
algorithms cannot be readily implemented in a                           multicast “groups” identified by only the destination
multicasting environment because the multicast                          address. The single source model ensures that the
environment consist of one sender but several                           receivers receive data from only the source it is


                                                                    1
subscribed to, while the ECMP (EXPRESS Control               timers tipped in favor of the receiver with low rates,
Message Protocol) maintained count of the receivers          this rate is fed back to the sender. If the rate
makes it is easier for the ISPs to deploy a pricing          feedback is less than the current rate, the sender
model.                                                       reduces its rate to the new rate, and multicasts the
                                                             new rate to all the receivers. Feedback suppression is
None of the above mentioned architectures provide
                                                             achieved by ensuring that the receivers send the
any explicit support for congestion control. A
                                                             feedback only if their calculated rate is less than the
problem that hinders the design of source-based
                                                             current sending rate and their random timer expires.
congestion control algorithms for these architectures,
                                                             Since the rate calculation depends directly on the
is the Loss Path Multiplicity (LPM), which was
                                                             RTT, this protocol is very sensitive to the accuracy
studied in depth in [5]. As the number of receivers
                                                             of the RTT estimation. Complicated scheme
increase in a multicast group the probability that the
                                                             requiring clock synchronization is presented in the
source receives at least one loss indication (LI) per
                                                             paper, which could be a bone of contention if the
packet increases. The authors term this problem as
                                                             scheme is to be implemented on the global internet.
LPM. The authors study this problem by considering
a family of AIMD protocols, in which the source              PGMCC (Pragmatic General Multicast Congestion
responds to only some of the LIs. The key                    Control) on the other hand is a less complicated ack-
components of such algorithms are the Loss                   based TCP-like congestion control algorithm. By
Indication Filter (LIF) and the Rate Adjustment              monitoring the NAK reports sent by the receivers,
Algorithm. The authors consider specific cases for           the sender chooses the receiver along the path with
the LIF policies and show that Pass-Worst filtering          highest end-to-end loss as the representative “acker”.
algorithm, where LIs from only the receiver with the         The “acker” sends positive acks for each packet
highest end-to-end loss is considered ensures max-           received, based on which a window based
min fairness.                                                congestion control scheme similar to TCP is
                                                             implemented at the sender. The acker oscillation is
The question regarding “fairness” still remains -
                                                             reduced by modifying the acker only if the
should the bandwidth of a multicast session be the
                                                             throughput calculated for some other receiver is
same as that of a single session of TCP or should it
                                                             below a certain threshold „c‟ of the throughput for
be larger since it caters to larger number of
                                                             the current acker. Guidelines based on experimental
receivers? Reasoning along these lines was carried
                                                             results are provided for the choice of „c‟. Since the
out in the paper [4], and the concept of “essentially
                                                             congestion control algorithm is window based and
fair” was introduced. A multicast session is
                                                             not rate based, the calculation of RTT is not too
“essentially fair” if its throughput is bounded by
                                                             critical and coarse estimation is sufficient.
some multiples (a,b) of the tcp throughput, such that
a  b < N, where N is the total number of receivers.         The congestion control schemes studied so far have
An algorithm called Random Listening Algorithm               been for the single rate multicast architecture. The
(RLA) was designed which closely follows the TCP             problem becomes substantially more complicated for
SACK implementation but reacts randomly to                   layered multicast architecture. A study based on the
congestion signal from any of the receivers. Based           impact of multicast layering on network fairness was
on analysis and simulation, it was shown that RLA            presented in [7]. Based on analytical models
does satisfy the conditions for bounded fairness.            theoretical results are provided for multicast utility-
                                                             based max-min fairness allocation, and it is shown
Several congestion control algorithms have been
                                                             that this allocation can be achieved through
proposed for single rate multicast implementation.
                                                             coordinated joins and leaves of multicast groups. In
Two significant ones are TFMCC [9] and PGMCC
                                                             the absence of coordination of joins and leaves, it is
[8], which use the Pass-Worst filter mentioned in
                                                             shown that there could be over-utilization of links
[5]. TFMCC (TCP-Friendly Multicast Congestion
                                                             leading to a high level of unfairness. A congestion
Control) is a multicast extension of the equation
                                                             control scheme for layered multicast architecture
based congestion control scheme for unicast called
                                                             similar to the coordinated scheme mentioned in the
TFRC. In TFMCC, the receivers estimate their RTT
                                                             above paper was presented in [3], where the sender
and the loss rate, using which they compute the rate
                                                             sends specially flagged packets in the data stream
at which they must be receiving data. Using random
                                                             called synchronization points (SPs). The receivers


                                                         2
conduct join experiments only immediately after an            Several different schemes proposed for providing
SP and base the decision to retain the layer or drop it       congestion control for multicast applications have
only on the events since the previous SP.                     been studied in this paper. Even though each of these
Additionally, since congestion may continue owing             protocols is based on a sound idea, they lack some
to the latency in the completion of the leave process,        quality or the other that prevents them from being
a deaf period is introduced after a leave is initiated        adopted as a global standard. In this section, we take
and during this period the receivers do not respond           a brief look at the limitations of these schemes.
to further losses. Another scheme for multi-layered           Consider first the layered multicast schemes.
congestion control called “Wave and Equation                  Receivers‟ add/drop layers based on congestion they
Based Rate Control” (WEBRC) is presented in [10],             experience. Even though this could result in a high
where the novel concept of multicast round trip time          level of intra-protocol fairness, inter-protocol
(MRTT) and transmitting data in waves is                      fairness when compared to TCP cannot be achieved.
introduced. The basic transmission layer consists of          This fact has been clearly stated in [2]. Even with
the basic rate, to which all the receivers subscribe.         additional restrictions imposed in [3], multicast is
The additional layers consist of equally spaced               shown to be more aggressive than TCP. This is to be
waves where the transmission rate increases quickly           expected, because on congestion, TCP increases the
to a peak and then decays smoothly to zero. The               congestion window (and hence the sending rate)
different wave layers start at fixed timeslot, the            linearly, but in case of multicasting a new layer is
information of which is embedded in the basic layer.          added which results in an abrupt increase in the rate,
The receivers compute the MRTT as the time                    effectively making the protocol behave in a
difference between a join request and receiving the           multiplicative     increase/multiplicative    decrease
first packet from that layer. Using this MRTT the             manner.
receivers compute their fair rate using the TCP
                                                              Of the single rate multicast congestion control
control equation. They then obtain the information
                                                              schemes, the primary ones TFMCC[9] and
corresponding to the wave layer transmitting at this
                                                              PGMCC[8], inherently suffer the problem of
rate from the base layer, and join that layer,
                                                              delivering data at the rate of the slowest receiver,
switching between different layers to maintain the
                                                              irrespective of the capacity of the other receivers or
TCP-friendly rate.
                                                              links on the network. Suppose a conservative
In order to ensure fault tolerance and provide service        approach was adopted and it was decided that the
at consistent quality, most service providers resort to       max-min fairness norm across all receivers was
server replication techniques, where several sources          adopted as a standard for multicast fairness. Even
can provide the same service, and the receivers can           then, the two schemes could not be approved for
choose the “best” source server based on any                  global deployment. TFMCC relies heavily upon
number of criteria. The process by which a receiver           accurate estimation of RTT for rate calculation, and
chooses one of the sources is called anycasting.              since this is done at the receivers, it results in a very
Since most multicasting applications could take               elaborate set up. Clock synchronization is used for
advantage of this scheme, it is briefly discussed here.       obtaining initial RTT estimate and then messages are
At the network level anycasting would require a               exchanged between receiver and sender to update
separate class of address called the anycast address          this value, an overhead, which could not be tolerable
space. On the other hand, implementation of                   in large multicast groups or sparse mode multicast.
anycasting at the application level is reasonably             PGMCC seems like an ideal candidate, but the acker
simpler. One such approach is provided in [11],               selection process still requires the sender to process
where instead of separate anycast addresses, the              the nak reports, estimate RTT and compute
group of anycast sources is identified by Anycast             throughput. This could put a lot of load on the
Domain Names (ADNs). Using a DNS-like query                   sender if the number of receivers becomes very
response, the address of the source is obtained by an         large. A simpler approach would be for the sender to
application level service.                                    estimate a smoothed RTT just like TCP, based on
                                                              acks from the current acker. Then the receiver that
                                                              sent maximum number of unique naks in one
3. DISCUSSION
                                                              smoothed RTT could be chosen as the next acker. To



                                                          3
avoid spurious changes, weighted history (like
EWMA proposed in TFRC) could be taken into
account. Also, the choice of acker can be tipped in
favor of current acker by using a threshold exactly as
mentioned in the paper. Using efficient data
structures, this could be implemented lot more easily
than the original scheme.
So, as we see, currently proposed schemes for
congestion control need further enhancements and
improvisations before any wide-scale deployment on
the internet. Similar problems are found in the area
of security and pricing for large multicast
applications. This offsets the benefits of using
multicast over unicast, making it a less favorable
model for data delivery at the ISPs.

4. REFERENCES
[1]  S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C-G. Liu, L. Wei,
     “An Architecture for Wide-Area Multicast Routing,” ACM
     SIGCOMM, 1994.
[2] S. McCanne, V. Jacobson, and M. Vetterli, “Receiver-Driven
     Layered Multicast,” ACM SIGCOMM, 1996.
[3] L. Vicisano, J. Crowcroft, and L. Rizzo, “TCP-Like Congestion
     Control for Layered Multicast Data Transfer,” IEEE INFOCOM,
     1998.
[4] H. W. Wang and M. Schwartz, “Achieving Bounded Fairness for
     Multicast and TCP Traffic in the Internet,” ACM SIGCOMM,
     1998.
[5] S. Bhattacharyya, D. Towsley, and J. Kurose, “The Loss Path
     Multiplicity Problem in Multicast Congestion Control,” IEEE
     INFOCOM, 1999.
[6] H. Holbrook and D.R. Cheriton, “IP Multicast Channels:
     EXPRESS Support for Large-Scale Single-Source Applications,”
     ACM SIGCOMM, 1999.
[7] D. Rubenstein, J. Kurose, and D. Towsley, “The Impact of
     Multicast Layering on Network Fairness,” ACM SIGCOMM,
     1999.
[8] L. Rizzo, “pgmcc: A TCP-Friendly Single-Rate Multicast
     Congestion Control Scheme,” ACM SIGCOMM, 2000.
[9] J. Widmer and M. Handley, “Extending Equation-Based
     Congestion Control to Multicast Applications,” ACM SIGCOMM,
     2001.
[10] M. Luby, V.K. Goyal, S. Skaria, and G.B. Horn, “Wave and
     Equation Based Rate Control Using Multicast Round Trip Time,”
     ACM SIGCOMM, 2002.
[11] S. Bhattacharjee, M. Ammar, E. Zegura, V. Shah, and Z. Fei,
     “Application-Layer Anycasting,” IEEE INFOCOM, 1997.




                                                                           4

				
DOCUMENT INFO