Cisco Knowledge Suite Cisco SystemsCisco Press

Cutting Edge
Core Reference
Guided Learning
Networking Architecture
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services

The Cons of IP Multicast


< Back Contents Next >

Introduction to IP Multicast



A Brief History of IP Multicast



The Pros of IP Multicast



The Cons of IP Multicast



Multicast Applications



MBone--The Internet's Multicast Backbone




Save to MyCKS

Developing IP Multicast Networks, Volume I

From: Developing IP Multicast Networks, Volume I
Author: Beau Williamson
Publisher: Cisco Press (53)
More Information

The Cons of IP Multicast

Although there are a number of good reasons for wanting to use IP multicasting in networks, you need to keep in mind that there are limitations and downsides to this technology. These limitations need to be clearly understood, particularly if you are developing new applications that plan to use IP multicasting.

Some of the main drawbacks associated with the implementation of an IP multicast system include unreliable packet delivery, packet duplication, and network congestion.

Unreliable Packet Delivery

IP multicast, like IP unicast, is inherently unreliable. It is only through the use of TCP at Layer 4 (or some other higher layer protocol) that IP unicast data streams can be made reliable. However, because IP multicasting assumes a one-to-many communication mode, it was not designed to use the end-to-end mechanisms inherent in TCP. IP multicast packets typically use the User Datagram Protocol (UDP), which is best-effort in nature. Therefore, an application that uses IP multicasting must expect occasional packet loss and be prepared to either accept the loss or to somehow handle this at the application layer or via a reliable multicast protocol layered on top of UDP.

Dr. Deering states in his doctoral thesis that “during periods when paths are being changed immediately following a topology change, multicast packets that happen to be in flight have a lower probability of reaching their destinations than do unicast packets.” Deering goes on to explain that even if erroneous unicast forwarding information exists at some routers in the network during a topology change, the network may eventually succeed in forwarding the packet to the destination. The reason this happens is that the unicast forwarding mechanism continues to attempt to forward the packet toward the destination IP address while the network topology is in transition, though the actual path may be somewhat circuitous. The forwarding mechanisms of IP multicast, on the other hand, are based on the source IP address, and to prevent loops, the packet is discarded if it does not arrive on the interface that would lead back to the source. The significance of Dr. Deering's point is a subject of some debate, particularly because the impact has not been studied. However, taken at face value, the theory is worth noting.

If the preceding material seems a bit unclear to you at this point, don't worry; Chapter 2 covers these forwarding mechanisms in greater detail. For now, it is sufficient to understand that IP multicast forwarding makes use of the source IP address, while IP unicast forwarding makes use of the destination IP address.

Packet Duplication

Duplicate packets are, just as in the UDP unicast world, a fact of life. However, a key difference between unicast and multicast routing is that routers intentionally send copies of a multicast packet out multiple interfaces. This increases the probability that multiple copies of the multicast packet may arrive at a receiver. For example, in certain redundant network topologies in which multiple paths exist to the receiver, duplicate packets can occur until the multicast routing protocol converges and eliminates the redundant path. Typically, this means that only an occasional packet is duplicated within the network, although under some transient network-error conditions, a number of duplicates may arrive at the receiver. (You'll gain a better understanding of where and when duplicate packets can occur while studying the details of different multicast routing protocols in Chapter 4, “Multimedia Multicast Applications.”) Again, well-designed IP multicast applications should be prepared to detect and handle the arrival of the occasional duplicate packet.


On one particular occasion, I recall a U.S. government agency that had designed an IP multicast application to control a critical piece of government equipment whose malfunction might result in the loss of life. Unfortunately, the application designers had failed to account for the possibility of duplicate packets caused by normal IP multicast network operation. This oversight resulted in the critical control command in the IP multicast packet being executed multiple times.

Imagine the result if such an application were used to command and control a number of tanks on the battlefield: “All tanks turn right 90 degrees,” “All tanks turn right 90 degrees,” “All tanks turn right 90 degrees…”

Network Congestion

In the TCP unicast case, the standard TCP backoff and slow-start window mechanisms automatically adjust the speed of the data transfer and therefore provide a degree of congestion avoidance within the network. Because IP multicasting cannot use TCP (due to its connectionless, one-to-many nature), there is no built-in congestion avoidance mechanism to prevent a multicast stream from exhausting link bandwidth or other critical router resources. Having said that, it is important for you to note that UDP unicast data streams suffer the same congestion avoidance problems! Furthermore, the recent growth in popularity of multimedia audio and video applications both on the Internet and within private intranets is increasing the amount of UDP unicast traffic.

As you learn more about the workings of IP multicasting, you will find that there is no provision to prevent you from joining a multicast group that is sourcing data at a rate that exceeds the total available bandwidth in your portion of the network.

Figure 1-6 shows two IP multicast servers sourcing the same video content. One server sources the program at 500 kbps, intended for use only in the local corporate headquarters network environment, while the other server sources the program at 128 kbps, intended for use by the remote sales offices.

Figure 1-6. Exceeding Network Bandwidth with Multicast Traffic

If a user at a remote sales office joins the 500-kbps multicast group by mistake, the result will be that the 256-kbps circuit to the remote sales office will be completely consumed by the 500-kbps video multicast traffic.

In Chapter 16, you will learn ways to configure the 256-kbps circuit to limit the amount of bandwidth that the multicast traffic can consume. Another alternative is to use administratively scoped boundaries to prevent users in the remote office from joining the 500 kbps group. (Administratively scoped addresses and boundaries are addressed in Chapter 2, “Multicast Basics.”)

With all this in mind, it should be noted that, in all fairness, IP multicast is no worse than many of the common audio/video streaming applications in use today. These applications default to using unicast UDP and not TCP as their delivery mechanism—which means that like applications using IP multicast as a delivery mechanism, they do not use any form of congestion control!


I'm frequently told by network designers that they do not plan to implement IP multicasting on their networks because of the lack of congestion control inherent in IP multicast's UDP-based delivery mechanisms. The real truth of the matter is that their users are probably putting up streaming-video Web servers that supply video clips of departmental training or other similar material using UDP-based, unicast applications that have no more congestion control than IP multicast. On the other hand, IP multicasting could possibly reduce the overall load in the network by sourcing a single multicast video stream instead of multiple unicast streams. (I sometimes refer to this behavior as being slightly podiabombastic; which is the tendency to blow off one's foot.)

The reason that some of these applications don't default to the use of TCP is that the normal retransmission mechanism in TCP provides little value because of the real-time nature of audio. By the time the retransmitted packet arrives, it's too late to be useful in the audio stream. Instead, the application designers would rather pull down the data as fast as the network permits (at the expense of possible network congestion) and not be artificially restricted by the congestion avoidance mechanism built into TCP. In most of these cases, the use of IP multicasting will reduce overall network congestion because a single transmitted data stream can reach all receivers.


In the early days of the MBone, when the primary application was the audio conferencing tool VAT (which, of course, is based on UDP), the common practice in an audio conference was to clear one's throat over the microphone several times before beginning any dialog. This caused the congestion mechanisms of any active TCP streams flowing across potential congestion points in the network to kick in and back off, thereby giving the UDP-based audio conference traffic more bandwidth. I guess you might say that this was the first attempt at a crude form of resource reservation, which was set up via these initial Ahem packets. (The MBone is discussed in more detail later in this chapter.)


< Back Contents Next >

Save to MyCKS


Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.


From the Brains at InformIT


Contact Us


Copyright, Terms & Conditions


Privacy Policy


© Copyright 2000 InformIT. All rights reserved.