Read gateway-paper-submitted.pdf text version

An Application Level Gateway for Interactive Remote Instruction

A. Abdel-Hamid, S. Ghanem, K. Maly, H. Abdel-Wahab, C. M. Overstreet, J. C. Wild, A. Gupta, W. Farag, B. Koodallur Department of Computer Science, Old Dominion University Norfolk, VA 23529-0162, USA {hamid, ghanem, maly, wahab, cmo, wild, ajay, farag, kooda_b}@cs.odu.edu Abstract

IRI-h (for Interactive Remote Instructionheterogeneous) is a Java-based cross-platform distributed education instruction system for heterogeneous network environments. In this paper, we introduce the design and operation of an application level gateway that is seamlessly integrated within IRI-h's architecture to handle class participants with no multicast connectivity or limited bandwidth such as home users. A gateway prototype is fully implemented in Java and tested within an experimental lab setup. Preliminary performance results indicate the effectiveness and feasibility of our design. used to teach a semester-long computer science course across 2 sites 20 miles apart. IRI-h gateways (GW) are included in IRI-h sites to support class participants with no multicast capabilities or limited bandwidth such as home users by offering data packet relaying and rate adaptation services [1]. A gateway is a session independent machine that can serve simultaneous ongoing sessions. Figure 1 illustrates a possible IRI-h session involving 2 high-bandwidth multicast-enabled sites, and 2 multicast-disabled session participants that require gateway services. Please note that a site can have one or more designated gateway machines.

Keywords: distance learning, multicast gateway, rate

control, Java.

Directory Server Site1 Site2

Multicast Intranet

1. Introduction

IRI-h is a platform independent interactive remote instruction system for heterogeneous network environments. It offers a synchronous virtual classroom environment with audio, video, and tool sharing capabilities [8]. A particular IRI-h class meeting is called a session, and might consist of multiple virtual rooms. A client-server architecture is adopted between several session participants (SP) and a central session manager (SM) for exchanging control and state information. In contrast, a scalable multicast-based group communication model is used for data streams within deployed services. Available IRI-h services for class participants include audio, video, tool-sharing, annotations, and pointer services. IRI-h services use shared resources that are allocated and managed through the SM, e.g., group communication channels. Group communication channels are allocated through a group communication server (GC server) within the SM. A Directory Server (DS) provides a lookup service of currently active IRI-h sessions. SMs are required to register with the DS upon startup, and to maintain connectivity during the lifetime of the session. Later, an SP-startup component can query the DS to decide which session is to be joined. An IRI-h prototype [4] was fully implemented in Java [5], and effectively

SP1 SM

SP3 SP2

GW

GW

unicast UDP TCP connection SP4

SP5

Figure 1: A typical IRI-h session. At the time of this writing, we have implemented a prototype for a Java-based gateway that has been seamlessly integrated into IRI-h's architecture. The prototype has been tested in an experimental lab setup on multiple platforms including Unix machines running the Solaris operating system, and PCs running Windows 2000. Preliminary performance results are promising in terms of GW load (how many session participants can be serviced

1

by a single gateway machine) and the introduced data stream delay due to gateway processing. Targeted class participants requiring gateway service are home users with the increasingly available high-speed connections such as xDSL and cable modem technologies. In this paper, we describe the design and software architecture of IRI-h gateways along with interactions with the session manager and session participants. In addition, we explore how rate control and media scaling can be performed within the gateway. Several multicast gateways have been introduced in the literature, including mTunnel [9], rtp gateway [3], a multicast gateway for ISDN lines [7], and UTG (the UCL Transcoding Gateway) [11]. Such gateways are not adequate for use within IRI-h because of their lack of features such as the availability of a "session gateway" that can handle multiple IRI-h services in which some of the streams are not RTP-based [10] and the ability to simultaneously service multiple gateway clients with varying quality of service. Due to lack of space, the reader is referred to the corresponding references for design and operational details. The paper is organized as follows. Section 2 presents an IRI-h operational overview in the presence of gateways. Section 3 introduces the gateway design and describes the gateway components responsible for data packets relay and rate adaptation services. Finally, section 4 concludes the paper along with some future work discussion.

2. Operational Overview

Each IRI-h site has one or more designated gateway machines that can support multiple ongoing sessions. Gateway machines are session independent representing a shared resource for IRI-sessions. Furthermore, a physical limitation exists on gateways placement on the edges of the network, hence their independence from sessions and session managers that can be started on any machine within IRI-h's Intranet. However, an implicit requirement is that a gateway machine be part of the multicast Intranet, i.e., is capable of receiving multicast streams generated by IRI-h multicast-enabled participants. A session manager is provided the list of currently designated gateways through command line parameters or through an automated startup procedure. In the latter case, designated gateways are selected through a web interface from an IRI-h Intranet configuration file [8]. The SM then establishes TCP connections to all the identified gateways. Such TCP connections are used to pass requests from the SM to the GW and to monitor the availability of the GW during the life of the session. The list of gateways that a SM is able to connect to constitutes a list of currently active gateways that is supplied to a newly connected SP as part of a participant startup protocol [1]. When allocating a new multicast-based group communication

channel the SM requests the creation of a corresponding gateway server (GS) from each active gateway. Gateway servers are gateway components that can provide data packet relaying and rate adaptation services for multicastdisabled participants or participants with limited connectivity bandwidth. The contact information of a GS is stored in the group communication server database for subsequent retrieval by session participants requiring gateway service. A SP performs a multicast capability test using the provided list of GWs and chooses its candidate GW based on a minimum round trip time selection criterion [1]. Each GW provides to a connecting SP its "multicast capability test" multicast group and port. This multicast group is formed as a function of the GW IP address, e.g., a GW with IP address "a.b.c.d" will have a test multicast group of "226.b.c.d". The SP sends back to the SM its multicast capability test result and candidate GW. Before using a group communication channel from within a multicastdisabled SP, the group communication server database is queried and the contact information for the corresponding GS is retrieved. This contact information is used to establish a transit TCP connection to the corresponding GS in order to identify which UDP ports the SP/GS will use in order to send/receive data packets for this group communication channel. Since a SM needs to be informed of any newly invoked gateways after its startup, GWs are required to register with the directory server upon startup. The directory server uses a push strategy where any currently active session managers are informed of the newly invoked GW. The SM, in turn, attempts to establish connection to this GW, and if successful adds it to its list of active GWs, and informs currently connected SPs of the newly available GW. A SP needs to be informed if its servicing gateway becomes unavailable during the life of the session. Hence, the SM uses its GW permanent TCP connection to sense if a GW becomes unavailable and informs all session participants serviced by that GW. In this case, each affected SP attempts to recover by choosing a new candidate GW, if available, and subsequently performs the UDP ports identification process.

3. Gateway Design

The gateway design is influenced by the following gateway operational requirements: serve multiple ongoing sessions possibly with multiple virtual rooms; serve multiple gateway clients with dynamically varying quality of service; and smooth out peak bit rates, e.g., bursts from tool-sharing data streams generated from within highbandwidth sites. Figure 2 depicts the design of an IRI-h gateway. Session managers and session participants act as gateway clients submitting client requests. A Client Request

2

Manager handles such requests and relays the request to either a SP services manager or a SM services manager. A session manager can request the allocation of a GS to service one of its group communication channels. In order to service multiple ongoing sessions, a GS is identified by the following components: <SM machine address, SM port, virtual room number, service-type> with the assumption that a unique service type is assigned to services within the same virtual rooms. Table 1 summarizes gateway services available to session participants.

Gateway

Client request manager

SP services manager

SM services manager

Gateway servers

Dynamic thread creation

Thread relationship

Figure 2: The design of an IRI-h gateway. Service Name Multicast capability test Round Trip Time Test Retrieve original video stream sender (section 3.1) UDP ports identification process Description Classify a SP as being multicast-enabled or disabled. Calculate the round trip time between the SP and the GW. Gateway queries its gateway servers to identify the original sender of a video stream. Identify which UDP ports will be used by SP/GS to send/receive data packets for this group communication channel. Provider Gateway

Gateway

Gateway

Gateway Server

Table 1: Gateway services offered to session participants.

3.1. Gateway Servers Design and Operation

Gateway servers handle a specific multicast-based group communication channel and hence are supplied with the multicast group and port used for this channel in the highspeed multicast-enabled Intranet. A SP requiring gateway service connects to a GS and performs a UDP ports selection process as outlined in Table 1. The set of all SPs that performed the UDP ports identification process, in

addition to the high-speed multicast group, become the clients of this GS. In essence, when a GS receives a new datagram packet from one of its clients, it extracts the payload of the packet and encapsulates this payload into datagram packets destined for each individual serviced client except the originating client. In summary, the GS functions as a payload relay server generating n-1 datagram packets in response to an incoming packet, assuming n is the current number of clients. Such datagram packet processing is the same whether the data packet was received from a multicast group or from one of the SPs currently serviced by this GS. In addition, it does not preclude the GS from serving other SPs that are multicast-enabled but only require rate limiting or media transcoding. Gateway Servers are characterized by the corresponding service type for this group communication channel. Tool-sharing, layout management, pointer, and annotation services require generic gateway servers. However, video, and audio services are RTP-based [8], and hence require an RTP gateway server. In our current prototype, RTP gateway servers are implemented using the Java Media Framework (JMF) [6]. Adopting a relay approach creates a problem for video window identification for purposes of layout management within the SP's interface. A video window identifier is based on the originating sender machine IP address. Obviously a video stream received at the multicast-disabled SP will be identified as originating from the GW and not from the original video sender. To solve this problem, an identified video sender at the SP is inspected to determine if it is a gateway machine, and if so is contacted to retrieve the original video sender machine name corresponding to the relayed RTP stream. To provide such lookup functionality, each GS stores the SSRC (Synchronization Source) [10] for each generated RTP stream. Another functionality of gateway servers is to perform rate limiting or media transcoding, if required, to cope with the expected limited connectivity bandwidth for home users. For example, a video gateway server might drop video frames, or transcode the incoming video stream to a less bandwidth-consuming video format. Tool-sharing and video streams are the most bandwidth consuming streams within IRI-h services [8]. IRI-h video streams use a JPEG capture format, hence can be rate limited by dropping entire video frames. The necessity of format transcoding is left for future research. The tool-sharing data stream requires a buffering and flow-control approach in order to effectively implement rate limiting and smooth peak bit rates (bursts).

4. Conclusions and Future Work

In this paper, we presented the design and operation of IRI-h gateways that cater for IRI-h class participants with no multicast connectivity or limited connectivity

3

bandwidth. At the time of this writing we have implemented a Java-based gateway prototype. Design features described in this paper, but not yet implemented include the GW rate control and bandwidth management policies. We tested our prototype gateway within an experimental lab setup in which one gateway machine handled 4 multicast-disabled clients in the presence of one toolsharing stream and 2 video streams. CPU consumption by the gateway process was in the range of 15 to 25 percent. We are currently in the process of establishing a test bed to evaluate IRI-h's performance using currently available high-speed home connections such as xDSL, and cable modem technologies. Future work includes implementing rate control and bandwidth management policies within our gateways. For efficient GW operation, a bandwidth allocation and adaptation strategy [2] would have to be in place. Such a strategy would guarantee that the GW does not exceed the bandwidth of its output pipe and the total bandwidth relayed to a specific session participant does not exceed the SP's actual connectivity limits. We will explore the use of semantic information to guide the intelligent dropping of data to reduce bandwidth when necessary and the addition of priorities to relayed data streams. For instance, an audio stream is usually more crucial to a session participant than a video stream. Furthermore, we intend to research the effect of delays introduced by buffering and flow control on the interactivity feature that distinguishes our IRI-h system.

Educational Resources in Computing (JERIC), Vol. 1, No. 1, Spring 2001. [9] P. Parnes, K. Synnes, and D. Schefstrom, "mTunnel: a Multicast Tunneling System with a User based Quality-ofService Model", in Proceedings of The 4th European Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services (IDMS'97), Darmstadt, Germany, September 1997. [10] H. Schulzrinne, et al., " RTP: A Transport Protocol for Real-Time Applications", Request For Comments (Proposed Standard) 1889, Internet Engineering Task Force, January 1996. [11] J. Yang, "Accessing MBone Sessions over N-ISDN", Merci Project Technical Report, Computer Science Department, University of College London, UK, August 1997. Available online at URL http://wwwmice.cs.ucl.ac.uk/multimedia/projects/utg.

References

[1] A. Abdel-Hamid, S. Ghanem, K. Maly, and H. AbdelWahab, "The Software Architecture of An Interactive Remote Instruction System For Heterogeneous Network Environments", in Proceedings of the 6th IEEE International Symposium on Computers and Communications (ISCC'2001), pp. 694-699, Hammamet, Tunisia, July 2001. E. Amir, S. McCanne, and R. Katz, "Receiver-driven Bandwidth Adaptation for Light-weight Sessions", in Proceedings of ACM Multimedia 97, Seattle, WA, November. 1997. E. Amir, S. McCanne, and H. Zhang, "An Application Level Video Gateway", in Proceedings of ACM Multimedia 95, San Francisco, CA, November 1995. IRI-h Home Page, at URL http://www.cs.odu.edu/~iri-h. Sun's Java Home page, at URL http://java.sun.com. Java Media Framework (JMF) Home page, at URL http://java.sun.com/products/java-media/jmf/index.html. C. Kuhmünch, "A Multicast Gateway for Dial-In Lines", Technical Report TR-98-004, Dept. of Mathematics and Computer Science, University of Manheim, Germany, July 1998. K. Maly, H. Abdel-Wahab, C. Wild, C.M. Overstreet, A. Gupta, A.Abdel-Hamid, S. Ghanem, A. Gonzalez, and X. Zhu, "IRI-h, A Java-based Distance Education System: Architecture and Performance", ACM Journal of

[2]

[3]

[4] [5] [6] [7]

[8]

4

Information

4 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

1036596


You might also be interested in

BETA
rfc3261.dvi