Part III
Applications and Services

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 network)
• 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 patterns.

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 of ways:

• 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 acceptable.

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:

1.

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.

2.

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.