Up: Internetworking Multimedia
In the preceding chapters, we have presented a number of aspects of
the Internet that have evolved to permit multicast multimedia
applications. in particular, we can identify certain functons of the
internet that have made this evolution quite rapid and effective.
No Circuits Thank You - the use of packet switching allows efficient
multiplexing. The fact that these packets contain both source
and destination (possibly group) address allows efficient
distribution of control.
Scaling - Aggregation of Flow Information
RSVP allows for policy free allocation of resources. Where
fine grain allocation is needed it is possible, but where a best
effort (or other emerging default Internet Packet Delivery Service) is
sufficient, it can be used for large aggregations of flows.
Multicast encourages distribution of control functionality to the edges
of the network, where the edge system is a computer, and is more
flexibly programable i nany case. Ths makes deployment of new services
much more feasible than an approach which rests on Intermediate Nodes
(e.g. smart MCUs or other application level devices within the
Soft State and Receiver Reservation are based on a notion of
optimism about resource availability - essentially, the average case
behaviousr is most common, and it is that ``calls'' (or sessions or
flows) are typically not blocked. Thus we should only icur expensive,
and delay-ridden round-trip-time exchanges of call-control or
signaling messages, when we really have to!
Based on all the above, the idea that a large scale system is always
consistent is clearly not achievable, and given the principles
described here (really a logical extension of the Clark End-to-End
principles), we shoudl design distributed applications for
Convergent State and Convergent Consensus. For multiemdia applications
with human users, this is particularly attractive because of humans
tolerance for temproary inconsistencyt in many application usage
Multicast is a very powerful building block. It has led to the
evolution of a whole new way of constructing protocols, based around
the paradigm shift 7.5 from
sender based protocol design, to receiver based protocols.
The idea of receiver based protocols has now been applied in a number
The basic multicast join mechanism is receiver based (IGMP joins do
not involve sources ever).
The Internet Resource Reservation protocol is receiver based.
Receiver based adaption to congestion has been described by Steve
McCanne, using multiple IP multicast groups, and layered coded video
with different layers send on different addresses. COngestion
avoidance is achieved as with TCP, by a control loop based on perceived
loss, but without the closed loop feedback needed by TCP - receivers
simply monitor loss for each level ,and leave the associated group if
congestion is causing to high packet loss,
and carry out join experiments to probe whetehr they can start to
receive more layers on other groups as loss reduces on existing ones.
Receiver driven repair protocols such as that in the scalable reliable
multicast protocol used in the LBL Whiteboard application, and
a similar one in NTE, are seen has having very general application.
it is not yet clear, but if unicast is just a special case of
multicast, it may be the case that the receiver driven approach is
appropriate to all types of communication protocol.
The Mbone and the multicast multimedia applications have seen
deployment without any formal resource reservation system. It is
now believed by not a few researchers that a formal resource
reservation protocol per se, may never be necessary - a subscription
based approach, combined with measurement based admission control and
queueing in routers that provides simple priority for interactive
(e.g. audio and web browsing) traffic may be sufficient, and
sufficiently less complex in management terms that the
underutilisation that this might imply for the network designer may be
When we discussed the Mbone conference control and media delivery models, one of the claims made was
that they scaled well for systems with large numbers of participants over very large networks, In the face of
partial failures. Of course, this means that there are (at least temporary) inconsistencies that may be
perceived by users. Luckily, humans (unlike bank managers) are quite capable of holding inconsistent
views temporarily, and waiting for conflicts to resolve, so this is not necessarily a show stopper.
Unreliability and Human Tolerance work surpassingly well in the experience of many Mbone users.
Ordering and Human Frailty may be a problem for some classes of user, though. For example, a distributed
auction system would not be feasible using a scheme that did not constrain bids (and video/audio from
bidders) in the correct order. In a large scale system, it may be that this is only achievable at a very large
cost. There has been quite a bit of research on reliable, and on ordered reliable delivery multicast protocols,
and the work at Cornell on Isis and Horus is particularly relevant. The most recent transport level work is t
hat at Berkeley for NASA, and we have a brief look at that next.
The Reliable Multicast Protocol is a multiservice protocol with the goal of supporting a range of services
on top of the Internet Mbone delivery service. RMP supports various types of ordering, and organizes
participants into virtual topologies to achieve levels of reliability. It remains to be seen whether a single
protocol can carry out the very broad range of services that we have so far outlined.
An often expressed concern about the Mbone open channel model of conferencing is that it is not secure.
This is in fact simply not the case. Privacy and authentication are end to end functions, and whether media
and media control are unicast or multicast is not relevant [Ballardie, 95]. There are only a couple of
consequences of the fact that Mbone conferencing uses multicast:
- Since this encourages multi-way videoconferencing, there is a greater need for Multiparty Key
Distribution. Typically, this means that an asymmetric key system is needed such as PKC based on
RSA or PGP.
- Traffic analysis and denial of service, two threats to security which are often overlooked, are
potentially easier with a multicast network. It transpires that the very techniques used to provide better
resource guarantees (RSVP and Integrated Service IP routers) can prevent the denial of service attack.
Traffic analysis may be a little harder to prevent in a multi-provider Internet. Generally, it may be that
sites will use random traffic from other sources, and perhaps route their traffic so it appears to source
from different entry points to the net (perhaps different RPs or Cores in the multicast routing system),
to avoid analysis. It remains to be seen if this is a serious threat.
Up: Internetworking Multimedia