![[image]](rcvr-adapt.gif)
Andrew Swan
Steven McCanne
Lawrence A. Rowe
{aswan,mccanne,rowe}@cs.berkeley.edu
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 flow 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 significant
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.
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 flow simply by framing the flow as a sequence of packets and multicasting those packets to a multicast group address. Receivers interested in a certain flow simply join the multicast group corresponding to the flow in question and the network automatically delivers that flow from the source to each receiver along an efficient multicast routing tree. Though this communication model is natural and simple, it brings with it a number of new and difficult 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 flows 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-effort 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 conflicting 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 refined, 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 difficult to do in a scalable manner. Furthermore, because there are multiple paths, which may have different characteristics, the sender alone cannot simultaneously meet the conflicting demands of different receivers.
One solution to this problem is proxy-based transcoding, where data streams are individually transformed according to the specification 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 difficult 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 offering a common platform for such services as part of the basic network service model [28], 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 effort and cost [7].
Alternatively, we can avoid proxies with an entirely ``end-to-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.
Layered encoding can be effectively combined with multicast transmission by sending different layers on different 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 refined in a specific protocol architecture called Receiver-driven Layered 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 off 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 subflows 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 offer such per-source filtering. Though work is underway in the Internet Engineering Task Force to extend the IP Multicast service model to allow per-source filtering [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 offers no benefit 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 inflate 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 configure a path across a well-known bottleneck link with a ``pipesize'' option. As a result, the TCP does not attempt any adaptation beyond 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 flow 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 flows, 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 traffic 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 benefit 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 configured 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 specific 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.
The protocol architecture that underlies the light-weight sessions conferencing tools is depicted in Figure 3. At the bottom of the protocol stack is IP Multicast, which offers efficient one-to-many data transmission and thus provides the foundation for applications that need to distribute data to many receivers in a scalable manner.
![[image]](arch.gif)
|
| Figure 3: Protocols that form the Internet Multimedia Collaboration Architecture |
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 to a local router which then uses a multicast routing protocol1 to arrange for all traffic 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 offers only best-effort service. It does not offer 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.
The IP Multicast service model provides two mechanisms for scoping a transmitted packet so that it stays within a specific region. When IP Multicast was initially developed, the Time-To-Live (TTL) field in the IP packet header, which limits the number of hops a packet may take, was the only scoping mechanism. The TTL field is decremented at every router a packet traverses, and when it reaches zero, the packet is discarded. To impose administrative structure on TTL-defined scopes, routers can be configured with a non-zero ``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 configured with a threshold of 32, and thus will not forward multicast traffic 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 inflexible (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 defined by multicast addresses rather than by the TTL field. A network administrator creates an administratively scoped region by choosing a range of addresses for the scope and configuring 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 flexibility in defining 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 traffic and that traffic should not be leaked onto the UCB campus network, it is bounded by an administratively scoped region. Simultaneously, a separate administratively scoped region is defined for the UCB campus. Because several hosts have a high-speed connection to CAIRN yet are also part of the UCB campus, the multicast scope regions must overlap. Such a scheme cannot be realized with TTL scoping.
In addition to providing a mechanism for containing and localizing high-rate traffic, administrative scoping enhances the scalability of multicast routing and addressing since administratively scoped addresses may be spatially re-used. For example, the address range 239.192.0.0/14 (i.e., addresses 239.192.0.0 through 239.195.255.255) is defined as the organization-local scope. Because a packet transmitted to an address in this range is not forwarded outside the local organization, the same range of addresses can be used within other organizations without conflicts. This spatial re-use of addresses enhances the scalability of the multicast routing infrastructure since routing state for administratively scoped addresses need only be maintained locally.
A great deal of work has gone into the development of protocols for multicast distribution of continuous media, culminating in the specification of the Real-Time Transport Protocol (RTP) [26,25]. Multicast protocols for other applications (e.g., reliable multicast [6, 17,27] and its use in collaborative applications [29]) are still the subject of active research.
RTP and other protocols under development follow the light-weight sessions model, in which there is no explicit control of group membership or explicit conference control. This model works well in conjunction with the IP Multicast service model; an application joins a session simply by subscribing to the appropriate multicast group. With this 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 invitation model, a user is explicitly invited by another user 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 approach works well for small meeting scenarios but is poorly suited to large scale broadcast style events. For the session invitation model to be effective, 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 different approach is required.
In the session announcement model, which is used in the Session Announcement Protocol (SAP) [9], session descriptions are periodically multicast to a well-known multicast group. A session directory tool maintains a list of all session descriptions that have been recently announced via SAP. Because the session announcements contain all information needed to launch the actual collaboration tools, the session directory tool can run the appropriate applications when the user selects a program. This frees the user from the cumbersome task of dealing with command line arguments, multicast addresses, and so forth.
When a description is received by a session directory application, 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.
Protocols that periodically announce their state at each source an maintain a cached copy of each state announcement at the receiver are called announce-listen protocols [24]. Announce-listen protocols are easy to implement yet are robust since there is no separate or explicit provision for fault recovery. If a message is dropped by the network, it is refreshed by a subsequent transmission, and, if an application crashes, its announcements eventually time out.
To ensure that SAP announcements do not consume an arbitrary amount of bandwidth, the aggregate bandwidth for all SAP announcements is fixed. To send a SAP announcement, an application estimates the total number of announcements and the average size of each announcement. The average interval between transmissions is calculated as follows:
N is the total number of announcements, size is the average message size, and bw is the aggregate bandwidth for all SAP announcements. If all sending applications implement this algorithm, the aggregate bandwidth consumed does not exceed bw. Receiving applications also calculate the transmission interval and time out an old announcement if is not refreshed for a period equal to some multiple of the transmission interval.
In the current session directory service, a separate instance 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 scalability of SAP and the multicast routing infrastructure. It 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.
Both SAP and SIP require a standard format for describing session parameters. The Session Description Protocol (SDP) defines a common format that includes media 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 directory application sdr [8].
There are several weaknesses with the current conference setup architecture:
To address the first problem, we have worked out a simple scheme, described in the next section, for advertising layered sessions in which layers are transmitted across varied scopes. Upon creating a layered session, the originator can allocate and advertise addresses for all layers within the local scope. However, the originator cannot allocate and advertise addresses for enhancement layers in remote regions, as illustrated in Figure 5. In a remote region, only the announcement for the base layers is visible. As a result, some entity needs to recognize missing layers and allocate and advertise addresses for them. For example, in Figure 5, if the receiving hosts (R1, R2, and R3) want to use local high-bandwidth enhancement layers, multicast addresses must be allocated and an announcement to supplement A1 must be created.
One solution to this problem would be a distributed algorithm that runs in session directory clients in the remote region. For example, in Figure 5, R1, R2, and R3 could invoke a distributed algorithm in which one of them would be ``elected'' to allocate and advertise multicast addresses for the enhancement layers. This approach, however, requires a complex coordination protocol. Furthermore, it may be desirable to implement different policies to fill-in missing layers at different sites, which would be difficult 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 first complete design and working implementation. This program is run as a background process and performs the following tasks:
The remainder of this section describes these tasks in more detail.
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 first 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 effective 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 effectively as all session updates are transmitted individually to all clients.
A more elegant solution is to use the concept of a soft-state 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 different 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 offers 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,
The expected time until a session directory tool receives all announcements is thus:
Expected waiting times for a range of bandwidths are shown in Figure 6 for the values N=30, 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 fixed 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.
To assess the benefits 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 observed start-up times very close to the expected times. These results indicate that packet loss is a significant 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 offers 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 modified to receive faster updates. A disadvantage of this approach is the difficulty of effectively optimizing for limited bandwidth (e.g., a wireless network). In such an environment, a soft-state gateway would not be effective 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 different client selects the session. This scheme could be realized using the flexible reliable multicast framework described by Raman [23].
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 find the unicast address of the agent process. One solution to this problem is for the user to configure 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 inflexible; a network administrator cannot move the agent process to a different 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 effort by a malicious user determined to disrupt another user's session announcement, it prevents accidental deletions or modifications 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 identified. If a stronger security model is required, a 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 effective 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 effective if the administratively scoped region is correctly configured. In fact, the current draft discussing administrative scoping [21] specifically 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 offers some degree of protection with low complexity.
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.
As it is currently specified, the only provision in SDP for describing layered sessions is that a contiguous range of addresses may be specified as part of a media channel description. Non-contiguous ranges cannot be described. As a result, a session that uses layered transmission with non-contiguous 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 specifies 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.
With the scheme outlined above, session directory tools must collate the separate SDP messages that comprise a single announcement. Fortunately, SDP includes a field, the ``o'' field, that is guaranteed to be globally unique for each session. By setting the ``o'' field 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 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 specific to individual media streams. The attribute used to describe layered sessions is always specific 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:
a=layers:<first>[-<last>][/<total>]
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 high-bandwidth enhancement layers while others do not). In such a case, the total number of layers is left unspecified 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 specified 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 define a policy within the agent for deciding which sessions may be left incomplete. Alternatively, a mechanism could be defined 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 difficult for sessions that do not specify a fixed 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 configure 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.
To field 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 [30] 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.
![[image]](screenshot.gif)
|
| Figure 9: The nsdr user interface |
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-specific 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.
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 effective SAP cache and for making SAP announcements by proxy. The layered session description scheme and the applications we developed do not require significant conceptual changes to existing protocols (i.e., SAP and SDP) and they are easily deployed alongside other session directory applications.
[2] The decomposition is analogous to HTTP and HTML; SAP and 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.
[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.
[5] PVH is a layered video compression algorithm based on conditional replenishment and a hybrid wavelet/DCT transform stage [18].
This research was supported by DARPA contract N66001-96-C-8508 and by generous support from Fujitsu Laboratories, Ltd., Fuji Xerox, Intel, Microsoft, and NEC Corporation.
![[image]](scoped-layering.gif)
![[image]](admin.gif)
![[image]](layered-reconstruct.gif)
![[image]](ssg.gif)
![[image]](ers.gif)