Purdue University
`Purdue e-Pubs
`
`Computer Science Technical Reports
`
`Department of Computer Science
`
`2-1-1997
`
`Active Gateway: A Facility for Video Conferencing
`Traffic Control
`
`ShungeLi
`
`Bharat Bhargava
`
`Li, Shunge and Bhargava, Bharat, "Active Gateway: A Facility for Video Conferencing Traffic Control" ( 1997). Computer Science
`Technical Reports. Paper 1349.
`http://docs.lib.purdue.edu/
`cstech/ 1349
`
`This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact epubs@lpurdue.edu
`
`for
`
`additional
`
`information.
`
`INV0009324
`
`Page 1 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`ACTIVE GATEWAY:
`A FACILITY FOR VIDEO
`CONFERENCING TRAFFIC CONTROL
`
`Shunge Li
`Bharat Bhargava
`
`Department of Computer Sciences
`Purdue University
`West LafayUc, IN 47907
`
`CSD-TR 97-011
`February 1997
`
`INV0009325
`
`Page 2 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`Active Gateway:
`
`
`A Facility for Video Conferencing Traffic Control*
`
`Shunge Li and Bharat Bhargava
`
`
`
`Department of Computer Sciences
`Purdue University
`
`West Lafayette, IN 47907, U.S.A
`
`{lis, b b }@cs.purdue.edu
`
`Abstract
`
`Active technology is emerging as one of the most promising fields in networking and
`
`
`
`
`
`
`distributed computing. It permits customized and more flexible control over the underlying
`
`
`
`networks. End users can systematically and strategically study and change the network
`
`
`
`behaviors by programming individual nodes of the network. The functionality of an active
`
`
`network goes beyond the traditional data transmission; each node of an active network
`
`
`has the ability to executing certain programs ( or commands) passing through it. This
`
`
`
`
`
`
`pa.per describes our research work of applying active technology to video conferencing traffic
`
`
`
`
`
`control. We present the architecture and the design of an application-level facility, called
`
`
`active gateway, for video conferencing traffic and quality of service (QoS) control. We
`
`show that this facility enables more control functions for video conferencing which are
`
`
`
`not seen in conventional video conferencing tools. We illustrate its features through several
`
`
`
`
`experiments. Many important issues related to the design of an active network are discussed.
`
`
`
`Some technical solutions and future improvement a.re suggested.
`
`1 Introduction
`
`Recent technological advances in computing has come to a point where human,s understanding of
`
`
`
`
`
`computation model and the way computing should be done are about to change. Computers are
`
`
`
`not stand-alone entities any more. They are networked globally, or at least within an enterprise
`
`
`
`or an organization. On the other hand, people have realized that the computer network itself
`
`
`
`·This research is supported by NSF under grant number NCR-9405931
`
`
`
`INV0009326
`
`Page 3 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`It is no longer just a passive medium for moving data from one
`can function as a computer.
`place to another. It can actively generate, store, exchange, and control information, and can be
`programmed by end users. In other words, it can be a computer itself!
`
`Active technology, under this situation, is emerging as one of the most promising fields in dis(cid:173)
`tributed computing. Under the networking context, each network node is active if it can not only
`perform its traditional
`task of data transmission, but also execute programs or commands passing
`through it. Therefore, end users of an active network can systematically and strategically study
`and change the network's cooperative or non-cooperative behaviors by, for example, injecting to
`each active node a piece of programs in certain way and letting them be executed simultaneously
`to create some useful scenarios that aren't easily repeated in practice. With active technology,
`end users can have more flexible control of the network by programming
`the network as a whole.
`They can conduct scientific experiments repeatedly
`in a more controHable fashion. They can
`also customize the network computing environments by manipulating
`the network resources as
`well as the performance parameters of each node. By programming
`the network routers, end
`users can have better control over the way shared system and network resources are managed.
`Bandwidth mismatch problem among different network links, personalized QoS requirements, as
`well as traffic scheduling, can be handled more easily.
`
`Active network or programmable network also brings to the network community another
`benefit that isn't seen in traditional network systems. Currently, it is difficult to incorporate new
`algorithms or services into routers or switches without going through the complex standardization
`process that can last for at least 5 years. This is due to the fact that whatever new services come
`to the intermediate gateways are expected to have a wide range of applications to build upon and
`therefore must be adopted with care. Active network permits rapid development, deployment,
`and utilization of new network services, protocols, functionalities by giving users the ability to
`programming network nodes and to experimenting
`their new ideas right away.
`
`in networking. For example,
`Active technology opens up a door with many opportunities
`resource management is a big issue in multimedia communications. Resource reservation usually
`results in resource under-utilization. With active technology, bandwidth which has been reserved
`for some application can be temporarily borrowed by other applications needing it if the former is
`not using full amount of reserved bandwidth. This can be easily achieved by forcing the involved
`gateway to run a program that properly marshals the bandwidth among applications.
`
`Active network is a timely service because its ability to executing programs at each node is
`much needed by many application domains: security, multimedia, network management,
`traffic
`control, service customization,
`to name a few. This paper describes our research work of applying
`active technology to video conferencing control. We present the architecture and the design of
`an application-level facility called active gateway. We show that its facility enables more control
`functions which are not seen in conventional video conferencing tools. We illustrate its features
`
`2
`
`INV0009327
`
`Page 4 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`issues related to the design of an active network
`through several experiments. Many important
`are discussed. Some technical solutions and future improvement are suggested.
`
`2 Related Work
`
`An active network isn't something that is different from current networks in its entirety. Some
`forms of preliminary active network capabilities can be found in several products or systems.
`For example, a typical commercial router encapsulates multiple protocol modules that can be
`easily configured by system administrators based on their running environments. This kind
`of configurability
`is very limited compared to the programmability
`the active network offers,
`however, because human knowledge about when and what to configure in the router under a
`certain condition has not been incorporated
`into a program; the corrfiguration task is currently
`performed through human interaction with the router at run time. With active network, we
`can program this human knowledge into the configuration task and launch the program at the
`intermediate routers. Routers will no longer need the system administrators
`to configure them;
`the program does it all.
`
`Similarly, video gateway ([AMZ95]) and mixer mechanism defined in RTP ([SCFJ96]) can
`perform 1 at intermediate network nodes, certain application-level processing functions such as
`transcoding, stream synthesizing, and filtering. Firewalls, Web proxies, and agents are also
`mechanisms that allow fixed sets of processing tasks to be performed at some network nodes.
`The fact that all these technologies are applied within individual end systems and above the
`end-to-end network layer ([TW96]) has led to several recent research activities that leverage and
`extend these technologies for use within the network.
`
`The laboratory for Computer Science at MIT has implemented a network service called Active
`IP Option ([WT96]), in which Tel scripts are embedded in IP packets using IP option fields. Any
`gateway recognizing the special options can interpret and execute the scripts. Others just ignore
`them. With this new service, many traditional networking services, such as finding MTU of a
`remote network link, can be re-implemented
`in a more efficient fashion. More importantly, new
`functionalities can be built upon.
`
`Researchers at MIT also proposed to build an experimental ActiveNet on the Internet ([TGSK96]).
`ActiveNet is intended to be designed as a network infrastructure
`that will serve as a testbed and
`environment for active network researches. It is proposed to be built very much the same way
`the MBone ([Eid94]) was built, that is, through tunneling. This is a cost-effective approach
`because it does not build a separate network. The ActiveNet will be made transparent
`to other
`Internet users as they won't be aware of the existence of the ActiveNet. The Internet and the
`ActiveNet wiJl co-exist, and the Internet will operate as usual. About a dozen institutes have
`agreed to work towards this goal and many other organizations have expressed their interests in
`
`3
`
`INV0009328
`
`Page 5 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`participating
`
`in such a construction.
`
`NetScript ([YdS96]) is another effort by researchers at Columbia University towards build(cid:173)
`ing active programmable networks. The NetScript project focuses on the architecture
`issue for
`programmable network. Each intermediate programmable network node is considered as a Vir(cid:173)
`tual Network Engine (VNE) interconnected by Virtual Links (VL). A VNE is programmed by
`NetScript agents to process packets and route them to other VNEs via some VLs. Agents them(cid:173)
`selves receive services from the Agent Services layer which supports delegation, execution, and
`control of agent programs, as well as communication services among agents. NetScript is a small
`and simple dataflow language specifically designed for communications-based
`tasks.
`
`The idea of active network can be applied to network hardware facility as well. Switch Ware,
`proposed by researchers at University of Pennsylvania and Bellcore, is an instance of active
`network engineering practice [Sea96]. A Switch Ware is a programmable, software-controlled net(cid:173)
`work switch intended to replace the special-purpose switching hardware. It consists of input and
`output ports controlled by a software-programmable element. Sequences of messages contain(cid:173)
`ing programs a.re sent to the SwitchWare switch's input ports, which interpret
`the messages as
`programs.
`
`In this paper, we demonstrate a. practical prototype system that controls video conferencing
`streams via active application gateways. We show that by programming active application
`gateways, we can achieve new control services that would otherwise hardly be achievable with
`traditional video conferencing technology.
`
`3 Active Application Gateways
`
`3.1 Design Methodology
`
`3.1.1 Application Domains
`
`One of the primary objectives for us to develop the facility of active gateways is to build a testbed
`for conducting experiments on real-time multimedia communications. This facility will allow us
`to study these issues in a more controllable and more systematic way. Study of new protocols for
`multimedia communications, new resource management schemes, and new QoS control mecha(cid:173)
`nisms will be largely facilitated through the use of such a facility. However, the facility is not
`just limited to these domains. It can also be used in network management, distributed object
`systems, security, world-wide information systems, etc. In this paper, we focus on its use in video
`conferencing traffic control.
`
`4
`
`INV0009329
`
`Page 6 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`3.1.2 Kernel Implementation
`
`vs. Application-Level
`
`Implementation
`
`We implemented
`following reasons:
`
`the facility of active gateways as an application-level service because of the
`
`1. Because many features of active gateways are in experimental stage, they are expected to
`be added, removed, or updated frequently. Developing them directly within kernels would
`mean frequent kernel changes, compilations, and installations, which are time-consuming
`tasks.
`
`2. An active network provides end users with an ability to customizing the systems for specific
`applications. A specific application, however, usually has specialized requirements
`that
`cannot be generalized to other applications. This highly application-oriented nature makes
`its development and deployment. unsuitable
`to be done in the operating systems' kernels,
`which are supposed to offer services for all applications.
`
`3. Developing active gateways as an application service allows current systems to continue
`operation without being affected by the development process.
`
`4. Most developers don't have access to the kernel source codes, making application-level
`development the only choice.
`
`Not only does the development of active gateways not need to change kernel, it does not re(cid:173)
`quire super-user permission to run it 1 either. In fact, during development process we deliberately
`avoided using those system services that would require root permission. A superuser permission
`requirement limits the usability of a software to a great extent. It may also leave some security
`holes to malicious users. Easy compilation, installation, execution, and great degree of usability
`are what we seek for this software.
`
`3. 1.3 Program Encoding Schemes
`
`role in an active
`The scheme in which a program is encoded or expressed plays an important
`network. A good scheme must support mobility, portability, and efficiency. It may optionally
`support built-in security features, or simply let network protocols to handle the issue.
`
`Mobility not only refers to heterogeneity or platform-in.dependency, but also implies the ability
`to adjusting to running environments of different network nodes. Because a program is expected
`to flow through a number of network nodes on a range of possibly different platforms in an active
`network before it reaches its ultimate destination, either the program encoding scheme must be
`platform-independent or each active node must be capable of doing on-the-fly compilation on the
`program source codes. If the program is expressed in binary code, it may not be recognizable
`by some active nodes unless it also carries binary codes that can be recognized by the nodes.
`
`5
`
`INV0009330
`
`Page 7 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`However, simultaneously carrying binary codes for multiple platforms increases code redundancy
`and wastes considerable network bandwidth. Therefore, although binary encoding scheme is the
`In a heterogeneous
`most efficient one, it works only on platforms with binary compatibility.
`environment such as the Internet, this approach has very limited interoperability.
`
`There are two ways to deal with programs expressed in source code scheme: interpretation and
`on-the-fly compilation. On-the-fly compilation, while achieving the greatest interoperability, has
`severe performance penalty because the nodes must first compile a program and link the object
`code with libraries before they can execute it. This time-consuming process is sometimes not
`affordable for real-time applications. Even though an application is not time-critical, run-time
`compilation usually takes long time, which will result in unpleasant response time. Interpretation,
`on the other hand, allows programs to be evaluated right away without requiring knowledge about
`the binary co de formats of local platforms. For programs of small sizes, it has reasonable response
`time. Furthermore,
`it supports rapid prototyping.
`
`Intermediate code scheme is a compromise between compilation scheme and interpretation
`scheme in terms of efficiency and portability. This approach introduces a concept of Virtual
`Machine (VM), whose intermediate code format is supported universally. Every active node
`recognizes the intermediate code format and has a translation routine that does the mapping
`from the intermediate code format onto binary code format of the local platform. A program
`is compiled and translated
`into the intermediate code format at the dispatcher node before
`this intermediate code into its
`dispatched to active nodes. Each active node then translates
`own binary code which is linkable and executable on its local machine. This approach achieves
`a good balance between portability and efficiency, therefore is the most promising approach.
`The only requirement for this approach to work globally is that every node must support VM
`intermediate code format (e.g., the bytecode format in Java) and must have a Lranslation routine
`to map between its local platform binary code format and the VM intermediate code format.
`
`Therefore, a good candidate of the program encoding schemes must be both platform(cid:173)
`independent and interpretable.
`In addition,
`it must be simple and concise in order to save
`network bandwidth. Many scripting languages, such as Tel ([Ous93)) and Perl ([Lar96)), meet
`these requirements. Java ([GM95]), though not a scripting language, falls into this category well
`due to its Virtual Machine (VM) model. Its nice integration with the World-Wide-Web (WWW)
`and its built-in security features make it especially attractive
`in future deployment of active
`network technology through WWW. Perl, as one of the major languages for Common Gateway
`Interface (CGI) programming in the WWW stage, has been very successful in the WWW world,
`which is by nature heterogeneous. It has great potential towards being developed as one major
`working language for active network. Tel has already been used in the Active IP Option re(cid:173)
`search. Its conciseness, ease to build GUis with, and ease to integrate with C language, make it
`a non-negligible choice as a working language for active network. Other languages, such as ML,
`
`6
`
`INV0009331
`
`Page 8 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`have also been used in active network programming ([Sea96]). (YdS96] developed a dataflow
`language called NetScript as a means for programmable network research. However, they need
`to be further developed towards mobility, portability, and efficiency, in order to be accepted
`globally.
`
`We use Tel scripting language in our development of active gateways due to following reasons:
`
`It took us about one month to build our prototyped (demonstratable)
`1. Rapid prototyping.
`active gateways, though constant improvement is always needed.
`
`into C programming language, which is used to implement major gateway
`2. Embeddability
`functionalities. Tcl's interpreter
`is implemented as a library of C functions that can easily
`be incorporated
`into applications.
`
`flexible
`3. GUI support by .Tk, a companion toolkit of Tel. AccessibHity, customization,
`control, and systematic manipulation of active network imply an easy-to-use and friendly
`GUI.
`
`4. Efficiency and portability. For small programs, Tel achieves reasonably good efficiency.
`Compared to Java-approach, which will be described later, no compilation process is in(cid:173)
`volved. As to portability, Tcl's interpreters are available on most platforms.
`
`3.2 Architecture
`
`of the Active Network
`
`We have constructed an experimental active network prototype on top of our campus network
`environment. The active network consists of a set of active application gateways, a set of end
`systems, and a set of dispatchers, all of which can be placed on arbitrary network nodes. Such
`an active network is virtual because it does not exist physically; it is built on top of conventional
`IP networks. However, it is a network from end users' perceptions because they are not aware
`of the existence of the underlying physical network, which actually delivers dispatched programs
`transparently. They are aware only of the logical entities (e.g., routes, connections) in the active
`network. Creating such a virtual network is useful because it does not change the routers in the
`physical network at all and thus allows them to continue operation without being affected by
`the active network. Figure 1 depicts the relationship between an active (virtual) network and a
`physical network.
`
`To avoid kernel changes within the routers of an active network and superuser permission
`requirement 1 we use UDP instead of raw IP as the basic networking service. Tel scripts, along
`with other meta information (see the next subsection}, are encapsulated
`in UDP datagrams,
`which are in turn delivered in conventional networks.
`
`7
`
`INV0009332
`
`Page 9 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`Figure 1: A Virtual Network and Its Physical Network
`
`Figure 2 shows a simple but typical case of active network setup where an active gateway is
`placed in a network node between two networks each respectively connecting an end system. Also
`connected to the gateway via a separate network is a dispatcher, which serves as an operational
`platform for the active gateway. The dispatcher
`issues programs or scripts
`to the gateway
`over some network and receives from the gateway return messages that report
`the status of
`applications, resource usages, statistical
`information about network traffics, etc. The purpose
`of such a construction
`is to enforce the communication between two end systems to go through
`the gateway, therefore facilitating experimentation. The active gateway can perform traditional
`packet routing function in the logical sense in addition to executing programs dispatched from
`remote dispatcher softwares.
`
`In general, an active network may contain arbitrary number of dispatcher programs and/or
`active gateways in the same physical network at the same time. They can provide services
`to arbitrary number of end systems and can communicate with each other using a built-in
`routing facility. Because the dispatcher programs and the active gateways are implemented at
`application~level, both can be launched as standalone applications from any nodes and run on
`any target machines in the network, allowing easy installation and utilization by end users. In
`practice, only one dispatcher is needed because it can concurrently dispatch various programs to
`as many gateways as possible.
`
`3.3 Communication
`
`Facility
`
`The communication facility in our active network is constructed to support dispatch of programs
`as well as communications among active gateways. An active gateway is responsible for normal
`packet routing as well as handling programs passing through it. A well known port number has
`
`8
`
`INV0009333
`
`Page 10 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`Dispatcher
`
`Nelwork
`
`Sender
`
`Receiver
`
`1---------1
`
`Nel work
`
`1-------1
`
`Network
`
`1---------1
`
`Gateway
`
`Figure 2: A Simple Active Network
`
`been established for application-level packet routing. To demultiplex normal data packets and
`dispatched programs, we designate a separate port number to handle programs flowing through
`active gateways. Any active gateway listening to this particular port will receive program(cid:173)
`embedded UDP datagrams passing through it.
`
`Note that it is possible to share the same port between application data packets and program(cid:173)
`embedded UDP datagrams. However, doing so would require to define a new type field in the
`packet header. For every application
`the active gateway wants to support, its packet structure
`has to be updated to incorporate this type field. Specifying a separate port number for dispatched
`programs would provide a more general mechanism that can work with as many applications as
`possible while minimizing modifications that have to be made to the applications.
`
`into UDP datagrams and dispatched to the network. Besides
`Tel scripts are encapsulated
`the scripts themselves, also included in UDP datagrams are extra control and meta information
`such as program encoding scheme, routing and addressing information, meta information about
`the scripts (length, constants, environment variables, parameters).
`For security reasons, the
`Tel-scripts (or any other programs) need to be encrypted using some cryptographic scheme such
`as public key cipher. Meta information therefore may also contain digital signatures and public
`keys. These information are packaged as a message header of the Tel scripts and are placed at
`a layer above UDP (table 1).
`
`3.4 Components
`
`of Active Gateways
`
`runs as a
`An active gateway is currently implemented with two threads. The Tel interpreter
`thread and the router, which performs normal functions of routing, event handling, scheduling,
`
`9
`
`INV0009334
`
`Page 11 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`Table 1: Format of Script-Embedded UDP Datagrams Dispatched to Active Gateways
`
`I UDP Header I Meta Data / [Encrypted] Tel Script /
`
`Input Packet Queues
`
`Data Packets
`
`Programs/Scripts
`
`Interpreter
`
`Packet Router
`
`Packet Scheduler
`
`Resource Manager
`
`Output Packet Queues
`
`Figure 3: Components of An Active Gateway
`
`runs as the other. Figure 3 shows the components of an active gateway.
`
`3.4.1
`
`Routing Tables
`
`The most basic functionality a gateway performs is packet routing. Each active gateway has its
`own built-in routing table that is controllable by end users through program dispatching. This
`routing table specifies logical routes in the active network, not physical routes in underlying
`physical network. For example, one hop away (from A' to C) in an active network may be
`several hops apart (from A to C) in an actual physical network (figure 1). Users of the active
`network are unaware of the routing operations performed in the underlying network; instead,
`they are aware only of the routing operations performed in the active network.
`
`From implementation point of view, the routing table of an active gateway is no difference
`from that of a conventional IP gateway. For each destination IP address, it contains the IP
`
`10
`
`INV0009335
`
`Page 12 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`address of the next hop gateway (in the logical sense). The routing table at each active node
`(hosts as well as intermediate gateways) is configurable through some primitives and is consulted
`to determine the next logical route to send the UDP datagrams
`to. The content of the routing
`table can be changed at any time by the active node by executing programs dispatched to it.
`This logical facility allows end users to easily perform application-specific
`traffic flow control
`without changing physical routes for other applications. Packets of other applications are routed
`the same way as if there were not active gateways in the network.
`
`3.4.2
`
`Primitives
`
`Primitives are the smallest programmable units that can perform the most basic functionality
`for a specific application in an active network. They form a base from which all the application's
`control functions can be derived. In this paper, we are not intended to define primitives for
`the active network's control language. Rather,
`the primitives we are talking about here are
`application-oriented.
`
`Our primitives can be categorized into two classes:
`
`primitives. These are are basic operations involving communications
`• Communication
`among active network nodes. Examples include operations on routing table (setting, chang(cid:173)
`ing, or removing routes), network resources (setting bandwidth), network QoS (querying
`link latency, throughput), and application QoS (querying delay,jitter, connection informa(cid:173)
`tion).
`
`that deal only with
`primitives. These are are basic operations
`• Non-communication
`the local entities such as resources. Examples include operations on resource management,
`scheduling, priorization, policy, etc. Also provided are primitives regarding time event
`management,
`including invoking an event or a procedure at a particular
`time, delaying an
`event by a time interval, etc.
`
`3.4.3
`
`Policies
`
`Policy-based control mechanism is a must for many distributed systems and applications. QoS
`control in real-time multimedia communications
`is by definition policy-based simply because
`there does not exist a single universal control scheme that works for all cases.
`
`In terms of
`Policies used in active gateways can be classified based on different criteria.
`functionality, they can be classified as control policy and scheduling policy; in terms of the way
`they are defined and dispatched, they can be classified as static policy and dynamic policyi and
`in terms of generality, they can be classified as application-specific policy and general policy.
`
`11
`
`INV0009336
`
`Page 13 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`Control policies deal with how to perform a certain type of control. For example, a control
`policy may define which packets should be dropped or which connections ( or channels) should
`be closed when the available network bandwidth falls below a threshold. Scheduling policies
`deal with how to schedule system and network resources. For example, a scheduling policy may
`state how to allocate and schedule resources among multiple connections. Static policies are
`predefined. Dynamic policies are defined and dispatched by end users on-the-fly.
`
`Active gateways support many control policies and scheduling policies that can be either
`static or dynamic or both. During initialization, an active gateway loads predefined policies.
`During execution of a program, a newly defined policy can be taken into effect by replacing
`the current policy. This dynamic reconfigurability of policies can be programmed in Tel scripts.
`Each policy has a unique policy number and is implemented as a Tel procedure. Therefore, a
`policy can be overwritten by redefining the corresponding Tel procedure on-the-fly.
`
`3.4.4 GUI
`
`A graphical user interface (GUI) has been designed and implemented for the dispatcher software
`to make its operations easy. It serves as a software platform for launching Tel-scripts on active
`gateways. It greatly facilitates our experimentation.
`
`Our GUI consists of a control panel (a set of control buttons/scales),
`an information panel
`reporting network status or statistical
`information, a text-editable window for users to type in
`commands/scripts
`and to dispatch to the gateways for execution. Menu bars and accelerate
`keys are also provided to facilitate and speed up operations. A graphical panel that can picto(cid:173)
`rially show state/status
`information is to be added to enhance the visualizability of information
`presentation.
`
`3.4.5
`
`Events
`
`Many events are encountered in a real multimedia communication session. They include data
`loss, data corruption, and retard of data delivery. To study their effects on QoS, a mechanism is
`needed to control the generation of these events.
`
`Active gateways support many operations other than routing. These events include dropping
`a packet, delaying the delivery of a packet by a certain amount of time, recording a packet, cor(cid:173)
`rupting a packet, and transcoding a packet. The purpose of supporting
`these special operations
`at intermediate gateways is to simulate various network service models and traffic models on
`a more controllable network environment such as a campus network. Often, communications
`with UDP in LANs witness less or no data loss. Even in a lossy environment,
`the quantity of
`the loss rate is hard to control. By dropping packets flowing into an intermediate gateway with
`certain probability, we introduce a loss rate into packet delivery over a specific link. Also, many
`
`12
`
`INV0009337
`
`Page 14 of 27
`
`Implicit Exhibit 2012
`Juniper v. Implicit
`
`

`

`infrequently-occurred events can be re-produced as many times as we want. With this approach,
`coupled with active technology, data loss or other events becomes more controllable, manageable,
`and programmable.
`
`these special events systematically.
`to generate
`An event generator has been implemented
`Associated with each event is a routine that implements the semantics of that event. These
`routines will be called when corresponding events are activated. The event generator follows a
`proba