APPARATUS AND METHOD FOR TESTING NETWORK APPLICATIONS
FIELD OF THE INVENTION
The present invention relates to an apparatus and method for testing
network applications, and more particularly but not exclusively to testing
applications for use with wide area networks (WANS) and with the Internet.
BACKGROUND OF THE INVENTION
In recent years there has been considerable growth, in use of WANs and
the Internet. This growth has been both in terms of the number of people and
organizations using such facilities and also in terms of the network capacity taken up by the various applications. The past few years have also noted the appearance and spread of applications such as the Internet phone which require
the reliable transfer of data in real time.
All three of these developments have led to vast increases in the quantity
of data on the Internet, and all regular users are aware that there are times of the
day when Internet traffic is very slow and real time applications become all but
impossible to use.
An organization setting up a connection between different sites will wish
to be certain that the connection will be able to support its applications at all times
of operation. This applies whether the organization intends to use the Internet for
its connection or whether it is designing its own WAN and wishes to decide on the
necessary design capacity.
At present there is known a system for testing the capacity of a network to support an application. It is possible to model a network using three parameters, a maximum bandwidth, a time delay and a percentage loss of data packets. The system uses a fixed set of parameters obtained from general experience of the Internet and the parameters can be changed by the user if he feels that the system does not accurately represent the connection being tested.
A problem with this system is that the parameters of a real network change with time, sometimes quite rapidly. An application that passes the test using the above system may fail in actual use on the network because, for a small percentage of the time, the connection between two specific points on the network varies markedly from an expected value. Alternatively the very fact that values are changing may affect performance.
In response to the latter point it is known, not to provide the system with specific parameters but rather with a time-variant set of parameters. This, however, still does not deal with the problem of radical and unexpected changes and furthermore does not deal adequately with the behavior patterns of specific networks or of specific routes on a given network. In particular it does not deal adequately with attempts to set up a connection between two points via the Internet.
SUMMARY OF THE INVENTION
According to a first aspect of the present invention there is provided a system for modeling a network. The system is associated with a location on the network and comprises a sending device for sending data units from the system location to a second, predefined location on the network and arranging the units to return to the system location, a receiving device for receiving the units on their return to the system location, a measuring device for measuring the delay between the sending of the unit and the receipt of the same unit by return, and a counter for counting the number of units that do not return, a network parameter reconstructor for reconstructing, from the measuring device and from the counter, parameters of the network, and a modeling device adapted to utilize the reconstructed parameters to model the network. The sending device is preferably operative to send data units at predefined intervals over a preset period.
An array may be built up of delays of succeeding units and may provide parameters for the modeling of the network. A particular advantage of the invention is that it is able to model the Internet effectively, however it is applicable to any other type of communication network as well. The invention is useful in determining the performance of a network application having predefined functions. The application would be combined with the system as described above and one or more of the predefined functions of the application would be carried out in the normal way, as if the application were connected to the network. As the system is built in behind the network driver the application believes it is operating normally with the network but, instead of the packets being output to a genuine network they are output to the model and dealt with according to the
retrieved parameters. Thus the user receives an indication as to actual performance of the system on the network based on the time delays and loss rates in the delivery of packets and is able to see from this whether the use of the particular application over the given network is feasible or not. According to a second aspect of the present application there is provided a system for modeling a network, the system being associated with a first location on said network and comprising a network performance reporting module for obtaining parameters from a network and a cloud module for incorporating the parameters obtained from the network performance reporting module to form a model of the network, the network performance reporting module being characterized in that it comprises a sending device for sending data units from the first location to a second, predefined location on the network and arranging the units to return to the first location, a receiving, device for receiving the units on their return to the first location, a measuring device for measuring, the delay between the sending of the unit and the receipt of the same unit by return, a counter for counting the number of units that do not return, and a modeling device adapted to model a network in accordance with the measured delay of the measuring device and the count of the counter.
The units may be data packets in a standard format and the sending device may be operative to send data units at predefined intervals over a preset period. The array may be built up of delays of succeeding units and may be usable to provide parameters for the modeling of the network.
The system may be embodied on a computer. The system may also be embodied on several computers. For example the modeling device may be embodied on a separate computer from the rest of the system.
BRIEF DESCRIPTION OF THE DRAWINGS
For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which, Figure 1 shows a part of a network such as the Internet,
Figure 2A shows a path that a communication may take through a series of routers,
Figure 2B shows how the path of figure 2A is considered in a cloud model, Figure 3 shows a typical distribution of delay times for data packets following a path across a network,
Figure 4 shows a model according to an embodiment of the present invention,
Figure 5A shows a standard network application, and Figure 5B shows how an embodiment of the present invention may be added to the application of figure 5A.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
Figure 1 shows a part of a network. A series of endpoints 10.1 - 10.3, which represent individual users, or in the case of the Internet, Internet service providers, are connected to a network via gateways 12.1 - 12.3. Linking the gateways are individual routers 14.1 - 14.8 whose task it is to read the addresses of data packets and to direct the packet to the most appropriate of the neighboring routers for the given destination. For example Router 2, when faced with a message for endpoint 10.2, should know that it must direct the message to Router 3 and not to Router 4. If it does send it via Router 4 then Router 4 should send it via Router 6 and Router 9, and Router 9 should know to direct it via Router 8 to ensure that it reaches the correct endpoint.
Figure 2A shows a path that an actual message may take through a series of routers. Each router takes two parameters, one is the percentage of packets lost over this part of the network and the second is the delay time introduced over this part of the network. The routers are treated as nodes of the network. The parameters of each node will change rapidly, especially during periods of heavy use of the network and it is not feasible to keep track of the parameters of every single node.
Figure 2B shows how the network may be modeled. It is modeled as a cloud which has parameters which are the sum of the individual parameters of the routers. The parameters of the cloud are more stable than the parameters of individual routers for messages being sent over any appreciable number of routers because statistical effects begin to appear. Thus it is feasible, as has been done in the prior art, to use a model of this sort, with sets of predetermined
parameters, to model the behavior of the network. This works well up to a point, but as mentioned above, cannot deal effectively with data intensive communications needing to work in real time because standard sets of parameters do not really deal with the effects of short term but exceptionally large scale fluctuations at individual routers. For that matter standard sets of parameters do not deal with specific conditions applying to the individual route that the user is interested in.
There is currently known a utility called "ping", based on the ICMP protocol, which is used to check the viability of Internet connections. The "ping" or another like utility, sends a data packet to the desired address. The data packet is immediately returned from the desired address to the sender and the sender is thus able to know that the connection is viable and is able to determine the time delay over the connection.
Embodiments of the present invention use a variation of the "ping" utility to determine the actual time-variant parameters of the network for use in the model of figure 2B. A series of "pings" are transmitted over the connection under test at regular intervals, for example every half second, and the returning data packets are used to build up a graph of delay times. A data loss parameter is calculated from the number of packets that do not return. It will be appreciated that the actual parameters used in the model are half the values obtained because the packets traverse the network twice. However the fact that each packet traverses the network twice gives additional statistical soundness to the results.
A typical graph of delay times that might be obtained using the above described means is shown in figure 3.
The graph that is drawn up can then be used to provide time varying
parameters for the model of figure 2B, and the model of figure 2B can be used to
test applications under the expected conditions of actual use.
Figure 4 shows how the model of figure 2B may be implemented and how it may obtain and use parameters obtained from the network.
The model shown in figure 4 consists of three principal modules, a
gateway module 20, a cloud module 22 and an Internet performance recording module 24. The gateway module models the gateway to the Internet and takes
the following parameters, up-link bandwidth, down-link bandwidth and bucket (or
buffer) size. The bucket size is the maximum buffer size offered by the
connection and presents a challenge, particularly to real time applications. The
maximum number of data packets that can be sent to the network is limited by the up-link bandwidth. The remainder must be queued in the buffer. Data packets
that arrive when the buffer is full are simply lost.
The cloud module 22 is the model of figure 2B, and takes as its
parameters the latency, that is the delay in delivery of packets over the
connection, and packet loss, as discussed above. Module 24 is the Internet performance recording module and its task is to
obtain the data for the graph of figure 3. It takes parameters from the user as
follows, a target address, the length of time for which parameters are needed, and
the sampling interval. It then proceeds to operate a "ping" utility repeatedly at the set rate over the set time interval. The parameters are recorded, in a form
functionally equivalent to figure 3, and the results are used as the parameters for the cloud module 22.
In embodiments of the invention there are two ways that the cloud module selects parameters from the graph of figure 3. The first method is to proceed sequentially through the graph. The second method is to select parameters by making random jumps through the graph. The second method models a network with particularly high jitter, that is to say with sharp changes in the delay and such a test is particularly important for real time data which is very vulnerable to such behavior from a network. Cloud software includes two components, an application and a driver.
The driver is where execution of the simulation is carried out. A typical networking architecture may allow for three basic types of driver, adapters, protocols and intermediate drivers. In a standard system, as shown in figure 5A, a TCP/IP driver 30, used for communication via the Internet, is shown bound to an adapter driver 32. Figure 5B shows an Internet communication of the type shown in figure 5A which has been adapted for the purposes of the present invention. In figure 5B the modeling software of the invention is installed as an intermediate cloud driver 34 which is located between the TCP/IP driver 30 and the adapter driver 32. The adapter driver 32 and the TCP/IP driver are both unaware of the existence of the cloud driver 34 and in this way it is ensured that the protocol behavior does not change.
There is thus achieved a means of accurately modeling a network connection, including an Internet connection, using parameters taken from the
network itself. The behavior of the module can be controlled by the user and the model is applicable to a wide variety of networks.
It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention is defined only by the claims that follow: