US6845352B1 - Framework for flexible and scalable real-time traffic emulation for packet switched networks - Google Patents

Framework for flexible and scalable real-time traffic emulation for packet switched networks Download PDF

Info

Publication number
US6845352B1
US6845352B1 US09533396 US53339600A US6845352B1 US 6845352 B1 US6845352 B1 US 6845352B1 US 09533396 US09533396 US 09533396 US 53339600 A US53339600 A US 53339600A US 6845352 B1 US6845352 B1 US 6845352B1
Authority
US
Grant status
Grant
Patent type
Prior art keywords
emulation
endpoint
event
flow
emulator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US09533396
Inventor
Jay Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wsou Investments LLC
Lucent Technologies Inc
Original Assignee
Lucent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Grant date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/50Network service management, i.e. ensuring proper service fulfillment according to an agreement or contract between two parties, e.g. between an IT-provider and a customer
    • H04L41/5003Managing service level agreement [SLA] or interaction between SLA and quality of service [QoS]
    • H04L41/5009Determining service level performance, e.g. measuring SLA quality parameters, determining contract or guarantee violations, response time or mean time between failure [MTBF]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/14Arrangements for maintenance or administration or management of packet switching networks involving network analysis or design, e.g. simulation, network model or planning
    • H04L41/145Arrangements for maintenance or administration or management of packet switching networks involving network analysis or design, e.g. simulation, network model or planning involving simulating, designing, planning or modelling of a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/22Arrangements for maintenance or administration or management of packet switching networks using GUI [Graphical User Interface]

Abstract

An implementation framework, including methodologies and the architecture, for a real-time traffic emulation for packet switched networks. The framework uses extended finite state machines to model the traffic flows that are to be emulated. A simple yet flexible FMS-based scripting language is proposed to describe these flows. An event-driven approach to schedule CPU among flows is also adopted.

Description

TECHNICAL FIELD

The present invention relates to traffic emulation for packet-switched networks.

BACKGROUND OF THE INVENTION

Traffic emulation for packet-switched networks is a process in which packet streams, that mimic the characteristics of a real workload, are artificially injected into the target network. Traffic emulation is an important technique in the context of network performance testing since it can potentially preclude the use of a large amount of equipment and of many human testers, which would otherwise be needed in order to facilitate the intended workload for the testing.

An instance of the application that generates traffic to the target network is known as an “application instance”. Each application instance produces a stream of packets among the host computers, or endpoints, that are involved in the application instance. Some examples of application instances are: file download, streaming video and audio broadcast, and voice-over Internet Protocol (IP) telephony calls. Usually, a traffic emulation session involves multiple application instances and each application instance will involve two or more endpoints. By the same token, an endpoint can host several application instances simultaneously.

In the context of workload emulation, a “script” is an executable program that instructs an endpoint to emulate the traffic generated by an application instance. In a typical workload emulation implementation, the scripting language is “command oriented”; that is, a script contains a set of commands and related variables such that the endpoint executes a script by performing one command after another sequentially in an order given in the script. As an example of this, a (sender) endpoint may send a file to another (receiver) endpoint in which the scripts for such an instance may appear as follows:

File Transfer Script for Sender File Transfer Script for Receiver
Endpoint Endpoint
BEGIN BEGIN
FileSize = 1000000;
PacketSize = 100;
DataRate = 100000;
ReceiverAddr = SenderAddr =
“135.104.78.10” “135.104.78.34”
CONNECT_REQ; CONNECT_ACK;
WAIT_ACK;
LOOP LOOP
SEND; RECEIVE;
UNTIL EOF UNTIL
RCVD_DISCON_REQ
DISCONNECT_REQ; DISCONNECT_ACK;
WAIT_ACK;
END END

In this example, the sender endpoint will first request for a connection to the receiver for a transfer of a file that has a size of 1000 thousand bytes. After the receiver acknowledges the request, the connection is established and the sender will then enter a loop in which the endpoint will continuously send packets to the receiver, 100 bytes each, at a rate of 100 thousand bytes per second, until the entire file is transmitted. Then, the connection between the sender and the receiver will be torn down. It should be understood that, in the example set forth above, what is shown here is a simplified, hypothetical scripting language, the purpose being to demonstrate a typical script structure and the fact that a script is a sequences of commands that deal with program execution control (such as LOOP, IF, and GOTO), variable assignment, and actual traffic emulation (e.g., SEND and RECEIVE).

As mentioned earlier, an emulation session usually involves the emulation of multiple active application instances at a given time. A common example may be found in that many telephone calls may be taking place over a network at the same time. In this case, an endpoint needs to execute multiple scripts concurrently, one for each application instance. To achieve such concurrency, a conventional emulation tool will create one “process” (or even “thread”, which is a lightweight process that incurs less overhead than a typical process in terms of CPU cycles and memory) for each script and the emulator will rely on the process management subsystem of the underlying operating system to handle the CPU time-sharing among the scripts. However, in this approach, there are several shortcomings.

One notable shortcoming is limited emulation capacity. Particularly, there is an upper bound imposed by the operating system on the maximum number of processes or threads one can create. This number is usually less than a few hundred. Effectively, this will also be the maximum number of application instances that the emulator can accommodate.

Another shortcoming is poor scalability. Particularly, maintaining processes is expensive in terms of system resources, including CPU time and memory. Although threads are designed to keep such expenditures down, the overhead for a large number of threads can still be significant, which will in turn limit the scalability and the capacity of the emulator.

Finally, another notable problem is the lack of precise timing control. Particularly, since the sharing of CPU time is controlled by the operating system, it becomes difficult, if possible, to control the individual packet departure times, which is often critical for a credible performance analysis for IP-based applications. For example, in a given flow, assume that one may wish to emit one packet for every I millisecond. When many scripts are sharing the CPU and when a packet is due for emission, it is likely that at this moment the CPU is performing some other less urgent task for some other process. The emulator has little control on the CPU time scheduling.

In view of the foregoing, a need has been recognized in connection with providing traffic emulation that obviates the shortcomings and disadvantages discussed above, among others.

SUMMARY OF THE INVENTION

In accordance with at least one presently preferred embodiment of the present invention, a system for providing traffic emulation for packet-switched networks is broadly contemplated, wherein the system includes an endpoint and an emulator module associated with the endpoint, the emulator module including at least one finite state machine for modeling traffic flows to be emulated.

Also broadly contemplated in accordance with at least one presently preferred embodiment of the present invention is a method of providing traffic emulation for packet-switched networks, the method including the provision of an endpoint and of an emulator module associated with the endpoint, wherein the provision of an emulator module includes providing at least one finite state machine for modeling traffic flows to be emulated, and wherein the method further includes modeling traffic flows with the at least one finite state machine.

Other and further features and embodiments of the present invention will become apparent during the course of the following discussion and by reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings,

FIG. 1 is a schematic overview of a system architecture in accordance with an embodiment of the present invention;

FIG. 2 is a schematic overview of an endpoint architecture,

FIG. 3 is a schematic representation of finite state modules;

FIG. 4 is a schematic representation of an emulation manager finite state module; and

FIG. 5 is a schematic representation of a signaling subnet with star topology.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

As employed herein, the term “network” may be construed as referring to a packet-switched network system. Also, as employed herein, the terms “workload” and “traffic” may be considered to be interchangeable.

For the purpose of providing background for the ensuing discussion, traffic to a network may be considered to be a set of flows. Each flow is associated with two endpoints, “source” and “destination”, where, respectively, the traffic is initiated by the source endpoint and terminated by the destination endpoint. It will be appreciated that this does not imply that there will be no packet, particularly control packets, flowing from the destination to the source.

A flow is described by a flow descriptor which contains the following information:

FlowDescriptorId //identification for this flow descriptor
ProtocolType //protocol type, e.g., TCP, UDP, and RTP
SrcIPAddr //source endpoint IP address
DestIPAddr //destination endpoint IP address
MeanIAT //mean packet inter-arrival time
MinIAT //minimum packet inter-arrival time
MaxIAT //maximum packet inter-arrival time
IATDist //inter-arrival time distribution, e.g.,
//Constant, Uniform, Negative Exponential
MeanSize //mean packet size
MinSize //minimum packet size
MaxSize //maximum packet size
SizeDist //packet size distribution
MeanDuration //mean flow duration
MinDuration //minimum flow duration
MaxDuration //maximum flow duration
DurationDist //flow duration distribution

It should be understood that it is not necessary that all attributes in the flow descriptor are needed for a given flow. For example, in the case of a uniform distribution, the mean for the distribution is not needed. By the same token, additional attributes can be included as needed. It should also be appreciated that a flow does not necessarily correspond to a single application instance. Instead, it is possible to aggregate multiple application instances into a single flow for a proper level of granularity such that, as in the example presented further below, one flow in one case may correspond to only one application instance, but may correspond to many application instances in some other cases. So in the former case, the flow has a ‘finer’ granularity while in the later case the flow has a ‘coarser’ granularity.

In the present example, some flow descriptor attributes have to be adjusted accordingly. For instance, if a flow is specified that is an aggregation of 100 voice calls, then the MeanIAT of the flow will be one hundredth of that of a single call.

Turning now to an architecture that may be employed in accordance with at least one embodiment of the present invention, an emulator 100 may preferably include a console 101 and two or more endpoint hosts 102 connected by a target network 104, as shown in FIG. 1. Although essentially any number of endpoint hosts 102 is conceivable, four are shown in FIG. 1 for non-restrictive, illustrative purposes.

The endpoints 102 preferably emulate the intended workload by running the corresponding scripts. Each script specifies the behavior of a half-flow (i.e., either the source end or the destination end). The console 101 is preferably a central controller that coordinates the activities among endpoints 102. The console 101 is also responsible for configuring the emulation and reporting the emulation results to the user through its user interface.

All the packets exchanged among endpoints 102 and the console 101 will preferably fall into two categories: “control” and “data”. A control (or signaling) packet preferably contains a signal that indicates a particular event for a purpose of emulation control. On the other hand, the data packets are preferably the ones that actually emulate the real workload. Typically, the extra load generated by the signaling packets to the network is very small relative to the data traffic. Therefore the impact to the performance caused by the signaling packets is minimal.

As shown in FIG. 2, in order to transport signaling and data traffic, each endpoint 102 preferably has four logical ports: sigIn, sigOut, dataIn, and dataOut. As suggested by their names, the ports sigln and sigout are used solely for input and output of control packets for the endpoint. Similarly, dataIn and dataOut are used exclusively for transmitting and receiving data packets for the endpoint. Preferably, separate logical ports are used for data and control messages because the delivery of control messages has to be reliable (e.g., transmission control protocol (TCP)) while data transportation, depending on the emulated protocol, can be lossy (e.g., UDP). (UDP, or User Datagram Protocol, is part of the TCP/IP protocol suit that provides transport service that is lossy, i.e., with no guarantee of no-loss packet delivery.)

As shown in FIG. 2, a given endpoint 102 a preferably contains two main modules, Network Interface and Emulator, run by three processes. (A remote endpoint is indicated, for illustrative purposes, at 102 b.) In the Network Interface module, there are preferably two processes running in the background responsible for receiving packets from the dataIn and sigIn ports. These two processes will be referred to as the data daemon and signaling daemon. The rest of the system is run on the main process that handles the main emulation work and the sending of packets. Separate background processes are preferably created for receiving data and signaling packets so that waiting for input does not block the normal emulation activities. Although the I/O can be implemented in a non-blocking way, this however requires the process to continuously poll the I/O ports, which causes higher overhead.

Preferably, the emulation employed in accordance with at least one embodiment of the present invention utilizes an event-driven approach. Therefore, a main component in Emulator module is an Event Scheduler that contains an event queue. An Emulation Manager is preferably the main controller which also manages the flows that the endpoint 102 a emulates. The Emulation Manager preferably contains a finite state machine (FSM) that maintains the status of the emulation. Also, for each flow there is preferably a corresponding FSM. The Emulator module and the roles of the FSMs will be described in greater detail further below.

For a console 101 (See FIG. 1), the architecture is preferably very similar to that of the endpoint. However, a console 101 will preferably not include adata daemon (hence the dataIn and dataOut ports either) and the individual flow FSMs. In place of the data daemon, a UI daemon is preferably used, which accepts user's commands, turns them into events, and places them in the event queue along with other events to be processed by the main process. A separate process UI daemon is preferably created so that the user is allowed to initiate an event at any time during an emulation session.

Turning now to FSM-based modeling and scripting, it will be noted that, as mentioned earlier, a script specifies a half-flow. In contrast to a command-oriented language, however, the present invention broadly contemplates, in accordance with at least one preferred embodiment, that the scripting language is based on extended finite state machines (EFSMs). That is, an endpoint will preferably create a FSM according to the corresponding script for each half-flow associated with the endpoint. To illustrate this, reference is made to the concrete example of file transfer discussed in the “Background of the Invention” section:

File Transfer Script for Source Endpoint
ScriptName = FILE_TRANSFER_SOURCE
Role = SOURCE
FlowDescriptorID = FILE_TRANSFER
<BEGIN, CONNREQ, eStart>
<CONNREQ, CONNREQ, eConnReqAck>
<CONNREQ, TRANS, eTransDdata>
<TRANS, TRANS, eTransData>
<TRANS, END, eTearAck>
eStart: remote eConnReq
eConnReqAck: eTransData
eTransData: <EOF? remote eTear: eTransData>
eTearAck: NULL
File Transfer Script for the Destination Endpoint
ScriptName = FILE_TRANSFER_DESTINATION
Role = DESTINATION
FlowDescriptorID = FILE_TRANSFER
<BEGIN, CONNREQ, eStart>
<CONNREQ, CONNREQ, eConnReq>
<CONNREQ, TRANS, eTransData>
<TRANS, TRANS, eTransData>
<TRANS, END, eTear>
eStart: NULL
eConnReq: remote eConnReqAck
eTransData: NULL
eTear: remote e_TearAck

From the above, it may be observed that each script has three sections that, respectively, specify flow variable values, state transitions, and event actions. In the variable assignment section, the user needs to specify whether the script is for the source or the destination endpoint. The user also has to tell the system which flow descriptor the script will use. The second section of the script describes the state transitions. Each state transition will preferably have the following format:

    • <ST1, ST2, eEvnt>

The meaning of the above statement is that if the state machine is currently at a state ST1, then upon the arrival of event eEvnt the state will perform the job associated with the event and take a transition to change its state to ST2.

The state transitions shown here (i.e., both in the above file transfer example and in the state transition format) may be represented graphically as in FIG. 3, where the circles and arrows represent states and events, respectively.

As will be appreciated from FIG. 3, in order to keep the emulation going, an event may have to create another event to drive the state machine. For example, the event eTransData in the source endpoint is involved with forming a data packet based on the corresponding flow descriptor and send it to the destination endpoint. After that, if the flow is not yet complete, then the event has to create another eTransData event to trigger the system to send the next data packet. This is preferably specified in the third section of a script in which each statement has the following format:

    • eEvent [remote] eNextEvnt

The meaning of the above statement is that when the event eEvnt occurs, the system should create another event eNextEvnt after the execution of eevnt. In the case when there is a preceding word ‘remote’, the event eNextEvnt is generated for the “peer” state machine instead of itself Destination endpoint is the peer of the source, and vice versa. In the case of NULL, it simply means that no event needs to be generated (local or remote). The generation of an event can also be conditional as shown in the following example:

    • eTransData: <EOF? remote eTear: eTransData>where the key word EOF represents “end of flow”. Therefore, this statement means that if the condition is true (in this case end of flow), the system should generate a remote eTear event to its peer to request for a session tear down. Otherwise, a (local) eTransData should be generated for the next data packet.

The disclosure now turns to FSM-based event-driven emulation. Particularly, as indicated earlier, the emulation is preferably driven by individual events. In other words, the entire task of emulation is broken up into many small jobs and the execution of each job is triggered by a corresponding event.

An event is preferably implemented by a software object that contains a name, a timestamp, a flow id, and a variable data portion. The event name, for example estart, eConReq, and eTransData, identifies the event. The timestamp indicates the time when the event should be executed. The flow id indicates the associated flow for the event. The data portion of an event is used to store any event-specific data.

At the endpoint, events are queued up in the event queue of the scheduler ordered by their timestamp values. That is, events that have smaller timestamp values will be placed closer to the front of the queue. A new event may be generated locally by the execution of another event or by the arrival of a packet from a remote endpoint or the console. An emulation session proceeds simply with the Emulator continuing to process the first event in the queue until the exit criteria is met, for example, when all flows reach end state.

Preferably, the Emulator, in an endpoint, contains an Emulation Manager FSM and a flow FSM for each half-flow that the endpoint is emulating. An example of a flow Emulation Manager FSM is shown in FIG. 4. On the other hand, flow FSMs are preferably created based on the corresponding scripts, and examples of flow FSMs are shown in FIG. 3.

As shown in FIG. 4, the Emulation Manager FSM, which indicates that an emulation session has three stages (initialization, emulation, and result reporting), is preferably used to maintain the status of the endpoint. The details of each of these stages are explained next.

For initialization, in order to perform an emulation, the user first has to prepare the script(s) and the flow descriptor(s) on the console. After they are ready, the console will distribute them to endpoint(s) by way of eDistribute events. The data in each eDistribute event preferably contains the following information: flow script, flow descriptor, and number of flows so that the event gives the endpoint the flow script and its corresponding descriptor. It also tells the endpoint how many flows should be created using this script. The console will use one eDistdbute event for distributing each script to the target endpoint. During the initialization stage, the endpoint will create a flow FSM for each half-flow, establish proper channels (e.g., TCP, UDP) according to the script for data transportation with its peer(s), and perform any other needed initialization work. At this point, the Emulation Manager FSM will be in the state of Initialization.

Regarding emulation, after all the scripts are distributed to all endpoints and when the endpoints are done with initialization, the console will preferably start the emulation by sending an eStart event to each endpoint. Upon executing the event, the Emulation Manager will pass the event to each of its flow FSMs (see FIG. 2) and take a transition to state Emulation. For each flow FSM, eStart is the first event and it initiates the emulation for the corresponding flow. For the subsequent events that arrived at the endpoint, the Emulation Manager will pass the event to the intended flow (according to the flow id in the event structure). When the end state is reached for all flows, the Emulation Manager will notify the console that the emulation for the endpoint has been completed.

Finally, with regard to result reporting, after all the endpoints have finished their emulation, the console will request that each of the endpoints, by way of eReport event, report the emulation results for each flow it emulated. Upon executing the event, the endpoint will send statistics (e.g., throughput, packet loss rate, and packet delay) to the be console and return to the Active state. After all the endpoints are done, the console will be able to show the collective results to the user.

The disclosure now turns to a discussion of signaling topology, an example of which is shown in FIG. 5. Shown in FIG. 5 are a console 201 and several endpoints 202 in communication with a signaling hub 205.

It will be appreciated that, since the delivery of control messages has to be reliable (i.e., error free, no loss, and preserved sequence), a reliable protocol like transmission control protocol (TCP) may be used. However, because TCP is connection-oriented, this would require an endpoint 202 to establish a TCP virtual circuit (VC) to the console and to each of the associated endpoints 202. Two endpoints 202 are “associated” if they terminate (being either the source or the destination) a common flow. By doing so, in the worse case, there needs to be O(n2) VCs for the entire system, where n is the total number of endpoints. Nontheless, it is not expected that this presents a scalability problem because the number of VCs on each endpoint, each of which is run by a separate host computer, grows only linearly. Otherwise, one may create a star-based virtual signaling subnet 200 as shown in FIG. 5, where all the signaling packages are first sent to the hub 205, which in turn ‘switches’ the packet to the intended recipient. Note that for convenient implementation, the console 201 can also play the role of hub 205. With such a topology, whether or not the console 201 plays the role of hub 205, the total number of VCs is reduced to O(n) although at a cost of a less expeditious control signal delivery due to an extra hop introduced by the topology.

The disclosure now turns to a discussion of several advantages, and some further exemplary details, associated with emulation in accordance with at least one preferred embodiment of the present invention.

One important requirement of an emulator is to be able to emulate multiple flows concurrently simply because in reality many flows can happen simultaneously in the target network. It will be appreciated that it would not be a viable solution to use one physical processor for each flow. To achieve concurrency for emulating multiple flows, a conventional solution is to create and map a process or a thread (a light weight process) to each flow and let the underneath operating system to schedule the CPU time among these processes or threads. However, this approach does not scale because such approach imposes an upper bound on the maximum number of flows that can be emulated (i.e., the maximum number of processes or threads one may create). In addition, it will incur increasing overhead (both CPU time and memory) as the number of flow increases. In contrast, an approach in accordance with at least one embodiment of the present invention will place no such bound and the overhead is independent of the number of flows, since only a small constant number (e.g., three) of processes is used, regardless of the number of flows.

It will be appreciated that one important purpose of an emulation run is to place on the target network some traffic that mimics the real workload in terms of timing and data volume. Therefore, given a flow for the source endpoint, the emulator is to produce a sequence of packets according to the following sequences T=<t1, t2, . . . tn> and S=<s1, s2, . . . sn>, where ti and si, l<=i<=n, are the departure time and the size, respectively, of the ith packet, and n is the total number of data packets in the flow. The closer to S and T the emulator may create and emit packets, the more accurate the emulation is. It should be noted that, in practice, T and S could be derived stochastically or obtained from a trace. For the destination endpoint, the sequence T, on the other hand, represents the actual times when the packets arrive. So for the destination, a typical objective of an emulator is to accurately record the size and the arrival time for each arriving packet (so that throughput, delay, loss ratio, and other performance statistics can be properly derived).

In an approach according to at least one embodiment of the present invention, each packet is created and sent individually based on a triggering event. As a result, one can easily achieve any arbitrary packet size that varies from one packet to another, thus matching S exactly. However, due to a finite CPU power, the same can not be said for T. To be more specific, when the CPU is heavily loaded, a conventional emulator may miss its schedule in injecting a data packet into the network (or picking up from the port for the case of destination). However, the event-driven approach according to at least one embodiment of the present invention facilitates a solution that provides an opportunity to optimize the emulation timing accuracy. A proper process prioritization and a centralized scheduling algorithm, which will be discussed in more details further below, achieve this.

As described earlier, the endpoint software uses three processes, namely the signaling daemon, the data daemon, and the main process. They are preferably prioritized such that the control daemon has a higher priority while the main process and the data daemon has a lower priority. The control daemon is given a higher priority in order to ensure that control messages, which tend to be more urgent, will always be picked up by the endpoint in a timely manner. However, because the volume of control messages is expected to be very small, particularly during the data transmission state, there will be in general no signaling packet for a flow. The effect of signaling packets to emulation results is typically negligible.

Now one may consider the event scheduler on the main process. At any given moment, assume that the timestamp of the first event in the scheduler's event queue is to and assume that the current wall clock time is t. Let ät =t−t0. Then if ät˜0, the Emulator is just on time. Otherwise if ät>0, the Emulator has missed the time schedule for the event. Under both conditions the Emulator should execute the event as soon as possible. On the other hand, if at ät>0, this means the Emulator is ahead of the schedule. In this case, if |ät| is too large, it is undesirable to execute the event immediately because this will result in executing the event prematurely (and hence lead to an inaccurate emulation). Therefore, one may compare a, with a predefined small positive constant called LOOKAHEAD. The value of LOOKAHEAD represents the estimated (wall-clock) time required to process an event before a corresponding data packet (if any) is actually sent by the hardware. The Emulator will execute the event only if d, is approximately equal to LOOKAHEAD. Otherwise, the main process will either put itself asleep (hence giving up the CPU) for some time (or just enter a busy loop if the difference between a, and LOOKAHEAD is smaller then the granularity of the sleep mechanism supported by the operating system) until this condition is met. The event scheduling strategy described here is to maximize emulation accuracy while maintaining good CPU efficiency. It should be noted that, in the implementation this busy-looping mechanism can be made optional so that the user can turn it off to accommodate scenarios when the importance of generator capacity outweighs accuracy. In this case, if the difference between at and LOOKAHEAD is no larger than the smallest possible sleep unit, the Emulator will proceed to process the event.

It is clear that no matter how the CPU is scheduled, when the load given to the emulator exceeds certain limit, the emulator will start to fall behind the execution schedule for its events simply because the CPU power is finite. In particular, this threshold may vary over time since the CPU may not be used exclusively by the emulator. Therefore, it is beneficial that the emulator provides a quantified indication as to how well (or poorly) the timing requirement are met by the emulator in a particular run as a base for validation. For this purpose, one may define two emulation accuracy indexes α and â as follows: α = i = 1 n ( d i - d i ) / n / E ( D ) ,
and
â=|{d′ i |d′ i >d i for i=l . . . }|/n
where di and d′i denote the expecyed departure time and the actual departure time of packed i, respectively, for a given flow. Also, D is the random variable representing the packet inter-departure time for the flow. Therefore, when the value of a increases the accuracy (or the ‘quality’) of the emulation deteriorates. The value of âindicates how often the emulator misses an event's scheduled time in an emulation run. The index a is also useful in helping fine tuning LOOKAHEAD whose optimal value is system dependent.

The emulation in accordance with at least one embodiment of the present invention also allows the user to interact with the endpoints during an emulation session. For example, assume that the user wants to abandon the run or change some parameters (e.g., data rate) of some flows during an emulation. Then the console may issue the command to the endpoint during the run (by embedding the commanding a signaling packet and sending it to the corresponding endpoint(s) through the signaling port). Such interaction is made easy since the flow logic is separated from the logic of general emulation control by creating separate FSMs for flows and emulation management (see FIG. 2). In addition, by giving the control daemon a higher priority, it is ensured that the control command will be handled quickly.

The EFSM-based scripting approach according to at least one embodiment of the present invention allows great flexibility for users to define their application instances. In the simplest case, the emulator may provide some predefined scripts for most popular applications such as ftp and VoIP (i.e., voice over IP calls) so that emulating these applications would require no user programming. For more sophisticated users, the tool may also allow the users to create their own application instances by constructing FSM's that comprise system-defined events (i.e., events whose behavior is defined by the tool) and proprietary events that users create by themselves.

Furthermore, the EFSM-based modeling allows the tool to adopt a graphical user interface that uses the graphical representation of the FSMs (as illustrated in FIG. 3) to display scripts. Potentially, this allows users to maintain their scripts graphically for better user friendliness.

Several possible applications for emulation in accordance with at least one embodiment of the present invention are network testing, flow QoS (quality of service) validation, performance probing and monitoring, and traffic profiling. In the case of traffic profiling, one may use an endpoint to receive a stream of packets and establishes a stochastic profile of that traffic stream, for example, for the purpose of studying the network (queueing) effect to a known traffic source.

Although a traffic generator formed in accordance with at least one presently preferred embodiment of the present invention may be used in a desktop environment, it should be pointed out that the endpoint software could also be integrated directly into the target network (e.g., built into an IP edge router) as an embedded application.

It is to be understood that there exist various modifications to the above-described arrangements that are considered to fall within the spirit and scope of the present invention. Such modifications are all considered to be within the scope of the present invention as defined by the claims appended hereto.

Claims (12)

1. System for providing traffic emulation for packet-switched networks, said system comprising:
an endpoint; and
an emulator module associated with said endpoint;
said emulator module comprising at least one finite state machine for modeling a number of traffic flows to be emulated, said emulator module operable to maintain simultaneous emulation of the number of traffic flows using a constant number of processes, the number of traffic flows being larger than the constant number of processes, the number of processes being small relative to the number of traffic flows that can be emulated, the number of processes required for emulation being independent of the number of traffic flows to be emulated.
2. The system according to claim 1, wherein said emulator module comprises an emulation manager, said emulation manager comprising a finite state machine for maintaining the status of an emulation operation.
3. The system according to claim 2, wherein said finite state machine of said emulation manager comprises three stages, said three stages comprising an initialization stage, and emulation stage and a result reporting stage.
4. The system according to claim 1, wherein:
said endpoint further comprises a network interface module for facilitating the communication of flows to a network; and
said at least one finite state machine comprises a plurality of finite state machines, wherein each finite state machine corresponds to a different one of said flows.
5. The system according to claim 4, wherein said network interface module comprises:
at least one port for receiving data;
at least one port for receiving signals;
a first background process for managing the receipt of data at said at least one data port; and
a second background process for managing the receipt of signals at said at least one signal port.
6. The system according to claim 1, wherein said emulator module further comprises an event scheduler, said event scheduler comprising an event queue.
7. Method of providing traffic emulation for packet-switched networks, said method comprising:
providing an endpoint; and
providing an emulator module associated with said endpoint;
said step of providing an emulator module comprising providing at least one finite state machine for modeling a number of traffic flows to be emulated, said emulator module operable to maintain simultaneous emulation of the number of traffic flows using a constant number of processes, the number of traffic flows being larger than the constant number, of processes the number of processes being small relative to the number of traffic flows that can be emulated, the number of processes required for emulation being independent of the number of traffic flows to be emulated; and
modeling traffic flows with said at least one finite state machine.
8. The method according to claim 7, wherein:
said step of providing an emulator module comprises providing an emulation manager;
said step of providing an emulation manager comprises providing a finite state machine for maintaining the status of said emulation; and
said method further comprising maintaining the status of said emulation with said finite state machine of said emulation manager.
9. The method according to claim 8, wherein:
said step of providing a finite state machine for maintaining the status of said emulation comprises providing three stages, said three stages comprising an initialization stage, and emulation stage and a result reporting stage; and
said method further comprises:
performing each of said three stages in the following sequence: initialization stage, emulation stage and result reporting stage; and
thereafter returning to said initialization stage.
10. The method according to claim 7, wherein:
said step or providing an endpoint comprises providing a network interface module for facilitating the communication of flows to a network; and
said step of providing at least one finite state machine comprises providing a plurality of finite state machines, wherein each said finite state machine corresponds to a different one of said flows.
11. The method according to claim 10, wherein said step of providing a network interface module comprises providing:
at least one port for receiving data;
at least one port for receiving signals;
a first background process for managing the receipt of data at said at least one data port; and
a second background process for managing the receipt of signals at said at least one signal port;
said method further comprising:
managing the receipt of data at said at least one data port with said first background process; and
managing the receipt of signals at said at least one signal port with said second background process.
12. The method according to claim 7, wherein said step of providing an emulator module comprises providing an event scheduler, said event scheduler comprising an event queue.
US09533396 2000-03-22 2000-03-22 Framework for flexible and scalable real-time traffic emulation for packet switched networks Active US6845352B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09533396 US6845352B1 (en) 2000-03-22 2000-03-22 Framework for flexible and scalable real-time traffic emulation for packet switched networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09533396 US6845352B1 (en) 2000-03-22 2000-03-22 Framework for flexible and scalable real-time traffic emulation for packet switched networks

Publications (1)

Publication Number Publication Date
US6845352B1 true US6845352B1 (en) 2005-01-18

Family

ID=33564079

Family Applications (1)

Application Number Title Priority Date Filing Date
US09533396 Active US6845352B1 (en) 2000-03-22 2000-03-22 Framework for flexible and scalable real-time traffic emulation for packet switched networks

Country Status (1)

Country Link
US (1) US6845352B1 (en)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016937A1 (en) * 2000-08-02 2002-02-07 Henry Houh Method and apparatus for utilizing a network processor as part of a test system
US20020016708A1 (en) * 2000-08-02 2002-02-07 Henry Houh Method and apparatus for utilizing a network processor as part of a test system
US20020027925A1 (en) * 2000-08-03 2002-03-07 Sharon Barkai Path discovery in a distributed network management architecture
US20030110208A1 (en) * 2001-09-12 2003-06-12 Raqia Networks, Inc. Processing data across packet boundaries
US20040040010A1 (en) * 2002-04-22 2004-02-26 Kirill Kounik Slowing network connection for application optimization
US20040102942A1 (en) * 2002-11-27 2004-05-27 Opcoast Llc Method and system for virtual injection of network application codes into network simulation
US20040199370A1 (en) * 2003-04-01 2004-10-07 Microsoft Corp. Flexible network simulation tools and related methods
US20040236866A1 (en) * 2003-05-21 2004-11-25 Diego Dugatkin Automated characterization of network traffic
US20050021715A1 (en) * 2003-05-21 2005-01-27 Diego Dugatkin Automated capturing and characterization of network traffic using feedback
US20050113139A1 (en) * 2001-02-20 2005-05-26 Microsoft Corporation Mobile communication device dynamic service application and dynamic service application scripting
US20050198246A1 (en) * 2004-03-08 2005-09-08 Daniel Kegel Simulating a large number of users
US20060025984A1 (en) * 2004-08-02 2006-02-02 Microsoft Corporation Automatic validation and calibration of transaction-based performance models
US7032034B1 (en) * 2002-01-31 2006-04-18 Cisco Technology, Inc. Method and apparatus for simulating large scalable networks
US20060089893A1 (en) * 2004-10-22 2006-04-27 Joseph Vinod C Automated teller machine having access point and method for providing financial service using the same
US20070162602A1 (en) * 2006-01-06 2007-07-12 International Business Machines Corporation Template-based approach for workload generation
US20070260428A1 (en) * 2006-05-05 2007-11-08 International Business Machines Corporation System and method for benchmarking correlated stream processing systems
US20080107104A1 (en) * 2006-11-06 2008-05-08 Jan Olderdissen Generic Packet Generation
US7496035B1 (en) * 2003-01-31 2009-02-24 Cisco Technology, Inc. Methods and apparatus for defining flow types and instances thereof such as for identifying packets corresponding to instances of the flow types
US20090124535A1 (en) * 2007-11-13 2009-05-14 Peter Markland Viscous terpolymers as drug delivery platform
US7564809B1 (en) * 2004-05-06 2009-07-21 Cornell Research Foundation, Inc. Event-synchronization protocol for parallel simulation of large-scale wireless networks
US20100160891A1 (en) * 2008-12-23 2010-06-24 Tipton Arthur J Elastic implantable composites and implants comprising same
US20100158978A1 (en) * 2008-12-23 2010-06-24 Peter Markland Bioactive spray coating compositions and methods of making and uses thereof
US20110010585A1 (en) * 2009-07-09 2011-01-13 Embarg Holdings Company, Llc System and method for a testing vector and associated performance map
US8492512B2 (en) 2010-08-30 2013-07-23 Surmodics Pharmaceuticals, Inc. Process for reducing moisture in a biodegradable implant device
US20130304904A1 (en) * 2012-05-09 2013-11-14 Everbridge, Inc. Systems and methods for metric-based cloud management
US8914432B2 (en) 2001-10-01 2014-12-16 Ixia Real world traffic
US9415197B2 (en) 2008-12-23 2016-08-16 Surmodics, Inc. Implantable suction cup composites and implants comprising same
US9740708B2 (en) 2012-05-01 2017-08-22 Everbridge, Inc. Systems and methods for distance and performance based load balancing

Citations (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5197127A (en) * 1990-09-24 1993-03-23 International Business Machines Corporation Expert system method for performing window protocol-based data flow analysis within a data communication network
US5394540A (en) * 1992-09-08 1995-02-28 At&T Corp. System for testing a network component by selectively modifying messages received from the component and returning to a simulator
US5408465A (en) * 1993-06-21 1995-04-18 Hewlett-Packard Company Flexible scheme for admission control of multimedia streams on integrated networks
US5440719A (en) * 1992-10-27 1995-08-08 Cadence Design Systems, Inc. Method simulating data traffic on network in accordance with a client/sewer paradigm
US5592657A (en) * 1992-05-01 1997-01-07 Johnson; R. Brent Console simulator, multi-console management system, and console management distribution system
US5732213A (en) * 1996-03-22 1998-03-24 Ericsson Inc. System and method of testing open systems interconnection (OSI) layers in telecommunication networks
US5748617A (en) * 1996-05-01 1998-05-05 Mci Corporation Method and apparatus for emulating a digital cross-connect switch network
US5774695A (en) * 1996-03-22 1998-06-30 Ericsson Inc. Protocol interface gateway and method of connecting an emulator to a network
US5809282A (en) * 1995-06-07 1998-09-15 Grc International, Inc. Automated network simulation and optimization system
US5812780A (en) * 1996-05-24 1998-09-22 Microsoft Corporation Method, system, and product for assessing a server application performance
US5838919A (en) * 1996-09-10 1998-11-17 Ganymede Software, Inc. Methods, systems and computer program products for endpoint pair based communications network performance testing
US5881268A (en) * 1996-03-14 1999-03-09 International Business Machines Corporation Comparative performance modeling for distributed object oriented applications
US5889954A (en) * 1996-12-20 1999-03-30 Ericsson Inc. Network manager providing advanced interconnection capability
US5937165A (en) * 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US6134514A (en) * 1998-06-25 2000-10-17 Itt Manufacturing Enterprises, Inc. Large-scale network simulation method and apparatus
US6158031A (en) * 1998-09-08 2000-12-05 Lucent Technologies, Inc. Automated code generating translator for testing telecommunication system devices and method
US6189031B1 (en) * 1998-10-01 2001-02-13 Mci Communications Corporation Method and system for emulating a signaling point for testing a telecommunications network
US6269330B1 (en) * 1997-10-07 2001-07-31 Attune Networks Ltd. Fault location and performance testing of communication networks
US6295518B1 (en) * 1997-12-09 2001-09-25 Mci Communications Corporation System and method for emulating telecommunications network devices
US6363424B1 (en) * 1999-09-01 2002-03-26 Lucent Technologies, Inc. Reuse of services between different domains using state machine mapping techniques
US6393386B1 (en) * 1998-03-26 2002-05-21 Visual Networks Technologies, Inc. Dynamic modeling of complex networks and prediction of impacts of faults therein
US6519228B1 (en) * 1999-12-22 2003-02-11 International Business Machines Corp. System and method of operation for verifying and validating public switch telephone networks (PSTN) to (IP) network services
US6532237B1 (en) * 1999-02-16 2003-03-11 3Com Corporation Apparatus for and method of testing a hierarchical PNNI based ATM network
US6549882B1 (en) * 1998-12-21 2003-04-15 Cisco Technology, Inc. Mechanisms for providing and using a scripting language for flexibly simulationg a plurality of different network protocols
US6560720B1 (en) * 1999-09-09 2003-05-06 International Business Machines Corporation Error injection apparatus and method
US6601195B1 (en) * 1999-09-09 2003-07-29 International Business Machines Corporation Switch adapter testing

Patent Citations (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5197127A (en) * 1990-09-24 1993-03-23 International Business Machines Corporation Expert system method for performing window protocol-based data flow analysis within a data communication network
US5592657A (en) * 1992-05-01 1997-01-07 Johnson; R. Brent Console simulator, multi-console management system, and console management distribution system
US5394540A (en) * 1992-09-08 1995-02-28 At&T Corp. System for testing a network component by selectively modifying messages received from the component and returning to a simulator
US5440719A (en) * 1992-10-27 1995-08-08 Cadence Design Systems, Inc. Method simulating data traffic on network in accordance with a client/sewer paradigm
US5408465A (en) * 1993-06-21 1995-04-18 Hewlett-Packard Company Flexible scheme for admission control of multimedia streams on integrated networks
US5809282A (en) * 1995-06-07 1998-09-15 Grc International, Inc. Automated network simulation and optimization system
US5881268A (en) * 1996-03-14 1999-03-09 International Business Machines Corporation Comparative performance modeling for distributed object oriented applications
US5774695A (en) * 1996-03-22 1998-06-30 Ericsson Inc. Protocol interface gateway and method of connecting an emulator to a network
US5732213A (en) * 1996-03-22 1998-03-24 Ericsson Inc. System and method of testing open systems interconnection (OSI) layers in telecommunication networks
US5748617A (en) * 1996-05-01 1998-05-05 Mci Corporation Method and apparatus for emulating a digital cross-connect switch network
US5812780A (en) * 1996-05-24 1998-09-22 Microsoft Corporation Method, system, and product for assessing a server application performance
US5838919A (en) * 1996-09-10 1998-11-17 Ganymede Software, Inc. Methods, systems and computer program products for endpoint pair based communications network performance testing
US5937165A (en) * 1996-09-10 1999-08-10 Ganymede Software, Inc Systems, methods and computer program products for applications traffic based communications network performance testing
US5889954A (en) * 1996-12-20 1999-03-30 Ericsson Inc. Network manager providing advanced interconnection capability
US6269330B1 (en) * 1997-10-07 2001-07-31 Attune Networks Ltd. Fault location and performance testing of communication networks
US6295518B1 (en) * 1997-12-09 2001-09-25 Mci Communications Corporation System and method for emulating telecommunications network devices
US6393386B1 (en) * 1998-03-26 2002-05-21 Visual Networks Technologies, Inc. Dynamic modeling of complex networks and prediction of impacts of faults therein
US6134514A (en) * 1998-06-25 2000-10-17 Itt Manufacturing Enterprises, Inc. Large-scale network simulation method and apparatus
US6158031A (en) * 1998-09-08 2000-12-05 Lucent Technologies, Inc. Automated code generating translator for testing telecommunication system devices and method
US6189031B1 (en) * 1998-10-01 2001-02-13 Mci Communications Corporation Method and system for emulating a signaling point for testing a telecommunications network
US6549882B1 (en) * 1998-12-21 2003-04-15 Cisco Technology, Inc. Mechanisms for providing and using a scripting language for flexibly simulationg a plurality of different network protocols
US6532237B1 (en) * 1999-02-16 2003-03-11 3Com Corporation Apparatus for and method of testing a hierarchical PNNI based ATM network
US6363424B1 (en) * 1999-09-01 2002-03-26 Lucent Technologies, Inc. Reuse of services between different domains using state machine mapping techniques
US6560720B1 (en) * 1999-09-09 2003-05-06 International Business Machines Corporation Error injection apparatus and method
US6601195B1 (en) * 1999-09-09 2003-07-29 International Business Machines Corporation Switch adapter testing
US6519228B1 (en) * 1999-12-22 2003-02-11 International Business Machines Corp. System and method of operation for verifying and validating public switch telephone networks (PSTN) to (IP) network services

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Melamed, The Performance Analysis Workstation: An Interactive Animated Simulation Package For Queuing Networks, IEEE 1986.* *
Mok et al., An Interactive Graphical Modeling Tool for Performance and Process Simulation, ACM 1993. *

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016937A1 (en) * 2000-08-02 2002-02-07 Henry Houh Method and apparatus for utilizing a network processor as part of a test system
US20020016708A1 (en) * 2000-08-02 2002-02-07 Henry Houh Method and apparatus for utilizing a network processor as part of a test system
US20020027925A1 (en) * 2000-08-03 2002-03-07 Sharon Barkai Path discovery in a distributed network management architecture
US7342893B2 (en) * 2000-08-03 2008-03-11 Sheer Networks Ltd. Path discovery in a distributed network management architecture
US7725103B2 (en) * 2001-02-20 2010-05-25 Microsoft Corporation Mobile communication device dynamic service application and dynamic service application scripting
US20050113139A1 (en) * 2001-02-20 2005-05-26 Microsoft Corporation Mobile communication device dynamic service application and dynamic service application scripting
US20100197327A1 (en) * 2001-02-20 2010-08-05 Microsoft Corporation Mobile Communication Device Dynamic Service Application and Dynamic Service Application Scripting
US20030110208A1 (en) * 2001-09-12 2003-06-12 Raqia Networks, Inc. Processing data across packet boundaries
US9191301B2 (en) 2001-10-01 2015-11-17 Ixia Real world traffic
US8914432B2 (en) 2001-10-01 2014-12-16 Ixia Real world traffic
US7032034B1 (en) * 2002-01-31 2006-04-18 Cisco Technology, Inc. Method and apparatus for simulating large scalable networks
US7346896B2 (en) * 2002-04-22 2008-03-18 Sun Microsystems, Inc. Slowing network connection for application optimization
US20040040010A1 (en) * 2002-04-22 2004-02-26 Kirill Kounik Slowing network connection for application optimization
US7526420B2 (en) * 2002-11-27 2009-04-28 Opcoast Llc Method and system for virtual injection of network application codes into network simulation
US20040102942A1 (en) * 2002-11-27 2004-05-27 Opcoast Llc Method and system for virtual injection of network application codes into network simulation
US7496035B1 (en) * 2003-01-31 2009-02-24 Cisco Technology, Inc. Methods and apparatus for defining flow types and instances thereof such as for identifying packets corresponding to instances of the flow types
US20040199370A1 (en) * 2003-04-01 2004-10-07 Microsoft Corp. Flexible network simulation tools and related methods
US7447622B2 (en) * 2003-04-01 2008-11-04 Microsoft Corporation Flexible network simulation tools and related methods
US20040236866A1 (en) * 2003-05-21 2004-11-25 Diego Dugatkin Automated characterization of network traffic
US8694626B2 (en) 2003-05-21 2014-04-08 Ixia Automated characterization of network traffic
US20050021715A1 (en) * 2003-05-21 2005-01-27 Diego Dugatkin Automated capturing and characterization of network traffic using feedback
US7627669B2 (en) 2003-05-21 2009-12-01 Ixia Automated capturing and characterization of network traffic using feedback
US20110040874A1 (en) * 2003-05-21 2011-02-17 Diego Dugatkin Automated Characterization of Network Traffic
US7840664B2 (en) 2003-05-21 2010-11-23 Ixia Automated characterization of network traffic
US8244891B2 (en) 2004-03-08 2012-08-14 Ixia Simulating a large number of users
US20050198246A1 (en) * 2004-03-08 2005-09-08 Daniel Kegel Simulating a large number of users
US7564809B1 (en) * 2004-05-06 2009-07-21 Cornell Research Foundation, Inc. Event-synchronization protocol for parallel simulation of large-scale wireless networks
US20090187395A1 (en) * 2004-05-06 2009-07-23 Rajit Manohar Event-synchronization protocol for parallel simulation of large-scale wireless networks
US20060025984A1 (en) * 2004-08-02 2006-02-02 Microsoft Corporation Automatic validation and calibration of transaction-based performance models
US20060089893A1 (en) * 2004-10-22 2006-04-27 Joseph Vinod C Automated teller machine having access point and method for providing financial service using the same
US20070162602A1 (en) * 2006-01-06 2007-07-12 International Business Machines Corporation Template-based approach for workload generation
US8924189B2 (en) 2006-01-06 2014-12-30 International Business Machines Corporation Template-based approach for workload generation
US7698106B2 (en) * 2006-05-05 2010-04-13 International Business Machines Corporation System and method for benchmarking correlated stream processing systems
US20070260428A1 (en) * 2006-05-05 2007-11-08 International Business Machines Corporation System and method for benchmarking correlated stream processing systems
US20080228443A1 (en) * 2006-05-05 2008-09-18 International Business Machines Corp. System and method for benchmarking correlated stream processing systems
US8185352B2 (en) * 2006-05-05 2012-05-22 International Business Machines Corporation Benchmarking correlated stream processing systems
US20090024358A1 (en) * 2006-05-05 2009-01-22 International Business Machines Corp. Benchmarking correlated stream processing systems
US7467066B2 (en) * 2006-05-05 2008-12-16 International Business Machines Corporation System and method for benchmarking correlated stream processing systems
US20080107104A1 (en) * 2006-11-06 2008-05-08 Jan Olderdissen Generic Packet Generation
US7616568B2 (en) * 2006-11-06 2009-11-10 Ixia Generic packet generation
US8233399B2 (en) 2006-11-06 2012-07-31 Ixia Generic packet generator and method
US20100040085A1 (en) * 2006-11-06 2010-02-18 Jan Olderdissen Generic Packet Generator and Method
US9090737B2 (en) 2007-11-13 2015-07-28 Surmodics, Inc. Viscous terpolymers as drug delivery platform
US20090124535A1 (en) * 2007-11-13 2009-05-14 Peter Markland Viscous terpolymers as drug delivery platform
US20100158978A1 (en) * 2008-12-23 2010-06-24 Peter Markland Bioactive spray coating compositions and methods of making and uses thereof
US9415197B2 (en) 2008-12-23 2016-08-16 Surmodics, Inc. Implantable suction cup composites and implants comprising same
US20100160891A1 (en) * 2008-12-23 2010-06-24 Tipton Arthur J Elastic implantable composites and implants comprising same
US8974808B2 (en) 2008-12-23 2015-03-10 Surmodics, Inc. Elastic implantable composites and implants comprising same
US20110010585A1 (en) * 2009-07-09 2011-01-13 Embarg Holdings Company, Llc System and method for a testing vector and associated performance map
US9210050B2 (en) * 2009-07-09 2015-12-08 Centurylink Intellectual Property Llc System and method for a testing vector and associated performance map
US8920921B2 (en) 2010-08-30 2014-12-30 Surmodics Pharmaceuticals, Inc. Terpolymer blends and their use as pressure-sensitive adhesives
US9416221B2 (en) 2010-08-30 2016-08-16 Surmodics, Inc. Biodegradable terpolymers and terpolymer blends as pressure-sensitive adhesives
US9598532B2 (en) 2010-08-30 2017-03-21 Surmodics, Inc. Terpolymers as pressure-sensitive adhesives
US8492512B2 (en) 2010-08-30 2013-07-23 Surmodics Pharmaceuticals, Inc. Process for reducing moisture in a biodegradable implant device
US9740708B2 (en) 2012-05-01 2017-08-22 Everbridge, Inc. Systems and methods for distance and performance based load balancing
US9391855B2 (en) * 2012-05-09 2016-07-12 Everbridge, Inc. Systems and methods for simulating a notification system
US20130304904A1 (en) * 2012-05-09 2013-11-14 Everbridge, Inc. Systems and methods for metric-based cloud management

Similar Documents

Publication Publication Date Title
US6757897B1 (en) Apparatus and methods for scheduling and performing tasks
US6789050B1 (en) Method and apparatus for modeling a web server
US6408335B1 (en) Methods, systems and computer program products for endpoint pair based communications network performance testing
Winstein et al. TCP ex machina: computer-generated congestion control
US20090161547A1 (en) Compression Mechanisms for Control Plane-Data Plane Processing Architectures
Spring et al. Receiver based management of low bandwidth access links
US8145760B2 (en) Methods and systems for automatic inference and adaptation of virtualized computing environments
US6061725A (en) Endpoint node systems computer program products for application traffic based communications network performance testing
US20030117959A1 (en) Methods and apparatus for placement of test packets onto a data communication network
Lee et al. Experiences with processor reservation and dynamic qos in real-time mach
Schroeder et al. Open Versus Closed: A Cautionary Tale.
US5881237A (en) Methods, systems and computer program products for test scenario based communications network performance testing
US20030069957A1 (en) Server load testing and measurement system
Munir et al. Minimizing flow completion times in data centers
US7290028B2 (en) Methods, systems and computer program products for providing transactional quality of service
Chung et al. NS by Example
Christin et al. A quantitative assured forwarding service
Kiddle et al. Hybrid packet/fluid flow network simulation
US20080137540A1 (en) Method And Apparatus For Analysing Traffic In A Network
US20100005468A1 (en) Black-box performance control for high-volume throughput-centric systems
US20100040085A1 (en) Generic Packet Generator and Method
US20040034683A1 (en) Differentiated transport services for enabling real-time distributed interactive virtual systems
Wandeler et al. Optimal TDMA time slot and cycle length allocation for hard real-time systems
US20050213507A1 (en) Dynamically provisioning computer system resources
US20040114602A1 (en) Packet scheduling system and method for high-speed packet networks

Legal Events

Date Code Title Description
AS Assignment

Owner name: LUCENT TECHNOLOGIES INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WANG, JAY;REEL/FRAME:010688/0475

Effective date: 20000321

FPAY Fee payment

Year of fee payment: 4

FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12

AS Assignment

Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YO

Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574

Effective date: 20170822

AS Assignment

Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL LUCENT;REEL/FRAME:044000/0053

Effective date: 20170722