Department of Computer Science, Reykjavik University. Summary: ... distance learning infrastructure based on our novel lightweight IP multicast. We moreover ...
Distance learning using IP multicast Björn Brynjúlfsson, Ólafur Ragnar Helgason, Heimir Þór Sverrisson and Gísli Hjálmtýsson Department of Computer Science, Reykjavik University Summary: As the Internet and Internet technologies storm the world of communications, economic forces are driving IP to provide services well beyond what was originally intended. The simple flexible IP service model and the avoidance of the burdensome regulatory/contractual legacy of telephony have resulted in ubiquitous reach and greater economies. IP multicast promises to bring the same to group communications. Distance learning and teleconferencing is still mostly based on traditional telephony solutions where centralized conference bridges using ISDN still dominate. Although some solution providers offer facilities to use IP as transport, even H.323 based conferencing offers remain centralized with point-to-point connections to each participant. In this paper we describe our experimentation with teleconferencing and distance learning infrastructure based on our novel lightweight IP multicast. We moreover describe how we have exploited our multicast and smart routers to implement distributed scalable teleconferencing for H.323 clients. Network Systems and Services Laboratory, REYKJAVIK UNIVERSITY Ofanleiti 2, IS -103 Reykjavík Tel: +354 510 6200, Fax: +354 510 6201, email: { bjorninn, olafurr, heimir, gisli}@ru.is
1 Introduction The Internet and IP technology has taken over other communication technologies as the focal point of networking innovation both in technology and services. The simple service model of IP, flexibility and focus on software solutions have made Internet approaches robust, inexpensive and uniquely able to exploit the rapid advances in hardware capabilities. Equally important in the success of the Internet has been to avoid regulatory and contractual complexities of telephony. Internet solutions are evolving faster than any other network technology and IP technology is gradually replacing other communication technologies and networking services. Distance learning overcomes geographical barriers in sparsely populated areas and makes it possible to achieve economy-of-scale without localizing all participants. In particular, distance learning allows for increased selection of courses and curriculums and promises increased teaching quality as more people have access to more qualified instructors. Distance learning today is predominantly based on ISDN equipment and connectivity, justified by availability and quality of service guarantees provided by ISDN. Available equipment, more targeted on the corporate environment, is expensive and specialized. ISDN conferencing solutions are centralized; having a single conference bridge through which both control and media must pass. This conference bridge becomes the performance bottleneck, a single point of failure, and inherently limits the scalability of the conferencing service. Although increasingly H.323 based solutions are being offered allowing the use of IP transport, these solutions are architecturally the same having a single conference bridge and thus suffering from the same scalability and synchronicity problems. Multicast is a core network service where a group of receivers simultaneously receive a data stream from a sender. Packets are copied at multicast routers and forwarded on each port that has a downstream receiver. The sender sends only one data stream to its neighboring router independent of the number of
receivers and thus is load-insensitive to the number of receivers. Instead work is delegated onto the multicast routers inside the network thus increasing scalability. Therefore multicast is especially well suited for distance learning and live audio or video streaming on the Internet. Despite almost two decades of research on multicast it has yet to see widespread deployment on the Internet. The main reason is that multicast protocols proposed so far have some serious drawbacks and complexities that prevent deployment: a) The reserved multicast IP address range causes address allocation and scalability problems because multicast addresses are a scarce resource. b) Multicast specific routing protocols require substantial multicast specific infrastructure imposing significant cost and complexity on the Internet c) Existing protocols require a multicast specific virtual network where every router is a multicast router thus imposing significant management cost on IP network operations. We have designed and implemented a novel multicast protocol that exploits the existing unicast Internet infrastructure and existing router functions thereby eliminating the need for multicast specific routing protocols or infrastructure. By limiting the multicast model to one dedicated sender and incorporating the IP address of the sender in the multicast group ID we avoid the use of special multicast IP addresses, and multicast specific routing. Dynamic IP tunneling through non-multicast routers supports incremental deployment and eliminates the need for a multicast specific virtual network. The multicast is selfconfiguring and requires no multicast specific functions in the forwarding path of routers but exploits functions commonly available in modern routers such as flow classification and tunneling. We have implemented our new multicast using commodity hardware that we have tested at up to Gbps link rates. The only multicast specific function required on multicast routers is the software implementing our new Topology Management Protocol. Participants in a multicast session can use standard multimedia desktop applications for sending and receiving audio, video and other data, such as Windows Media Player, NetMeeting and more. Moreover we have built and experimented with a novel H.323 decentralized mode solution that avoids a centralized media bridge, and uses our multicast for scalability, without requiring changes to user end systems. In this paper we describe the implementation of our multicast and our considerable experimentation with multicast and distance learning using various network equipment, conferencing equipment and desktop multimedia applications.
2 Related work The contribution of this paper is mainly how Internet technology and the SLIM multicast in particular, can enhance distance learning. SLIM [1,2] is a network layer single source multicast. As such it is most strongly related other single source multicast protocols, particularly [3] and [4]. We share the author’s view that single source network layer multicast is the adequate and appropriate elementary multicast service and sufficient for more elaborate group communication sessions to be built upon. In fact a multi-sender session can easily be created using either our [1] or [3,4], SLIM leaves such issues to session management and out of our network layer protocol. In this work we experimented with using SLIM to implement a distributed conferencing with H.323. While SLIM is agnostic to the session initiation protocol, and could in particular use SIP [5] market reality makes H.323 of practical interest. Some existing legacy equipment supports H.323 and most IP enabled conferencing equipment available in the market place supports H.323. SIP provides a similar set of services as H.323.
SLIM and our H.323 solutions are implemented on the Pronto active router [6] using the PProcs architecture [7]. The flexibility of the PProcs architecture allows for simple, transparent solutions, for example of how multicast can be used as a transport for H.323 in centralized mode. This paper is based on previously written reports [8,9], on the same topic.
3 SLIM – Protocol summary Despite almost two decades of research on IP multicast it has yet to see widespread deployment on the Internet. The main reason being that multicast protocols proposed so far have some serious drawbacks and complexities that prevent deployment. First, the class D address range, used by traditional protocols, is a limited resource and calls for the use of global multicast address allocation which causes scalability problems. Second, the need for multicast specific routing and substantial multicast specific infrastructure in the multicast protocols proposed so far imposes significant cost and complexity on the Internet. As it is clear that multicast traffic will only be a small fraction of the total Internet traffic this added cost and complexity is hard to justify. Third, most of the existing protocols require a static multicast specific virtual network where every router is multicast capable thus imposing significant management cost on IP network operations and making incremental deployment hard. We have designed and implemented a Self-configuring Lightweight Internet Multicast protocol (SLIM) that avoids the drawbacks and complexities of the protocols proposed so far. We believe that the role of the network is to offer a simple multicast service model by sending a packet from a single source to one or more receivers without changing or adding any multicast specific infrastructure. All other functionality not directly relating to that model, such as session initiation and the creation of a multicast session with many senders, should be realized at the application- or session layers where SLIM is used as a building block. SLIM is a single source multicast. A multicast group is identified by the pair 〈S,C〉 where S is the IPaddress of the source and C is the source specific channel identifier. The address allocation problem is therefore eliminated as each source is locally responsible for choosing a C that makes the pair 〈S,C〉 globally unique. Especially, C does not need to be a class D IP address but can be any legal IP address. Control messages, join and leave, are processed by the Topology Management Protocol (TMP) running on multicast capable routers. The multicast distribution tree is built by receiver initiated join messages sent towards the source. The join message is caught by the first multicast router in its path which creates a classifier forwarding entry for the multicast group. It then forwards the join message towards the source. When a router that is already a part of the distribution tree for 〈S,C〉 receives the join message it adds the newly created branch to the distribution tree and suppresses the join message. A multicast distribution therefore constitutes of the classifier forwarding states and thus no multicast specific routing is needed for SLIM. The TMP protocol has built-in support for incremental deployment of the multicast. The multicast stream is dynamically tunneled through non-multicast routers, eliminating the need for a multicast specific virtual network and drastically reducing the management overhead of the multicast. The TMP protocol defines two types of control messages, join and leave, and a corresponding protocol header. The join message creates and maintains the topology of a distribution tree for a particular multicast group whereas leave tears down the forwarding state set up by the corresponding join message. The protocol header for the join message depicted in Figure 1 contains the following fields:
Control: set to the value JOIN Source Address (S): The IP address of the sender. Channel Address (C): An IP address chosen so that the pair 〈S,C〉 is globally unique.
Last-Branch-Point: The IP address of the next downstream multicast enabled router (or the next branchpoint) in the distribution tree, or the receiver. TTL@Last-Branch-Point: TTL value of the IP header on the last branch point. When a SLIM enabled router updates the last-branch-point it copies the TTL value in the IP header into this value before JOIN messages are forwarded. Option: Option identifier, followed by an option value. If present the protocol message header is followed by an option value. An example option is the “receive as” option, designed to cope with firewalls and NAT’s for multicast end user support.
Figure 1: The TMP protocol header
Control messages in the protocol are sent best effort with the Router alert IP option and a new protocol number. All forwarding state on routers is soft and therefore has to be refreshed periodically to prevent expiration and maintain the multicast distribution tree. The primary benefit of soft state is simplification of exception handling and it allows us to send the leave message unreliably as the allocated forwarding state is eventually removed after timer expiration. Therefore join is the only necessary control message for protocol correctness but leave can be used to accelerate resource reclaim on routers. We have implemented SLIM on the Pronto [6] router using the Packet Processor architecture [7]. The Pronto router is a flexible, highly modular router supporting the composition of paths through the router from elementary packet processors. In particular, a path can have multiple branches, each branch composed of one or more packet processors. Thus branches may differ in functionality. The TMP daemon is implemented entirely in userspace as the multicast protocol requires no multicast specific functionality in the datapath of the router. Moreover the TMP daemon maintains no non-local information beyond what is conveyed by the join and leave control messages and only makes use of general existing router facilities.
4 Exploiting multicast for distance learning Colleges and Universities are increasingly offering distance learning to remote students. Distance learning today is predominantly based on traditional ISDN equipment, connectivity and conference bridges, justified by the availability and quality of service guarantees provided by ISDN. In the Icelandic educational system we have furthermore found that in an effort to economize on equipment purchases, users and vendors have constructed conferencing solutions from commodity components, sacrificing reliability and ease of administration. ISDN conferencing solutions are centralized with a single conference bridge through which both control and media must pass. This conference bridge becomes the performance bottleneck, a single point of failure, and inherently limits the scalability of the conferencing service. Due to the limited number of concurrent conferencing sessions and participants, sessions – and thus teaching schedules – must be scheduled “globally”, i.e., among all potential clients of the service. In Iceland this implies that all distance learning sessions must be coordinated and impromptu meetings are virtually impossible. The success of the Internet stems greatly from its simple service model and the absence of regulatory and contractual complexities of telephony. As the Internet matures as the dominant network for all types of communication it is of ever increasing importance that distance learning moves the focus away from telephony solutions to Internet based solutions. Distance learning with IP multicast has the benefit that
Internet connections can be shared with other data streams and applications. Distance learning centers can therefore invest in Internet technology and Internet connections for the benefit of all. Although some solution providers offer facilities to use IP as transport, even H.323 based conferencing offers remain centralized with point-to-point connections to each participant. By offering live streaming from lectures, using “commodity” Internet technology and our multicast protocol, better efficiency can be achieved at much lower cost. It is also of some importance to look at the possibilities of connecting old equipment with new technology and therefore exploit current investment and infrastructure and help to accelerate the transition to IP based solutions. In the light of this we have built a scalable H.323 solution that uses our multicast as a building block.
4.1
Distance learning with SLIM
The use of IP multicast in distance learning achieves increased scalability as there is no longer a centralized bottleneck or a possible single point of failure that all media and control must pass through. Our multicast protocol moreover enables end users and senders to use commodity equipment and standard desktop applications for reception, encoding and streaming of media. The SLIM TMP protocol also has built-in support for reaching end users not directly connected to a multicast capable router and for coping with NAT’s and firewalls as we describe in [2]. We have recognized three scenarios where multicast is exploited for distance learning where the level of feedback and interaction between senders and receivers and the delay tolerated are the primary separators: I. Content distribution: A distribution from a multimedia server to multiple receivers. This can be exploited to distribute a prerecorded educational material, Internet radio or a high quality TV stream. A modest delay, such as from sender or receiver buffering, can easily be tolerated. II. Live distribution: A live distribution from a lecturer to multiple students. From a multicast perspective this is just like a content distribution from a multimedia server but this introduces certain real time constrains that needs to be met. Feedback from receivers (e.g. students) can be achieved with a chat room or a messenger application. This is a good choice when the students are at home with limited equipment and bandwidth. A small delay can be tolerated if the interaction among the group is message based. III. Fully interactive teleconference: A teleconference where all participants can send and receive audio and video streams. In this setup students can ask questions and participate in discussions as on site. A fully interactive distribution has stronger real time constraints than a content distribution and only a very small delay can be tolerated by users in a live conversation. For example, in a telephone conversation the maximum tolerated end-to-end delay is generally not more than 100 ms. A distance learning session can be a combination of the three scenarios described above where, for example, a slide show or a video is sent to all participants in a fully interactive conference with a content distribution. One of the advantages of SLIM is that an end user can easily create a multicast group on-demand and start a multicast session without any central authorization or coordination. This is beyond what can be done in a conventional distance learning system. Meetings can therefore be scheduled impromptu and the number of participants can change arbitrarily over the lifetime of the session. In scenarios I and II SLIM can be used directly as both cases are inherently a single source distribution. In case III there are at least two options to realize a multicast session with many senders with SLIM. With session relay all hosts that wish to send to the session tunnel the multicast data to the source S1 which then relays the data into a single distribution tree for the entire session. Another approach is to create a distribution tree per sender. Each receiver then has to join as many groups as there are senders.
4.2
Distributed scalable teleconferencing for H.323 clients
We have built a scalable decentralized H.323 solution that uses SLIM as a building block. Standard H.323 end systems can be used unchanged and with our solution distance learning benefits directly from investments to improve general IP network connectivity rather than investing in special purpose distance learning network solutions. With our solution, H.323 conferencing acheives the scalability of multicast and the number of participants is practically unlimited. In our solution we have built a multicast gateway (MG) that interrupts sessions initiations and media streams from the H.323 end systems running in centralized mode. A centralized multipoint controller (MC) is used for session control where participants register for the session but all media is multicast with SLIM. The MG converts a unicast media flow from a local client, destined for the MC, to a multicast flow. As this is inherently a multisource distribution a distribution tree is built per participant. When a H.323 client wants to participate in a conference the following steps are taken in our solution: 1. A multicast gateway intercepts the call setup messages sent between a H.323 client and the MC and learns the addresses and portnumbers to be used for the call. This way the MC also knows all the participants in the session. 2. The MC periodically multicasts a session description, on a “well known” multicast group, containing all the multicast groups for a particular session. 3. The multicast gateway joins this “well known” multicast group and receives a session description periodically, containing the participants in the meeting and their correponding multicast group. The MG joins the groups it wishes in the session description file (i.e. the ones that it is not already a member of). 4. The multicast gateway receives an OpenLogicalAck message from the H.323 client in which the client states on which address and portnumber it wants to receive the media stream from other session participants. 5. The multicast gateway mixes the media streams and sends them to the H.323 client on the address and portnumber advertised in the OpenLogicalAck message. 6. The multicast gateway interrupts an OpenLogicalAck message coming from the MC to the H.323 client indicating which address and portnumber the H.323 should use for its media streams. The multicast gateway then traps the media coming from the H.323 client on the advertised address and port and maps them to the multicast address the MC has advertised in the session description. Each time a participant joins or leaves the conference the MC multicasts a new session description to all the MG’s active in the session. Our contribution, exceeding what is already a part of H.323 conferencing, is the Multicast Gateway and extensions we make to the MC for multicast session control.
5 Experimentation and discussion We have experimented with the multicast in our laboratories, on production LANs and over the open Internet for two years. As a part of that we have experimented with multicast in interactive conferencing for distance learning and teleconferencing as well as Internet radio and a high quality live TV stream. The design of SLIM, and most notably the fact that it is based on traditional unicast forwarding and general routing facilities, makes it possible to introduce and experiment with our multicast on the open Internet without the collaboration of network administrators. Experiments were carried out over our testbed, shown on Figure 2, and the Reykjavík University (RU) network. The testbed consists of four Pronto routers, each router is SLIM enabled and with a local area segment connected to it. The links of the Pronto routers are all 100 Mbps and the nodes on the RU
network are both 100 Mbps and 1 Gbps. Throughout the experimentation audio, video and data streams from 100 Kbps to 2 Mbps were sent. In contrast distance learning equipment in Iceland uses 384 Kbps. Our test setup represents a distance learning infrastructure where each distance learning center is connected using a 100 Mbps access link to a very high speed IP backbone. As a reference the Icelandic research network RH-NET runs at 1 Gbps. Throughout the experiments we used commodity equipment for distribution and reception of the multicast streams. This includes normal PC computers with Windows 2000/XP and the Linux operating system and commonly available servers and clients as described below. For end user support we have implemented a small wrapper application that implements the control signals of SLIM, but is otherwise transparent to client applications. A user simply clicks an URL of interest (lecture/meeting) thereby downloading a session description. The wrapper application, which sends out SLIM control message, is automatically started and starts the actual multimedia receiver application.
Figure 2: The testbed used for our experiments
To show multicast excellence for distributed learning we carried out three experiments with the scenarios described in 4.1: I. Content distribution: We used a multimedia server both Windows Media Server and Apple Darwin to stream a prerecorded video from the local area network attached to N. End users on local area networks A, W and S can use players such as Windows Media Player and Apple Quicktime with our SLIM wrapper to join and receive the multicast stream. II. Live distribution: A lecturer is equipped with a camera and a microphone and audio and video encoding is done in real time. With this setup we could not use the Windows Media Server as it adds an intolerable server side buffer-delay of more than 10 seconds when streaming live content. Instead we use a USB hardware mpeg encoder (Hauppauge), recode with FFmpeg multimedia system if needed and serve the stream with the VideoLan open source media server. For reception, end users can use the VideoLan media player. This setup incurs only miniscule delay. III. Fully interactive teleconference: In this experiment a central server was used for session control residing on the LAN connected to N. Users with a teleconferencing client were located on all LAN’s. Each user was equipped with a microphone and a USB camera. IV. H.323 conferencing and legacy equipment. In addition we experimented with our decentralized H.323 conferencing using NetMeeting, Polycom H.323 compatible equipment and a number of other H.323 clients obtained over the web. While media streaming over the Internet is bound to raise QoS concerns, as network resources scale, this becomes a diminishing concern. With 100 Mbps LAN and a Gigabit backbone connection, the 2Mbps media streams used in our experiments do not require explicit QoS support. However, increasing appetites for bandwidth may increase instantaneous load of competing traffic increasing latency, delay variations and packet loss. To facilitate fine grained QoS guarantees we have implemented a sophisticated packet scheduler on the Pronto router. Other options available using our router include loss tolerant encoding schemes and active retransmissions inside the network. We have found that interoperability is one of the biggest problems with streaming media on the Internet. Proprietary protocols for session description and encoding forces end users to use clients in accordance with the streaming server employed.
6 Summary We have designed and implemented a new Self-configuring Lightweight Internet Multicast (SLIM) that avoids the problems that hinder widespread multicast deployment on the Internet. Specifically SLIM does not require multicast address allocation or multicast specific routing and self configures over the unchanged Internet infrastructure. The implementation of SLIM does not require any multicast specific infrastructure or a multicast specific datapath in routers but makes use of general router facilities also intended for other purposes such as QoS, traffic engineering and service differentiation. In this paper we have described our experimentation with distance learning as an application of multicast. Our experiments show that the use of SLIM in distance learning increases both flexibility and scalability significantly beyond that of other solutions. With SLIM a multicast group can be created on-demand by end users without central authorization or coordination. Meetings can therefore be scheduled impromptu and the number of participants can change arbitrarily over the lifetime of the session. Our experiments have been conducted using only commodity equipment and standard desktop applications. As a part of our experiments with distance learning we have developed and prototyped a decentralized H.323 conference solution that uses SLIM for network transport and eliminates the need for a centralized media bridge. Our current goals are to extend theses experiments over the RHnet in Iceland and the NORDUnet to Scandinavia and Europe.
7 References [1] Gísli Hjálmtýsson, Björn Brynjúlfsson and Ólafur R. Helgason, “Self-configuring Lightweight Internet Multicast,” in preparation. [2] Gísli Hjálmtýsson, Björn Brynjúlfsson and Ólafur Ragnar Helgason multicast,” accepted for publication at NGC 2003
“Overcoming last-hop/first-hop problems in IP
[3] H. Holbrook and D. Cheriton, “IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications,” In Proceedings of SIGCOMM 1999, 1999. [4] H. Holbrook and B. Cain, “Source Specific Multicast for IP,” IETF Internet Draft, work in progress, March 2003. draft-ietfssm-arch-02.txt. [5] H. Schulzrinne, J. Rosenberg, "A Comparison of SIP and H.323 for Internet Telephony”. [6] Gísli Hjálmtýsson, “The Pronto Platform - A Flexible Toolkit for Programming Networks using a Commodity Operating System,” in the proceedings of OpenArch 2000, Tel Aviv, Israel, March 2000. [7] Gísli Hjálmtýsson, Heimir Sverrisson, Björn Brynjúlfsson and Ólafur R. Helgason, “Dynamic packet processors - A new abstraction for router extensibility,” OpenArch 2003, San Francisco, April 2003. [8] Gísli Hjálmtýsson, “Network architecture for distance learning,” report for the Icelandic Ministry of Education, Reykjavik, January 2001. (In Icelandic) [9] Gísli Hjálmtýsson, “Experiments with network architecture for distance learning over a simple IP network,” report for the Icelandic Ministry of Education, Reykjavík, January 2002. (In Icelandic)
