Layered Transmission and Caching for the Multicast Session Directory ...

Layered Transmission and Caching for the Multicast Session Directory Service Andrew Swan

Steven McCanne

Lawrence A. Rowe

faswan,mccanne,[email protected]

matically delivers that ow from the source to each receiver along an ecient multicast routing tree. Though this communication model is natural and simple, it brings with it a number of new and dicult research problems that must be addressed to make the approach truly scalable. In this paper, we jointly address two such research problems | session rendezvous and multicast bit-rate adaptation for heterogeneous receivers | and develop interdependent solutions that not only provide good performance for each sub-problem, but taken together, enhance the scalability of light-weight sessions as a whole. The session rendezvous problem arises when a user wishes to join a multicast session in the light-weight sessions framework. Though this model assumes that all users can easily rendezvous by using a common multicast address, they still must each somehow learn that address. To this end, the light-weight sessions architecture includes a completely decentralized session directory service that advertises the bindings of multicast addresses to particular media ows on a well-known bootstrap address according to the Session Announcement Protocol (SAP) [9]. Both SAP and its complementary address allocation algorithms rely upon multicast scope | i.e., a mechanism that constrains the distance multicast datagrams may propagate | to enhance their scalability. By constraining the transmission of announcements to regions of the network that are administratively meaningful (e.g., sessions for U.C. Berkeley classes should be advertised only on our local campus), scalability is enhanced because advertisement bandwidth is reduced and the limited set of available multicast addresses can be re-used across scopes. Once all session members rendezvous with each other through the session directory service, they can freely transmit data to each other through the multicast packet service. But the multicast service provides only simple, best-eort delivery without any form of congestion control to prevent users from overrunning the network. Moreover, users are typically attached to the network at a heterogeneous set of rates. Thus if each source naively transmits at a constant bit-rate, the con icting requirements of a heterogeneous set of receivers cannot be met simultaneously | some paths are inevitably congested while others are underutilized. Unlike multicast congestion control, congestion control for unicast transmission has been extensively studied and re ned, leading to a fairly mature understanding of how end systems can collectively react to dynamic path characteristics to eliminate network congestion by adjusting their sending rate [14]. Multicast, however, is a comparatively recent development and soliciting feedback from an arbitrary number of receivers is dicult to do in a scalable manner.

Abstract The recent advent of the Internet Multicast service has enabled a number of successful real-time multimedia applications, yet the scalability of these applications remains challenged by the inherent heterogeneity of the underlying Internet. One promising approach for taming this heterogeneity is to encode each media ow as a layered signal that is striped across multiple multicast groups, thereby allowing a receiver to tune its individual reception rate by modulating its subscription to multicast groups. Though signi cant progress had been made on media transport protocols and congestion control strategies for adjusting multicast groups in this fashion, comparatively little work has been devoted to extending the session directory service and address allocation architecture to meet the needs and requirements of layered media. Moreover, the large-scale deployment of layered media formats is hindered by the lack of support for layered formats in existing session directory tools. To overcome these limitations, we propose a new architecture for session advertisement and caching that exploits multicast \administrative scope" through protocol proxies to admit layered media formats and reduce the start-up latency of a directory-service client by an order of magnitude or more. Our architecture is fully compatible with the existing directory service allowing our implementation, which is split across a new session directory tool and network proxy, to be incrementally deployed within the current Internet multimedia conferencing architecture. 1 Introduction The Internet Multicast service and its realization in the public Internet | the Multicast Backbone or MBone | form the cornerstone of a new model for multipoint communication called light-weight sessions [15]. In light-weight sessions, a multimedia application disseminates its media ow simply by framing the ow as a sequence of packets and multicasting those packets to a multicast group address. Receivers interested in a certain ow simply join the multicast group corresponding to the ow in question and the network auto-

To appear in ACM Multimedia '98, September 1998, Bristol, UK. 1

Furthermore, because there are multiple paths, which may have dierent characteristics, the sender alone cannot simultaneously meet the con icting demands of dierent receivers. One solution to this problem is proxy-based transcoding, where data streams are individually transformed according to the speci cation of each requesting receiver [7]. Such a solution, however, typically imposes an administrative burden because it is not transparent to end users. Proxies are also dicult to deploy | a user behind a constrained network link might not have access to the optimal point of placement for a proxy. Although the active networks research community aims to solve this problem by oering a common platform for such services as part of the basic network service model [27], numerous research problems must be addressed before such an infrastructure is widely deployed. Furthermore, Fox et al. argue that transcoding proxies must be highly reliable and scalable, which comes at considerable eort and cost [7]. Alternatively, we can avoid proxies with an entirely \endto-end" solution that completely avoids computation within the network through the use of layered media formats. A layered encoding algorithm encodes source data as a series of layers l1 ; l2 ; : : : ; ln . The layers are structured such that a decoder with an ordered subset of the layers (i.e., l1 ; : : : ; li where 1  i  n) can usefully decode that subset even if other layers are absent. In this fashion, the quality of the reconstructed signal increases as more layers are available at the decoder. The lowest layer is called the base layer and higher layers are called enhancement layers. 1 Mb/s

S1 128 kb/s

Figure 2: Receiver Adaptation with multiple sources. The receiver (R), receives trac from two sources, S1 and S2 . R has high-speed connectivity to S2 but not to S1 . Without the ability to prune trac from individual sources, R must subscribe only to the base layer or else high-speed trac from S1 will congest the slow link. With sourcespeci c prunes, R joins the enhancement layer (illustrated with a dashed line) but prunes trac on the enhancement layer from S1 , receiving high-speed trac from S2 without causing congestion on the link from S1 . ered Multicast (RLM) [20]. In RLM, a receiver searches for the optimal number of layers by experimentally joining and leaving multicast groups much as a TCP source searches for the bottleneck transmission rate with the slow-start congestion avoidance algorithm [14]. The receiver adds layers until congestion occurs and backs o to an operating point below this bottleneck. To use RLM, the session directory service must publish a list of multicast groups over which the media sub ows are transmitted. In the current framework, addresses are allocated by the session originator when the session is created. A straightforward approach would be to allocate a block of addresses from the smallest multicast scope that reaches all participants. As illustrated in Figure 2, this approach has the drawback that without the ability to prune individual sources, a receiver in a session with multiple sources must have a single subscription level for all sources. As a result, if a receiver is well connected to some sources and poorly connected to just a single source, the quality of the signal from the well connected sources will be unnecessarily poor. The IP Multicast service model currently does not currently oer such per-source ltering. Though work is underway in the Internet Engineering Task Force to extend the IP Multicast service model to allow per-source ltering [2], it will not be widely deployed for at least several years. Another drawback with simply allocating all addresses from a single scope is that multicast scoping cannot be used to optimize the adaptation process. RLM periodically probes for unused bandwidth (i.e., by increasing the subscription level). Since this probe is disruptive and oers no bene t if the receiver knows a priori that high bandwidth enhancement layers exceed the physical capacity of the connection to a sender, it is pointless to attempt adaptation in such a scenario much as it is pointless for a TCP connection behind a slow modem link to in ate its congestion window beyond that which is reasonably supported by the modem line. To this end, the BSD Unix \route" command provides an administrative mechanism to con gure a path across a well-known bottleneck link with a \pipesize" option. As a result, the TCP does not attempt any adaptation beyond

1 Mb/s

R2 1 Mb/s

512 kb/s

1 Mb/s

R

R1

S

S2

128 kb/s

R3

Figure 1: Receiver-driven Adaptation. The sender, S, sends three layers illustrated by solid, dashed, and dotted lines. Receivers adapt the service they receive by joining and leaving multicast groups. Receiver R1 has high-bandwidth connectivity to S , so it joins all three groups. Although R2 has a high-speed link, its path to S crosses a link that cannot accommodate all three layers so it subscribes to two layers. R3 has a slow link so it subscribes only to the base layer. Layered encoding can be eectively combined with multicast transmission by sending dierent layers on dierent multicast groups. Consequently, a receiver using only the basic IP Multicast service model (i.e., joining and leaving multicast groups) can individually tailor its service to match its capabilities, independently of other receivers. This approach, which was originally proposed by Deering [4], is illustrated in Figure 1. This basic framework was later re ned in a speci c protocol architecture called Receiver-driven Lay2

this limit and thus avoids unnecessary retransmission timeouts leading to much improved performance. Our solution for layered media adaptation follows a similar design principle in that we leverage well-known administrative multicast scopes to limit the degree of adaptation that RLM must perform. To this end, we extend the session directory service with explicit knowledge of multiple multicast groups and thereby allow a ow to span a range of varied multicast scopes. For example, a session originator may choose to allocate addresses from a local administrative scope for high-bandwidth enhancement layers while sending low-bandwidth base layers to a wider scope. Unfortunately, the Internet conference setup architecture does not presently support this style of addressing. In the current architecture, the session originator allocates and announces all addresses for media ows, yet this is at odds with our desire to allocate RLM layers to administrative scopes because a single \session owner" cannot possibly allocate all the necessary locally-scoped addresses in every region of the network. Not only is allocation impossible, but the companion announcement protocol cannot be run because the originator would have no way to inject administratively-scoped trac at every necessary point in the network. To solve these problems, we propose an architecture in which the session originator allocates and announces addresses within its local scope and across the wide area over global scope, and session announcement \agents" in turn allocate and announce local addresses in remote regions. Given that our proposed architecture requires persistent remapping agents in the network, we decided to address another long-standing problem with the current SAP architecture that could bene t from such agents | namely, the large latency associated with priming the session directory cache when a session directory client starts up. That is, we propose to split the session directory service into two pieces: a persistent server that is con gured into the network and runs SAP, and an ephemeral client that contacts the server at any time for a list (or partial list) of available sessions. The client, if it is long lived, may also run SAP after initially contacting the server to avoid future server exchanges. To support incremental deployment that is fully backward compatible with existing directory clients, we developed a variant of the server that re-advertises global SAP announcements at increased rate within a local administrative scope. In either case, the start-up time for session directory applications is decreased often by an order of magnitude or more. Though this split architecture has been discussed previously in the MBone research community [16], the speci c details, until now, had not been worked out, implemented, or developed to the degree presented herein. In this paper, we describe the architecture outlined above and present our research vehicle for exploring this design space: a new session directory tool called nsdr and a session announcement \agent" that implements the underlying architecture. The rest of the paper is organized as follows. Section 2 contains background information about the concepts and protocols discussed later. Section 3 describes sdfor, our implementation of a session announcement \agent". Section 4 discusses how layered sessions are handled in the new architecture. The status of our implementation and planned future work are covered in Section 5.

tom of the protocol stack is IP Multicast, which oers ecient one-to-many data transmission and thus provides the foundation for applications that need to distribute data to many receivers in a scalable manner. The IP Multicast service model, originally proposed by Deering [5], sets aside a range of IP addresses (224.0.0.0 { 239.255.255.255) as multicast addresses. Each address in this range corresponds to a single multicast group. Hosts send a request to join a group to1 a local router which then uses a multicast routing protocol to arrange for all trac to that group to be delivered to the host. A sender transmits a multicast packet by setting the IP destination address of the packet to the appropriate multicast address. Like the unicast IP service model, the IP Multicast service model oers only best-eort service. It does not oer any guarantee that packets will be delivered reliably or that they will not be delayed or reordered; such semantics must be implemented by a higher level protocol. Although developed some time ago, IP Multicast has not yet been deployed across the entire Internet. The portion of the Internet that does support IP Multicast is known as the Internet Multicast Backbone, or MBone. 2.1 Multicast Scoping The IP Multicast service model provides two mechanisms for scoping a transmitted packet so that it stays within a speci c region. When IP Multicast was initially developed, the Time-To-Live (TTL) eld in the IP packet header, which limits the number of hops a packet may take, was the only scoping mechanism. The TTL eld is decremented at every router a packet traverses, and when it reaches zero, the packet is discarded. To impose administrative structure on TTL-de ned scopes, routers can be con gured with a nonzero \TTL threshold". In this case, the packet is dropped when its TTL falls below the threshold. For example, a multicast router at the boundary of an organization might be con gured with a threshold of 32, and thus will not forward multicast trac with a TTL below 32. With common conventions for thresholds (e.g., 32 for organization boundaries), this scheme has been widely used for several years. However, TTL scoping has proven to be in exible (e.g., TTL \scopes" must be nested and cannot overlap) and it interacts poorly with some multicast routing protocols. For these reasons, administrative scoping has been proposed as a replacement for TTL scoping [21]. In administrative scoping, scope boundaries are explicitly de ned by multicast addresses rather than by the TTL eld. A network administrator creates an administratively scoped region by choosing a range of addresses for the scope and con guring all multicast routers at a boundary of the region to drop packets sent to an address that falls within the range. This approach gives network administrators more

exibility in de ning scope regions, as indicated by the topology illustrated in Figure 4. CAIRN is a high-speed network connecting several research sites, including a group within the U.C. Berkeley (UCB) Computer Science department. Since the CAIRN network typically carries high speed traf c and that trac should not be leaked onto the UCB campus network, it is bounded by an administratively scoped region. Simultaneously, a separate administratively scoped region is de ned for the UCB campus. Because several hosts have a high-speed connection to CAIRN yet are also part of

2 Background The protocol architecture that underlies the light-weight sessions conferencing tools is depicted in Figure 3. At the bot-

1 A good introductory explanation of multicast routing is available from the IP Multicast Initiative at http://www.ipmulticast.com/.

3

Conference Setup

Audio/Video

Shared Applications

RTP/RTCP

SRM

SDP SIP TCP

SAP UDP IP/IP Multicast

Figure 3: Protocols that form the Internet Multimedia Collaboration Architecture the UCB campus, the multicast scope regions must overlap. 2.2 Session Announcement Such a scheme cannot be realized with TTL scoping. A great deal of work has gone into the development of proIn addition to providing a mechanism for containing and tocols for multicast distribution of continuous media, cullocalizing high-rate trac, administrative scoping enhances minating in the speci cation of the Real-Time Transport the scalability of multicast routing and addressing since adProtocol (RTP) [25, 24]. Multicast protocols for other apministratively scoped addresses may be spatially re-used. plications (e.g., reliable multicast [6, 17, 26] and its use in For example, the address range 239:192:0:0=14 (i.e., addresses applications [28]) are still the subject of active 239.192.0.0 through 239.195.255.255) is de ned as the organization-collaborative research. local scope. Because a packet transmitted to an address RTP and other protocols under development follow the in this range is not forwarded outside the local organizalight-weight sessions model, in which there is no explicit tion, the same range of addresses can be used within other control of group membership or explicit conference control. organizations without con icts. This spatial re-use of adThis model works well in conjunction with the IP Multidresses enhances the scalability of the multicast routing incast service model; an application joins a session simply by frastructure since routing state for administratively scoped subscribing to the appropriate multicast group. With this addresses need only be maintained locally. approach, however, a mechanism for conference discovery is required so that the application can be given appropriate addresses when it is started. Two mechanisms for conference discovery are invitation and advertisement [10]. In the CAIRN UCB Campus invitation model, a user is explicitly invited by another user 239.140.173.0/24 239.192.0.0/10 to join a session. The Session Initiation Protocol (SIP) provides mechanisms for such invitation as well as user location, negotiation of session parameters, and so forth [12]. This aphost proach works well for small meeting scenarios but is poorly suited to large scale broadcast style events. For the session invitation model to be eective, the inviter must know the (unicast) addresses of all participants to be invited. If the participants are not known beforehand or if there are too many to contact individually, a dierent approach is required. In the session announcement model, which is used in Figure 4: Overlapping administratively scoped zones. the Session Announcement Protocol (SAP) [9], session deSuch a topology is not possible with TTL scoping. Suppose scriptions are periodically multicast to a well-known multithe TTL threshold for the UCB Campus region is t. Then cast group. A session directory tool maintains a list of all the threshold for the CAIRN region would have to be larger session descriptions that have been recently announced via than t or else packets transmitted from the host in the gure SAP. Because the session announcements contain all inforto the CAIRN scope would be dropped at the UCB Cammation needed to launch the actual collaboration tools, the pus boundary (which is not a boundary for CAIRN). On the session directory tool can run the appropriate applications other hand, if the host in the gure tried to send to the UCB when the user selects a program. This frees the user from the Campus scope, the packets would be dropped at the CAIRN cumbersome task of dealing with command line arguments, boundary which is not a boundary for the UCB Campus remulticast addresses, and so forth. gion. With administrative scoping, the host simply allocates When a description is received by a session directory apa multicast address from the appropriate region. plication, a timer is set with a duration several times longer than the interval between announcements. During normal operation, an active session description is continuously refreshed by periodic messages. When a session expires or the application announcing it stops running, the session description eventually times out. 4

Protocols that periodically announce their state at each an announcement interval of 10 minutes or so. Cousource an maintain a cached copy of each state announcepled with unreliable delivery of multicast trac3 , a ment at the receiver are called announce-listen protocols citeschooler- user running a session directory tool often has to wait thesis96. Announce-listen protocols are easy to implement upwards of 10{20 minutes to see a particular session yet are robust since there is no separate or explicit provision announcement. for fault recovery. If a message is dropped by the network,  A user who wishes to announce a session must run it is refreshed by a subsequent transmission, and, if an apan application that implements the SAP protocol and plication crashes, its announcements eventually time out. transmits the session description periodically. If the To ensure that SAP announcements do not consume an session directory tool or the computer it is running arbitrary amount of bandwidth, the aggregate bandwidth on crashes or is restarted, the user must ensure that for all SAP announcements is xed. To send a SAP anthe announcing application is restarted or the session nouncement, an application estimates the total number of description will no longer be announced. announcements and the average size of each announcement. The average interval between transmissions is calculated as To address the rst problem, we have worked out a simfollows: ple scheme, described in the next section, for advertising layered sessions in which layers are transmitted across varinterval = N size ied scopes. Upon creating a layered session, the originator bw can allocate and advertise addresses for all layers within the local scope. However, the originator cannot allocate and adN is the total number of announcements, size is the aververtise addresses for enhancement layers in remote regions, age message size, and bw is the aggregate bandwidth for all as illustrated in Figure 5. In a remote region, only the anSAP announcements. If all sending applications implement nouncement for the base layers is visible. As a result, some this algorithm, the aggregate bandwidth consumed does not entity needs to recognize missing layers and allocate and exceed bw . Receiving applications also calculate the transadvertise addresses for them. For example, in Figure 5, if mission interval and time out an old announcement if is not the receiving hosts (R1 , R2 , and R3 ) want to use local highrefreshed for a period equal to some multiple of the transbandwidth enhancement layers, multicast addresses must be mission interval. allocated and an announcement to supplement A1 must be In the current session directory service, a separate increated. stance of SAP is run in each administratively scoped region. Announcements of sessions that are of interest only in a local area are constrained to an appropriate administratively scoped region by multicasting the advertisement within that scope. This approach greatly enhances the scalA2 ability of SAP and the multicast routing infrastructure. It R1 also allows multicast addresses to be re-used spatially, as described above. Finally, it ensures that hosts receive only announcements for sessions in which they can participate. S R2 Both SAP and SIP require a standard format for deA 1 scribing session parameters. The Session Description Protocol (SDP) de nes a common format that includes media R3 channel descriptions (i.e., media type and format, transport protocol, and network addresses and ports), timing information, and other session description information [11]. SAP and SIP both use SDP for the session description2 . These protocols are implemented in the widely used session direcFigure 5: Layered Session Announcements. Host S cretory application sdr [8]. ates and advertises a session. The base layers are described in the SDP message A1 which is transmitted globally and received by the receiving hosts R1 , R2 , and R3 . The enhance3 A Split Architecture for SAP ment layers are transmitted only within an administrative scope. The addresses for the enhancement layers are deThere are several weaknesses with the current conference scribed in the SDP message A2 which is transmitted within setup architecture: the same administrative scope. A2 is not visible at the receiving hosts since the addresses it includes were allocated  Although SDP has provisions for describing layered within the administratively scoped region and thus are not sessions, it cannot be used to describe layered sessions useful to them. in which all layers are not transmitted within the same scope. Yet, as discussed above, it is often desirable to One solution to this problem would be a distributed altransmit dierent layers within dierent scopes. gorithm that runs in session directory clients in the remote  The bandwidth for SAP announcements sent to the region. For example, in Figure 5, R1 , R2 , and R3 could inglobal MBone is limited to 200 bits per second [9]. voke a distributed algorithm in which one of them would be Assuming 25 global sessions with an average message \elected" to allocate and advertise multicast addresses for size of 500 bytes, the bandwidth constraint leads to the enhancement layers. This approach, however, requires a complex coordination protocol. Furthermore, it may be de2 The decomposition is analogous to HTTP and HTML; SAP and sirable to implement dierent policies to ll-in missing layers SIP are transport protocols and SDP is the payload typically carried by those transport protocols.

3 Many multicast routers implement a simple priority queuing scheme based on UDP port numbers and unfortunately, the default SAP port (9875) falls in to the lowest priority group.

5

3.1 Caching For a session directory tool to take advantage of announcements cached at an agent, a mechanism is needed for the client to query the cache. The rst scheme we implemented was to open a TCP connection from the client to the cache and transmit all changes (i.e., new sessions, session updates, and session timeouts) to the client across the TCP channel. This solution is eective for a small number of clients but does not scale well to an environment with many clients. With many clients, the cache must cope with the overhead of maintaining many simultaneous TCP connections, and bandwidth to the cache is not used eectively as all session updates are transmitted individually to all clients. A more elegant solution is to use the concept of a softstate gateway, introduced by Amir [1]. The soft-state gateway in sdfor is relatively simple; it runs an instance of the SAP protocol on the global SAP session and maintains an up-to-date list of current session descriptions. This list is used as the input to another instance of the SAP protocol that is run within a locally-scoped region where the bandwidth limit is higher than the global limit. That is, every session announcement received on the global SAP channel is re-announced by the gateway within a dierent scope. Since the scope in which announcements are re-announced is smaller, the aggregate SAP bandwidth is higher. As a result, session descriptions are sent more frequently and a client's list of sessions is brought up-to-date quickly. For

example, we set the limit for local SAP announcements to 10 kilobits per second, which for 25 sessions with an average message size of 500 bytes leads to an average interval of 10 seconds between announcements of a single program. More formally, suppose there are N total sessions being announced with an average size of size and the aggregate SAP bandwidth is bw . SAP messages are carried within UDP packets, but UDP oers no guarantee of reliable delivery. As a result, if a session announcement is dropped while a session directory application is in the start-up phase (i.e., has not yet received all active sessions), the application has to wait until the announcement is re-transmitted. Let n denote the expected number of announcements that must be transmitted before a session directory receives every announcement. Assuming an independent packet loss model with loss probability p,

n = 1 N? p

The expected time until a session directory tool receives all announcements is thus: N size t = n size bw = (1 ? p) bw Expected waiting times for a range of bandwidths are shown in Figure 6 for the values N = 30 and size = 500 , and p = 0. Note that the parameter bw used when making the calculation is the local bandwidth plus the global bandwidth (which is xed at 200 b/s) since a receiver listens to both local and global announcements. Even with a modest local SAP bandwidth limit, the start-up time for a session directly client can be reduced by an order of magnitude or more. 12

Expected Start-up Time (mins)

at dierent sites, which would be dicult to do within client applications running on users' desktops. A second approach would use an \agent" that listens to SAP announcements and then allocates and advertises addresses for missing layers when they are detected. This approach has the advantage that extra functionality can be placed in the agent to solve the start-up latency problem described above. We have adopted this second approach and implemented it in a \session directory forwarding agent", or sdfor. This split architecture has been previously proposed but , to the best of our knowledge, has not appeared in the research literature. Moreover, our system is the rst complete design and working implementation. This program is run as a background process and performs the following tasks: Layered Session Completion As described above, the agent listens to all SAP announcements. When a layered session with missing layers is detected, it locally allocates and re-advertises addresses for the missing layers. This task is discussed in greater detail in the next section. Caching As part of the SAP announce-listen protocol, the agent maintains a cache of the sessions currently being advertised. Thus, when a session directly client starts up, it can consult the cache expediently to reduce the waiting time for all announcements to be received. Proxy Announcement A user who wishes to announce a session may con gure his or her session directory tool to contact the agent and have it announce the session on its behalf. As long as the agent process is kept running reliably by a system administrator, the user need not continuously run a session directory tool to ensure that the persistence of the advertisement The remainder of this section describes these tasks in more detail.

10 8 6 4 2 0 0

2000 4000 6000 8000 Local SAP Bandwidth (b/s)

10000

Figure 6: Expected session directory start-up times with a soft-state gateway forwarding announcements at dierent rates. Note that SAP bandwidth of 0 corresponds to no soft-state gateway (i.e., clients receive announcements only on the global SAP channel). To assess the bene ts of the soft-state gateway, we conducted a series of informal experiments to measure how long it takes in practice for a session directory tool to receive a complete list of sessions. During the experiments, the number of active sessions varied between 29 and 31 and the average SDP message size was 501 bytes. With no soft-state gateway running, it took just over 38 minutes for all announcements to be received (although all but two announcements had been received after about 20 minutes). We ran a series of experiments with a soft-state gateway running and 6

observed start-up times very close to the expected times. These results indicate that packet loss is a signi cant factor when no soft-state gateway is present and the session directory relies on transmissions from distant applications. Since packet loss between a client and a soft-state gateway is likely to be negligible in most environments, the soft-state gateway oers two advantages. Besides faster convergence due to increased bandwidth, the lower packet loss rate also results in reduced waiting time at startup. A key advantage of the soft-state gateway approach is its amenability to incremental deployment. Existing session directory tools need not be modi ed to receive faster updates. A disadvantage of this approach is the diculty of eectively optimizing for limited bandwidth (e.g., a wireless network). In such an environment, a soft-state gateway would not be eective since the local SAP bandwidth limit would not be any higher than the global limit. An approach similar to the TCP solution described above, but with better scalability properties, is desirable. Since a session directory tool typically displays a list of session titles and displays detailed information only when a session is examined by a user, the gateway could initially forward only session titles. When a program is selected, the client asks for the full announcement which the gateway multicasts. Since the full announcement is multicasted, other session directories will receive it and will not need to issue a redundant request when a dierent client selects the session. This scheme could be realized using the exible reliable multicast framework described by Raman [23].

2 1 client

server 3

Figure 7: Expanding Ring Search. The client rst sends a packet with a small TTL. Since that packet does not reach any servers, the client sends another packet with a higher TTL. This packet does reach a server which sends a response to the client. solution based on cryptographic signatures could be developed. Since such a solution requires services that have not been widely deployed (i.e., a public key distribution infrastructure), we use the simpler but weaker approach in our current implementation. Unfortunately, this scheme is not as transparent as the soft-state gateway is for caching. If no agent is running, the expanding ring search will fail. In such a case, a client might start advertising the session itself and periodically conduct another expanding ring search to locate a recently started agent. To ensure that only users within the local domain access the advertising agent, an authentication mechanism is needed. Authentication is required if, for example, the advertising agent cryptographically signs each announcement it is advertising, certifying that it originates within the organization from which it is being advertised. An architecture for verifying such signatures has not been deployed, primarily because | as noted previously | it requires an eective key distribution infrastructure. To perform authentication, we could rely on the inability of users outside the local domain to execute a successful expanding ring search to locate an agent. This scheme would not be foolproof since a remote user might know the location (the IP address and TCP port) of the advertising agent process or might be able to guess it (e.g., by examining the source address of other announcements originating from the local domain). Instead, we chose to use a challenge-response system. When a client creates a session to be advertised, the advertising agent multicasts a packet within the local administrative scope zone containing a randomly chosen key. The client must respond quickly with that key or the session will not be advertised. This scheme is only eective if the administratively scoped region is correctly con gured. In fact, the current draft discussing administrative scoping [21] speci cally discourages application and protocol designers from relying on administrative scoping for security. While we believe that stronger solutions (e.g., using cryptographic signatures) deserve investigation, this scheme oers some degree of protection with low complexity.

3.2 Proxy Announcements When a client wishes to advertise a session, it locates an appropriate instance of the agent and contacts it via TCP. In order to do so, it must nd the unicast address of the agent process. One solution to this problem is for the user to con gure the session directory tool with the unicast address, but this burdens users with the undesirable requirement that they discover this address. Additionally, this solution is in exible; a network administrator cannot move the agent process to a dierent host without notifying all users. Instead, we chose to have clients locate an agent dynamically using an expanding ring search, as suggested by Deering [5]. As illustrated in Figure 7 a client performs an expanding ring search by sending a multicast packet to a well-known address. Servers listen to that address and send a response whenever they see a request. Clients begin by sending their request with a small scope (e.g., with a TTL of 1). They continue to re-send the request, each time with a larger TTL, until a response is received. When the client locates a server via expanding ring search, it establishes a TCP connection to the agent and transmits the message it wishes to advertise. When such a request is received, the agent begins to advertise the session on behalf of the client and returns a key to the client. This key can be used later to modify or delete the session announcement4. Although this scheme can be circumvented with some eort by a malicious user determined to disrupt another user's session announcement, it prevents accidental deletions or modi cations and trivial attacks. It is also possible to log all activity so that if a problem does occur, the host from which the attack came can be identi ed. If a stronger security model is required, a 4 SDP includes a list of times when a session will be active and when a session is no longer active based on the times in the SDP message, the session announcement is implicitly deleted.

7

to signal layers. The numeric order of the addresses cannot be used because the assignment of address ranges to administrative scopes is arbitrarily chosen by a network administrator. Thus, We use the SDP attribute mechanism to specify this mapping. An SDP message can contain arbitrary attributes; if an application sees an attribute it does not recognize it is ignored. SDP attributes can be either global (i.e., meaningful for the session as a whole) or speci c to individual media streams. The attribute used to describe layered sessions is always speci c to an individual media stream. Following the convention that SDP attributes take the form \name :value ", we developed the following syntax for the layers attribute:

4 Layered Media Having described the details of the split agent architecture that reduces the start-up latency of session directory clients, we now discuss how this same agent architecture can be exploited for layered session advertisement. 4.1 Session Description As it is currently speci ed, the only provision in SDP for describing layered sessions is that a contiguous range of addresses may be speci ed as part of a media channel description. Non-contiguous ranges cannot be described. As a result, a session that uses layered transmission with noncontiguous addresses (i.e., because the enhancement layers are sent to administratively scoped addresses) cannot be described with a single SDP message. If a single announcement contains all the addresses and is announced globally, all receivers will see the addresses for the enhancement layers. However, these addresses are not valid outside the scope in which they were allocated, so they are useless to receivers outside the administratively scoped region. Moreover, the IP Multicast service model does not provide an easy way for a receiver to determine if it lies in the same region as another host. Thus, if a single announcement contains the addresses of the enhancement layers, the receiver cannot easily decide if the enhancement layer addresses are useful. Alternatively, the session announcement could be transmitted only within the scope to which the enhancement layers are sent, but then receivers outside that scope would not see an announcement for the base layers, which they are otherwise able to receive. To support sessions that use layered transmission in which the addresses are not contiguous, we form a session description from multiple SDP messages. For every administrative scope within which some layers are transmitted, a distinct SDP message is created, which includes only addresses from that scope. When SDP is used in conjunction with SAP, each message is multicast within the same administrative scope as the layers it advertises. Because SDP is a message format used by protocols other than SAP, such a change is unacceptable if it requires conceptual changes to other transport protocols that use SDP. The changes we propose do not require changes to other transport protocols because SDP speci es that a single SDP \payload" may contain multiple independent SDP messages. As long as an application understands how to reconstruct SDP advertisements from multiple messages, the messages that comprise a single announcement can be concatenated in to a single SDP payload and carried by the same underlying transport protocol. Two SDP messages that advertise a simple layered session are shown in Figure 8.

a=layers:[-][/]

The bracketed arguments are optional. The attribute contains the number of a layer or a range of layers (e.g., 2 or 4-7) and optionally, a count of the total number of layers. If a total is present, the announcement is not complete until addresses for all layers are received. For some layered transmission schemes, the total number of layers need not be the same for every receiver (i.e., some receivers might use highbandwidth enhancement layers while others do not). In such a case, the total number of layers is left unspeci ed and an advertisement may be considered complete if addresses for all layers up to some point have been received. In such a case, it is possible that one or more messages containing addresses of higher layers have not yet been received when the advertisement is considered complete, so applications should wait a short period of time (determined by the SAP protocol timers) before deciding such an advertisement is complete, to allow for advertisements of any further enhancement layers to arrive. This structure allows the session announcement agent to detect incomplete session announcements. If the total number of layers is speci ed for a session but some layers have not been allocated in the local region, the agent must allocate the missing layers before any local participant can join the session. If there are many such incomplete sessions but no local participants, allocating addresses for all the sessions wastes multicast addresses. Because the total number of globally advertised sessions is still low, we have not addressed this issue. If there are many global sessions, the agent needs a policy to decide which sessions it should complete. One possible approach is to allow an administrator to de ne a policy within the agent for deciding which sessions may be left incomplete. Alternatively, a mechanism could be de ned for users to express their interest in a session to the agent so that the agent can respond by completing the announcement. The problem is more dicult for sessions that do not specify a xed total number of layers. Such a session can always be considered \complete" but the agent cannot know a priori if there is enough local interest in the session that local high-bandwidth enhancement layers should be allocated. In our current implementation, we con gure the agent with a target number of layers for each session and when a session with fewer than this target number of layers is encountered, extra layers are allocated to bring the total number of layers up to the target. This policy is relatively simplistic; we plan to experiment with more sophisticated policies in the future.

4.2 Reconstructing Messages With the scheme outlined above, session directory tools must collate the separate SDP messages that comprise a single announcement. Fortunately, SDP includes a eld, the \o" eld, that is guaranteed to be globally unique for each session. By setting the \o" eld to be the same in all messages that make up a single announcement, it is easy for an application receiving SDP messages to identify and reconstruct messages that form a single announcement. Once the appropriate messages have been received, they still must be ordered so that the appropriate media tools can be started. That is, the network address must be mapped 8

v=0 o=aswan 123 456 IN IP4 128.32.131.169 s=Layered Video Test t=0 0 m=video 1234 RTP/AVP 21 c=IN IP4 224.2.3.4/1/4 a=layers:0-3

v=0 o=aswan 123 456 IN IP4 128.32.131.169 s=Layered Video Test t=0 0 m=video 1234 RTP/AVP 21 c=IN IP4 239.192.2.16/1/4 a=layers:4-7

Figure 8: Two SDP messages that comprise a single announcement for a session that uses layered video transmission.

Figure 9: The nsdr user interface 5 Status and Future Work To eld and test our design, we implemented sdfor and a new session directory tool nsdr using the MASH platform [19]. MASH is a toolkit for multimedia and networking applications built on top of the Tcl [22] scripting language and Object Tcl [29] object-oriented Tcl extension. We have implemented basic session directory functionality in nsdr but some features still must be implemented, including encrypted session announcements and session invitation (e.g., via SIP). We have also made some improvements over sdr in nsdr. Most notably, nsdr can launch applications that operate on multiple media streams (e.g., a single tool that receives and displays both audio and video), which is not possible with sdr. The nsdr user interface is shown in Figure 9. The main window, which is shown on the left, includes a list of all currently available sessions. The detail window, shown on the right, is presented when the user clicks on a session. It presents much of the information included in the session description and presents an interface to launch the appropriate media-speci c tools to participate in the session. The primary goal of this work has been to deploy and experiment with layered video systems. We are just beginning to conduct experiments with the \Progressive Video with

Hybrid transform" (PVH) video codec5 and RLM for receiver adaptation. We plan to conduct trials on the CAIRN [3] and Internet2 [13] testbeds soon. As discussed above, more work is required on policies for reconstructing layered session announcements. We also plan to explore the possibility of using cooperation between multiple instances of the agent process to enhance the reliability of the proxy session advertisement service. We have recently deployed this architecture and expect that practical experience using it will lead to a better understanding of the challenges of MBone conference setup. 6 Summary We have described the design and development of two new tools to improve MBone conference setup. The session directory tool, nsdr, implements a simple scheme for describing sessions that use layered transmission, and our session announcement \agent", sdfor, plays a key role in the architecture for layered session advertisement. In addition, sdfor provides a convenient location for an eective SAP cache and for making SAP announcements by proxy. The 5 PVH is a layered video compression algorithm based on conditional replenishment and a hybrid wavelet/DCT transform stage [18].

9

[15] Jacobson, V. Sigcomm '94 tutorial: Multimedia conferencing on the internet, August 1994. [16] Jacobson, V. Re: sd and multicast ports, June 1995. Message to the rem-conf mailing list. [17] Lin, J. C., and Paul, S. RMTP: A reliable multicast transport protocol. In Proceedings IEEE Infocom '96 (San Francisco, CA, Mar. 1996), pp. 1414{1424. [18] McCanne, S. Scalable Compression and Transmission of Internet Multicast Video. PhD thesis, University of California Berkeley, December 1996. [19] McCanne, S., et al. Toward a common infrastructure for multimedia-networking middleware. In Proceedings of the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV '97) (1997). [20] McCanne, S., Jacobson, V., and Vetterli, M. Receiver-driven layered multicast. In Proceedings of SIGCOMM '96 (Stanford, CA, August 1996). [21] Meyer, D. Administratively Scoped IP Multicast, June 1998. Internet Draft, work in progress. [22] Ousterhout, J. Tcl and the Tk Toolkit. AddisonWesley, 1994. [23] Raman, S., and McCanne, S. Scalable data naming for application-level framing in reliable multicast. In Proceedings of ACM Multimedia '98 (Bristol, UK, September 1998). [24] Schulzrinne, H. RFC 1890, RTP Pro le for Audio and Video Conferences with Minimal Control, January 1996. [25] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. RFC 1889, RTP: A Transport Protocol for Real-Time Applications, January 1996. [26] Speakman, T., Farinacci, D., Lin, S., and Tweedly, A. Pragmatic General Multicast (PGM) Reliable Transport Protocol. CISCO Systems, 1998. Internet Draft, work in progress. [27] Tennenhouse, D. L., Smith, J. M., Sincoskie, W. D., Wetherall, D. J., and Minden, G. J. A survey of active network research. IEEE Communications Magazine 35 (Jan 1997), 80{86. [28] Tung, T.-L. Mediaboard using the scalable reliable multicast toolkit. Master's thesis, University of California Berkeley, April 1998. [29] Wetherall, D., and Lindblad, C. J. Extending Tcl for dynamic object-oriented programming. In Proceedings of the Tcl/Tk Workshop (1995).

layered session description scheme and the applications we developed do not require signi cant conceptual changes to existing protocols (i.e., SAP and SDP) and they are easily deployed alongside other session directory applications. Acknowledgments This research was supported by DARPA contract N6600196-C-8508 and by generous support from Fujitsu Laboratories, Ltd., Fuji Xerox, Intel, Microsoft, and NEC Corporation. References [1] Amir, E., and McCanne, S. An active service framework and its application to real-time multimedia transcoding. In Proceedings of SIGCOMM '98 (Vancouver, BC, September 1998). [2] Cain, B., Deering, S., and Thyagarajan, A. Internet Group Management Protocol, Version 3, November 1997. Internet Draft, work in progress. [3] The collaborative advanced internet research network (CAIRN). Web page: http://www.isi.edu/div7/CAIRN/. [4] Deering, S. Internet multicast routing: State of the art and open research issues, Oct. 1993. Multimedia Integrated Conferencing for Europe (MICE) Seminar at the Swedish Institute of Computer Science, Stockholm. [5] Deering, S. E. Multicast Routing in a Datagram Internetwork. PhD thesis, Stanford University, December 1991. [6] Floyd, S., Jacobson, V., Liu, C.-G., McCanne, S., and Zhang, L. A reliable multicast framework for light-weight sessions and application level framing. IEEE/ACM Transactions on Networking (December 1997). [7] Fox, A., Gribble, S. D., Brewer, E. A., and Amir, E. Adapting to network and client variation via on-demand, dynamic distillation. In Proceedings of ASPLOS-VII (October 1996). [8] Handley, M. The sdr6 multicast session directory. Software available on line . [9] Handley, M. SAP: Session Announcement Protocol, November 1996. Internet Draft, work in progress. [10] Handley, M., Crowcroft, J., and Bormann, C. The Internet Multimedia Conferencing Architecture, July 1997. Internet Draft, work in progress. [11] Handley, M., and Jacobson, V. RFC 2327, SDP: Session Description Protocol, April 1999. [12] Handley, M., Schulzrinne, H., and Schooler, E. SIP: Session Initiation Protocol, May 1998. Internet Draft, work in progess. [13] Internet2 home page. Web page: http://www.internet2.edu/. [14] Jacobson, V. Congestion avoidance and control. In Proceedings of SIGCOMM 88 (1988). 6 http://north.east.isi.edu/sdr

10