EP1444808A2 - Dispositif et procede d'analyse resau a prediction autonome - Google Patents

Dispositif et procede d'analyse resau a prediction autonome

Info

Publication number
EP1444808A2
EP1444808A2 EP02793213A EP02793213A EP1444808A2 EP 1444808 A2 EP1444808 A2 EP 1444808A2 EP 02793213 A EP02793213 A EP 02793213A EP 02793213 A EP02793213 A EP 02793213A EP 1444808 A2 EP1444808 A2 EP 1444808A2
Authority
EP
European Patent Office
Prior art keywords
router
class
network
routers
sources
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.)
Withdrawn
Application number
EP02793213A
Other languages
German (de)
English (en)
Inventor
François BACCELLI
Dohy Hong
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.)
N2NSOFT
Original Assignee
Institut National de Recherche en Informatique et en Automatique INRIA
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
Application filed by Institut National de Recherche en Informatique et en Automatique INRIA filed Critical Institut National de Recherche en Informatique et en Automatique INRIA
Publication of EP1444808A2 publication Critical patent/EP1444808A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/147—Network analysis or design for predicting network behaviour

Definitions

  • the invention relates to the monitoring and simulation of complex systems.
  • [1] proposes a formula for evaluating the throughput of a source controlled by TCP as a function of the probability of packet loss.
  • [2] proposes a representation in so-called "MAX-PLUS” algebra of complex systems, such as communication networks, and in particular flow and congestion control.
  • This "MAX-PLUS” algebra makes it possible to integrate the random nature of the parameters of the networks, while considering a plurality of nodes.
  • [2] takes into account only one source using a protocol of the TCP type.
  • [3] and [4] is proposed an elementary model allowing to apprehend the joint evolution of the rates of a set of TCP sources sharing a common router.
  • the proposed additive growth and multiplicative decrease (AIMD) model makes it possible to assess the performance degradation due to loss synchronization in the shared router.
  • AIMD additive growth and multiplicative decrease
  • one parameter remains unknown: the probability function of this synchronization.
  • the models offered are limited to the representation, either of several routers and a single controlled source, or of a single router shared between several sources controlled by TCP.
  • the monitoring and simulation systems of these networks controlled by TCP are not autonomous when predicting the throughput obtained by the sources. That is to say that they cannot get rid of the need for physical observations made on a real network such as for example that of the probability of losses in [1] or [2], or the law of synchronizations in [3] or [4]; in turn, these can hardly cover all possible cases with a reasonable degree of reliability, especially on a wide area network.
  • the invention improves the situation.
  • the invention relates to a method for testing and predicting the behavior of a computer network, comprising the following steps: a. memorize on the one hand a representation of the network, comprising routers, their own transmission properties, and transit times between routers, on the other hand a configuration of use of the network comprising traffic classes, for each of these classes is associated with a number of sources and a path through the routers, b. from the initial conditions chosen, repeatedly apply a traffic evolution model, of the additive growth and multiplicative decay type, to simulate an evolution of flows in the network, by memorizing each time a set of flow variables of classes or sources, and c. if repeating step b. produces a periodic orbit, returning appreciably to a set of flow variables of the classes or sources already encountered, examine the series of routers encountered, as responsible for the losses to evaluate the flow obtained by each class or source.
  • the invention also relates to a device for testing and predicting the behavior of a computer network.
  • the device comprises - a memory for storing: * network parameters including routers, their own transmission properties, and transit times between routers,
  • network usage configuration parameters including traffic classes, each of these classes associated with a number of sources and a route through the routers,
  • FIG. 1 illustrates a computer device comprising a processing module according to the invention
  • FIG. 2 illustrates a computer network made up of routers shared between a set of sessions
  • FIG. 3 represents a flowchart of the simulation method for a network analysis according to the invention
  • FIG. 4 shows the graph of the evolution of the average speed in a router belonging to the path of a class.
  • Appendix A includes the network parameters, source parameters, and model variables to which the description below refers.
  • Annex B includes steps for calculating algorithms linked to a model to which the description below refers.
  • Appendix C includes estimates of the synchronization rate under certain assumptions.
  • Annex D contains the mathematical formula to which the description below refers.
  • v [j] designates an array or vector variable ("array") having a value for each value of j.
  • array an array or vector variable having a value for each value of j.
  • FIG. 1 illustrates a computer environment comprising a central unit 1 connected to a screen 7 and input means 6 such as a keyboard or a mouse.
  • the central unit 1 is also connected to a GUI graphics card 2 adapted to control the display of data on the screen 7.
  • the central unit 1 is suitable for working in relation to the processing module 3 connected to memory 4.
  • Memory 4 stores data linked to the network representation 8 and data 9 linked to the configuration of use of the network. These data will be described more fully below.
  • the memory 4 includes a calculation module 5 which works in correspondence with the processing module 3.
  • This processing module 3 is capable of repeatedly applying a traffic evolution model, of the additive growth and multiplicative decrease type, to simulate an evolution throughputs in the routers of the network.
  • the processing module is specific to request a memorization of a set of flow variables in the network so as to predict the next epoch of congestion and to remedy the expected congestion.
  • the description relates in particular to the prediction of the performance of flows, for example of the TCP type, and the quantity of service (QoS) in a multi-router topology.
  • the device and the method of the invention are used inter alia when a large number of sources controlled by a protocol, of the TCP type for example, share several routers.
  • This simulation is based on a fluid description of the additive growth and multiplicative decrease (AIMD) type model.
  • AIMD additive growth and multiplicative decrease
  • FIG. 2 illustrates a computer network of the type used in the invention.
  • the network consists of several routers rO, ri, r2, r3 and r4, the router rO being an access router.
  • the routers are linked together by links such as Tl connects rO to r3, T2 connects rO to r2, T3 connects r3 to r4, T4 connects rO to r4, T5 connects r3 to r4, T6 connects rO to ri.
  • Sources 1, 2, 3 referenced by II, 12, 13 and destinations 1, 2, 3 referenced by Dl, D2, D3 are represented in FIG. 2.
  • the sources are connected to the network by the access router rO.
  • the destinations are linked to the network by an access router r4, r2, r3 respectively.
  • a class "type" corresponds to the set of classes defining the same path and or the same end-to-end path of a class (appendix A2-3).
  • a class "type" corresponds to the set of classes defining the same path and or the same end-to-end path of a class (appendix A2-3).
  • For a connecting journey one of the sources S to D3, at least two types of class are again defined, the type of class defining the path (T5) and the type of class defining the path (T4, T3) and passing through the intermediate router r4.
  • a class is defined by a path, a type of session, propagation delays and a number of sources.
  • the classes are designated by the variable s and the routers are designated by the variable r.
  • the same source can be designated as being a source of class s and a source of class s 'if the classes s and s' each define a path going from the same source to the same destination as previously illustrated but having a different session.
  • there are several sources for the same class that is to say several sources whose path is identical to reach their destination.
  • Congestion time n designates an instant n at which the flows of each class s are calculated (flows equal to the flow of each source i of class s). This "congestion time n” also designates an instant for which a network router is said to be “congested” or in “congestion state", that is to say a router which will have one or more packet losses.
  • the network parameters designate the parameters of the routers defined in Al-1, Al-2, Al-3, Al-4, Al-5.
  • the routers can be of different types such as for example: - of the FIFO (Fird In First Out) or FQ (Fair Queing) type designating types of routers liable to lose packets in queue overflow, also called Tail Drop,
  • AIMD additive growth and multiplicative decrease
  • FIG. 3 illustrates an exemplary embodiment of a simulation method for a network analysis according to the invention.
  • the process refers to appendices A, B, C and D related to the AIMD traffic evolution model proposed as an example.
  • each element of the matrix p [s, r] designates a probability of synchronization of packet losses, called synchronization rate defined between 0 and 1 which is here assumed to be predefined according to Bernoulli's law.
  • the value of the random variable gamma [s, r] equal to 0.5 signifies a probability law of the "head or toe" type, - in BO-2, each element of the vector c [r] designates the capacity (in packets per second) that a source could have from a router if the total capacity of this router was ideally shared between the sources using this router r,
  • each element of the matrix a [s, r] designates a proportion of the number of sources of class s on the number of sources using the router r, - in BO-4, each element of the vector m-rtt [r] denotes the sum over s of a [s, r] each divided by their minimum round trip time of the class considered squared,
  • each element of the matrix g [s, r] designates an integer between 0 and 1 calculated as a function of the synchronization rate
  • the initialization phase consists in initializing the average flow rates for all classes and for all periods of congestion n varying from 1 to N (n and N being integers), with the function f () given describing the initial condition.
  • tau_l [r] of step 1, defined in appendix B0, must be positive or zero. This means that the initial charge must be compatible with the capacities of the network.
  • the formulation B0-1 is predefined in the case where the following assumption is made: - the routers have a buffer memory of zero size.
  • the type of router used is of FIFO type and in A2-2, the type of session is of FTP type.
  • Steps 410, 420, 430 represent the iteration of appendix B1-0 on each time of congestion of steps 1, 2 and 3 defined below.
  • V step 1 in annex Bl-1 defines, for each router r at a time of congestion n, a sum of the class source bit rates over all the classes according to the time of congestion n-1.
  • som_n [r] represents the total load (or bit rate) on the router 'r' at the end of the previous iteration (during the first iteration, som_l [r] represents the total load on the router 'r' defined by the initial condition).
  • the calculation of tau -n [r] defines a time between the given time of congestion n-1 and the consecutive time of congestion n, called virtual inter-congestion time for each router r.
  • tau_n [r] is the virtual duration of the inter-congestion of router V which would be effective if for example all the other routers were of infinite capacity (c [r]).
  • U step 2 of annex Bl-2 makes it possible to determine the minimum inter-congestion time over the set of virtual inter-congestion times of the routers r, also called inter-congestion time of the network tau_n.
  • This minimum inter-congestion time designates the time between the old time of congestion and the current time of congestion.
  • the value of tau_n gives the n-th inter-congestion duration of the network.
  • step 420 a processing of average flow rates is carried out for each class s.
  • step 2 of appendix B1-2 it is calculated in (1) the average current flow x_n [s] of each class s at the n th epoch of congestion.
  • (1) applies the linear growth mechanism (AI developed in the documents presenting the AIMD model) to all sources.
  • the absolute date of the nth network congestion is given by the time value j n.
  • n th router or congested router at time n whose virtual inter-congestion time is equal to the inter-loss time of the network and which belongs to the class path (also called end-to-end path of the class)
  • the new average flow x_n [s] of each class s defined at the time of congestion n This new calculated average speed x_n [s] is lower than the previous average speed to avoid congestion, packet loss or other at the level of the congested router (s) at the time of congestion n.
  • the new average bit rate x__n [s] is calculated based on the synchronization rate and the corresponding old average bit rate.
  • (2) of appendix Bl-3 applies to the sources crossing the congested router the mechanism of multiplicative decrease (MD) of the mechanism AIMD on average.
  • step 430 it is checked that the calculated flows correspond to a state of the flows already encountered beforehand or that the number of iterations of steps 410 and 420 reaches a determined number of iterations (number defined by the variable Max_iter of Y step 0 in Bl-0). In the case of a negative response, the iteration of steps 410 and 420 continues to determine the next minimum inter-virtual time of the routers and the corresponding bit rates.
  • This iteration of steps 410 and 420 illustrates the mathematical formula of appendix D comprising sums on the classes for calculating the inter-congestion time of a router, a minimum to be found among the inter-congestion times of the routers and these operations are repeating for each time of congestion.
  • the average flow rates are calculated using the synchronization matrix represented by ⁇ n + 1 .
  • the vector recurrence equation has a solution (under certain assumptions) which is a periodic orbit in step 440.
  • the theory guarantees the uniqueness and the existence of 'such an orbit finished. Indeed, if congestions (causing losses) occur very often on each router, a single solution exists to the equation of appendix D which has a finite period n independent of the initial conditions of the vector x_n []. This solution is defined as a so-called periodic orbit because it would be found in the case of a new cycle of iterations.
  • this orbit can be determined using a traffic evolution model other than the additive growth and multiplicative decrease type model.
  • step 450 the average flow rates are analyzed.
  • instantaneous flows are calculated by a stochastic approach if the number of sources per class is high (SN).
  • the instantaneous flow rates are calculated from the sequences of average flow rates obtained.
  • the instantaneous rates X_n [s, i] are calculated according to formula B2-1 in which the inter-congestion time of the network at time n is added to the previous instantaneous rate X_ ⁇ n-1 ⁇ [s, i] and this for each class s and for each source i.
  • the new instantaneous speed X_n [s, i] is calculated according to the formula B2-2.
  • the random variable gamma [s, r] corresponds to the ratio of the flow rates X_n [s, i] just after and before congestion.
  • Max_iter When a periodic orbit is found before a maximum number of iterations, Max_iter, the results on the steady state result from the exploitation of the orbit thus obtained. Results on the transient regime (for example the time required to reach the steady state) can also be obtained. If the iteration stops when a maximum number of iterations is reached, Max_iter, without a periodic orbit being found, it is visually possible to observe if the steady state is approximately reached by plotting the evolution of x_n. In the case where this visualization is difficult, a transient regime is obtained which is always usable. In this case also, the convergence time towards the steady state is greater than the simulation time time_ ⁇ Max_iter ⁇ .
  • a typical value for the maximum number of iterations is between 10 3 and 10 6 depending on the size of the network and the number of sources.
  • the graph of evolution of the average speed x in a router belonging to the path of a class s is an illustration of the average speeds calculated on a number of iterations equal to 4.
  • the average flow rate of class s is x-1.
  • the average speed is calculated at point A.
  • the virtual inter-congestion time of the router considered is equal to the inter-congestion time of the network between the epochs of congestion 1 and 2.
  • the average bit rate x-2 of the router is calculated as a function of the synchronization rate and corresponds to point A '.
  • the average speed at point B is calculated the average speed at point B.
  • the virtual inter-congestion time of the router considered is equal to the inter-congestion time of the network between the epochs of congestion 2 and 3.
  • the average bit rate x-3 of the router is calculated at point B 'as a function of the synchronization rate.
  • the average speed at point C is calculated.
  • the virtual inter-congestion time of the router is not equal to the inter-congestion time of the network between the periods of congestion 3 and 4.
  • the average speed x-4 is that calculated at point C.
  • the average speed of the router considered is equal to the inter-congestion time of the network between the epochs of congestion 4 and 5.
  • the average speed of the router is calculated at point D 'as a function of the synchronization rate.
  • this average bit rate x-5 is equal to the average bit rate x-1, and the same is true for the other classes to which this router belongs and for other routers on the network, a set of mean bit rate value defines l '' periodic orbit sought.
  • each instantaneous flow X-n [s, i] takes the value of a function F (s, i). This value is either a given fixed value or a value obtained by random drawing.
  • the iteration of appendix B4-0 corresponds to the iteration of steps 1, 2 and 3 of appendices B4-1, B4-2, B4-3.
  • the value of the maximum number of Max_iter iterations varies depending, for example, on the duration over which the network (time_ ⁇ Max_iter ⁇ ) is studied or practical constraints, such as simulation time. As before, a posteriori graphical visual observation provides an idea of whether or not you have reached steady state.
  • step 1 of appendix B4-1 calculates the virtual inter-congestion times of each router, the bit rates x_n being stochastic (in 0b).
  • V step 2 of appendix B4-2 calculates the virtual inter-congestion time of the network and, in (lb), the current instantaneous flow X_n [s] of each class s at the n th period of congestion, (lb) applies from all sources the linear growth mechanism (AI developed in the documents presenting the AIMD model).
  • step 3 of appendix B4-3 the multiplicative decay mechanism (MD) of the AIMD mechanism is applied to the instantaneous bit rates of the sources passing through the congested router (in 2b).
  • Algorithm 3 corresponds to algorithm 2 in which algorithm elements preceded by a star have been added.
  • the following variables have also been added regarding the router buffer: - bb_n [r]: intermediate queue size in step n.
  • - tauO_n [r] represents the tau_n [r] of algorithm 2, that is to say the virtual inter-congestion time obtained if the other routers are of infinite capacity c [r] and if the router 'r' considered n has no buffer.
  • step 0 of appendix B5 the algorithm elements added to algorithm 2 are the initialization to zero of the queue sizes bb_n [r] and bn_n [r].
  • step 1 of appendix B5-1 the calculation of a virtual inter-congestion time of a router at the time of congestion n takes into account the virtual inter-congestion time of the router without buffer memory and the calculation of the intermediate queue size of the router.
  • step 2 of appendix B5-2 after the calculation of the inter-congestion times of the tau_n network at the times of congestion n and the updating of the flow rates, the queues bn-n [r] are put on the next day that, for a given period of congestion n and a router, the network inter-congestion time is greater than the time tau0_n [r] or not.
  • the synchronization rate instead of being predefined, is estimated in the following. Several estimates are possible.
  • the variables of the formula Cl-1 are calculated from the as follows: -the probability L of packet loss is calculated according to Cl -2 and - delta [s, r] is calculated as a proportion of round trip time rtt [s] of a class s which depends on the position of the router r.
  • the random variable gamma [s, r] is determined according for example to Bernoulli's law as previously seen. Assuming the rate-dependent synchronization (RI case), the synchronization rate is calculated by an approximation of the C2-1 type.
  • the synchronization rate is estimated for each router and for each class to which this router belongs.
  • the random variable gamma [s, r] is determined according to for example a linear model, or a model depending on the flow rate in an exponential or polynomial manner.
  • the method described assumes given the network parameters and the parameters of each TCP source.
  • the device and the corresponding method can have the following typical applications.
  • Direct application is the prediction of connection performance for a typical user in a given network configuration.
  • the performance sought is for example the average speed obtained by a user, and more generally a guaranteed speed during a certain percentage of the connection time, a loss rate or any other values which depend on the temporal fluctuation of the instantaneous flow.
  • Another direct application is the creation of an optimized TCP traffic generator.
  • the invention covers the software product comprising the functions used in the test method.
  • the invention also covers the software product defining the elements of the processing module of the device according to the invention.
  • the sources are of the HTTP type.
  • the synchronization rate is directly estimated by independent simulation.
  • the routers are of the fair queing (FQ) type.
  • Al-1 N_Router number of routers
  • A1-3 B router buffer size (unit in packet / s);
  • N_Router transmission delay (pure propagation);
  • A3 -5 tau_n n-th network inter-congestion time
  • : (c [r] - somjn [r]) / (m_rtt [r]);
  • X_n [s, i]: gamma [s, r] * X_n [s, i];
  • ⁇ tau_n [r]: (c [r] - som_n [r]) / (m_rtt [r]);
  • X_n [s, i]: F (s, i);

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de test et de prédiction du comportement d'un réseau informatique. Ce procédé comprend; a.mémoriser une représentation du réseau, comprenant des routeurs, et une configuration d'usage du réseau comprenant des classes de trafic chacune associée des sources; b. à partir de conditions initiales (400), appliquer répétitivement un modèle d'évolution du trafic (410, 420) de type croissance additive et décroissance multiplicative, pour simuler une évolution de débits dans le réseau, en mémorisant à chaque fois un jeu de variables de débits des classes ou des sources; et c. si la répétition de l'étape b. produit une orbite périodique (430), revenant sur un jeu de variables de débits des classes ou des sources déjà rencontré, examiner la suite des routeurs rencontrés, comme responsables des pertes pour évaluer le débit obtenu par chaque classe ou source (450).

Description

Dispositif et procédé d'analyse réseau à prédiction autonome
L'invention concerne la surveillance et la simulation de systèmes complexes.
Dans le cadre du contrôle de flux et de congestion dans des réseaux de communication, notamment de type Internet, on cherche, par analyse du débit, à déterminer l'impact des paramètres du réseau. Différentes propositions ont été faites. On retiendra, parmi les plus avancées:
[1]- Mathis, M. Semske, J. Mahdavi, J.Ott, T.(1997) "The Macroscopic Behavior of the TCP
Congestion Communication Review", 27(3), n°4155, juillet 97,
[2]- le brevet WO 01/65 772 Al,
[3]- Baccelli, F. and Hong, D. "A.I.M.D., Fairness and Fractal Scaling of TCP Traffic", Technical Report, RR-1455, INRIA Rocquencourt, avril 2001,
[4]- Hong, D., Lebedev D., "Many TCP User Asymptotic Analysis of the AIMD Model",
Technical Report, RR-4229, INRIA Rocquencourt, juillet 2001.
[1] propose une formule pour évaluer le débit d'une source contrôlée par TCP en fonction de la probabilité de perte de paquets.
[2] propose une représentation dans l'algèbre dite "MAX-PLUS" de systèmes complexes, tels que des réseaux de communication, et notamment du contrôle de flux et de congestion. Cette algèbre "MAX-PLUS" permet d'intégrer le caractère aléatoire des paramètres des réseaux, tout en considérant une pluralité de noeuds. Toutefois, [2] ne prend en compte qu'une seule source utilisant un protocole de type TCP.
Dans [3] et [4] est proposé un modèle élémentaire permettant d'appréhender l'évolution jointe des débits d'un ensemble de sources TCP partageant un routeur commun. Le modèle de type croissance additive et décroissance multiplicative (AIMD) proposé permet d'évaluer la dégradation des performances due à une synchronisation des pertes dans le routeur partagé. Toutefois, un paramètre reste inconnu : la fonction de probabilité de cette synchronisation. En outre, les modèles proposés sont limités à la représentation, soit de plusieurs routeurs et d'une seule source contrôlée, soit d'un seul routeur partagé entre plusieurs sources contrôlées par TCP.
De plus, les systèmes de surveillance et de simulation de ces réseaux contrôlés par TCP ne sont pas autonomes quand à la prédiction du débit obtenu par les sources. C'est à dire qu'ils ne peuvent pas s'affranchir de la nécessité d'observations physiques faites sur un réseau réel comme par exemple celle de la probabilité de pertes dans [1] ou [2], ou la loi des synchronisations dans [3] ou [4] ; à leur tour, celles-ci peuvent difficilement couvrir avec un degré raisonnable de fiabilité l' ensemble des cas possibles, notamment sur un réseau étendu.
L'invention vient améliorer la situation.
L'invention concerne un procédé de test et de prédiction du comportement d'un réseau informatique comprenant les étapes suivantes: a. mémoriser d'une part une représentation du réseau, comprenant des routeurs, leurs propriétés propres de transmission, et des temps de transit entre routeurs, d'autre part une configuration d'usage du réseau comprenant des classes de trafic, à chacune de ces classes est associé un nombre de sources et un trajet à travers les routeurs, b. à partir de conditions initiales choisies, appliquer répétitivement un modèle d'évolution du trafic, de type croissance additive et décroissance multiplicative, pour simuler une évolution de débits dans le réseau, en mémorisant à chaque fois un jeu de variables de débits des classes ou des sources, et c. si la répétition de l'étape b. produit une orbite périodique, revenant sensiblement sur un jeu de variables de débits des classes ou des sources déjà rencontré, examiner la suite des routeurs rencontrés, comme responsables des pertes pour évaluer le débit obtenu par chaque classe ou source.
L'invention concerne également un dispositif de test et de prédiction du comportement d'un réseau informatique.
Dans une caractéristique principale de l'invention, le dispositif comprend - une mémoire pour stocker: * des paramètres du réseau comprenant des routeurs, leurs propriétés propres de transmission, et des temps de transit entre routeurs,
* des paramètres de configuration d'usage du réseau comprenant des classes de trafic, à chacune de ces classes associé un nombre de sources et un trajet à travers les routeurs,
* un module de calcul selon un modèle d'évolution du trafic, de type croissance additive et décroissance multiplicative,
- un module de traitement propre à:
* à partir de conditions initiales choisies, appliquer répétitivement le modèle d' évolution du trafic, de type croissance additive et décroissance multiplicative, pour simuler une évolution des débits dans le réseau, en mémorisant à chaque fois un jeu de variables de débit des classes ou des sources,
* arrêter l'application répétitive du modèle d'évolution du trafic lorsqu'une orbite périodique revenant sensiblement sur un jeu de variables de débits des classes ou des sources déjà rencontré est obtenue
* examiner la suite des routeurs rencontrés, comme responsables de pertes pour évaluer le débit obtenu par chaque classe ou source.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, ainsi que des dessins annexés sur lesquels:
- la figure 1 illustre un dispositif informatique comprenant un module de traitement selon l'invention,
- la figure 2 illustre un réseau informatique constitué de routeurs partagés entre un ensemble de sessions,
- la figure 3 représente un ordinogramme du procédé de simulation pour une analyse réseau selon l'invention,
- la figure 4 représente le graphe d'évolution du débit moyen dans un routeur appartenant au trajet d'une classe. L'annexe A comprend les paramètres de réseau, les paramètres de sources et les variables du modèle auxquels la description ci-après fait référence.
L'annexe B comprend des étapes de calcul d'algorithmes liés à un modèle auxquelles la description ci-après fait référence. L'annexe C comprend des estimations du taux de synchronisation suivant certaines hypothèses.
L'annexe D comprend la formule mathématique à laquelle la description ci-après fait référence.
Les dessins et les annexes contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.
La description ci-après se réfère à la publication [2] en ce qui concerne un modèle de type croissance additive et décroissance multiplicative (AIMD) utilisé. Ce modèle élémentaire permet d'appréhender l'évolution jointe des débits d'un ensemble de sources TCP partageant un routeur commun sur un réseau informatique.
Dans la description, la notation v[j] désigne une variable tableau ou vecteur ("array") ayant une valeur pour chaque valeur de j. On parlera de matrice pour une variable à deux dimensions v[i,j].
La figure 1 illustre un environnement informatique comprenant une unité centrale 1 reliée à un écran 7 et des moyens de saisie 6 tel un clavier ou une souris. L'unité centrale 1 est également reliée à une carte graphique GUI 2 adaptée pour piloter 1 ' affichage de données sur l'écran 7. Selon l'invention, l'unité centrale 1 est propre à travailler en relation avec le module de traitement 3 relié à la mémoire 4. La mémoire 4 stocke des données liées à la représentation réseau 8 et des données 9 liées à la configuration d'usage du réseau. Ces données seront plus largement décrites ci-après. La mémoire 4 comprend un module de calcul 5 qui travaille en correspondance avec le module de traitement 3. Ce module de traitement 3 est propre à appliquer répétitivement un modèle d'évolution du trafic, de type croissance additive et décroissance multiplicative, pour simuler une évolution des débits dans les routeurs du réseau. A chaque application, le module de traitement est propre à demander une mémorisation d'un jeu de variables de débit dans le réseau de façon à prévoir la prochaine époque de congestion et à remédier à la congestion prévue.
La description porte sur notamment la prédiction des performances des flux, par exemple de type TCP, et la quantité de service (QoS) dans une topologie Multi-Routeurs. En d'autres termes, le dispositif et le procédé de l'invention sont utilisés entre autre lorsqu'un grand nombre de sources contrôlées par un protocole, de type TCP par exemple, partagent plusieurs routeurs. Cette simulation est basée sur une description fluide du modèle de type croissance additive et décroissance multiplicative (AIMD).
La figure 2 illustre un réseau informatique du type utilisé dans l'invention. Ainsi, le réseau est constitué de plusieurs routeurs rO, ri, r2, r3 et r4, le routeur rO étant un routeur d'accès. Les routeurs sont reliés entre-eux par des liens tels que Tl relie rO à r3, T2 relie rO à r2, T3 relie r3 à r4, T4 relie rO à r4, T5 relie r3 à r4, T6 relie rO à ri.
Des sources 1, 2, 3 référencées par II, 12, 13 et des destinations 1, 2, 3 référencées par Dl, D2, D3 sont représentées sur la figure 2. Les sources sont reliées au réseau par le routeur d'accès rO. Les destinations sont reliées au réseau par un routeur d'accès r4, r2, r3 respectivement.
La présente description utilise la notion de classes (de traffic). On considérera pour le moment qu'une classe est définie par un trajet et par certaines propriétés de la transmission que l'on peut faire sur ce trajet.
Différents traj ets peuvent être empruntés pour relier une source à une destination. Un même trajet peut être associé à différentes classes. On associe un trajet à un "type" de classe. Un "type" de classe correspond à l' ensemble des classes définissant un même traj et ou un même chemin bout-en-bout d'une classe (annexe A2-3). Ainsi, pour un trajet reliant une des sources S à Dl, au moins deux types de classe sont définis, le type de classe définissant le trajet (T4) et le type de classe définissant le trajet (T5, T3) et passant par le routeur intermédiaire r3. Pour un trajet reliant une des sources S à D2, au moins deux types de classe sont également définis, le type de classe définissant le trajet (T2) et le type de classe définissant le trajet (Tl, T2) et passant par le routeur intermédiaire r2. Pour un trajet reliant une des sources S à D3, au moins deux types de classe sont de nouveau définis, le type de classe définissant le trajet (T5) et le type de classe définissant le trajet (T4, T3) et passant par le routeur intermédiaire r4.
Une classe est définie par un trajet, un type de session, des délais de propagation et un nombre de sources. En référence à l'annexe A2, une classe peut être définie par exemple par l'ensemble des données ST,SN,SR,SB,SE. Plus explicitement, dans une classe 's' donnée, si SN[s] = 100, 100 sources appartenant à la classe 's' ont les mêmes caractéristiques suivantes :
- même type de session FTP (File Transfer Protocol) ou HTTP (Hyper Text Transfer Protocol), - même chemin bout-en-bout, donc en particulier même temps aller-retour désigné par RTT (=rtt[sj) (annexe A3-4).
Dans le reste de la description, les classes sont désignées par la variable s et les routeurs sont désignés par la variable r. La même source peut être désignée comme étant une source de classe s et une source de classe s' si les classes s et s' définissent chacune un trajet allant de la même source à la même destination comme précédemment illustré mais ayant une session différente. En outre, il y a plusieurs sources pour une même classe, c'est-à-dire plusieurs sources dont le trajet est identique pour atteindre leur destination.
Le terme "époque de congestion n" désigne un instant n auquel sont calculés les débits de chaque classe s (débits égaux au débit de chaque source i de classe s). Cette "époque de congestion n" désigne de plus un instant pour lequel un routeur du réseau est dit "congestionné" ou en "état de congestion", c'est-à-dire un routeur qui aura une ou plusieurs pertes de paquets.
En référence à la partie Al de l'annexe A, les paramètres du réseau désignent les paramètres des routeurs définis en Al-1, Al-2, Al-3, Al-4, Al-5. Ainsi, les routeurs, définis par leur capacité à traiter des débits de paquets, peuvent comprendre une mémoire tampon également appelée buf er, dont le rôle est de retenir une partie du débit entrant supérieur au débit sortant. En l' absence de mémoire tampon pour un routeur r, la taille de la mémoire tampon des routeurs est nulle B[r]=0. Les routeurs peuvent être de types différents comme par exemple: -de type FIFO (Fird In First Out) ou FQ (Fair Queing) désignant des types de routeurs susceptibles de perdre des paquets en débordement de file d'attente, également appelés Tail Drop,
- de type RED (Random Early Détection) désignant des types de routeurs capable d' éliminer des paquets par anticipation des débordement de files d'attente.
Dans l'exemple du modèle d'évolution du trafic de type croissance additive et décroissance multiplicative (AIMD), les variables sont définies en référence à la partie A3 de l'annexe A.
La figure 3 illustre un exemple de réalisation de procédé de simulation pour une analyse réseau selon l'invention. Le procédé se réfère aux annexes A, B, C et D reliées au modèle d'évolution du trafic AIMD proposé en exemple.
Ainsi, à l'étape 400 et en référence à la partie B0 de l'annexe B, des variables du modèle sont initialisées :
-en B0- 1 , chaque élément de la matrice p[s,r] désigne une probabilité de synchronisation des pertes de paquets, appelée taux de synchronisation défini entre 0 et 1 qui est ici supposé prédéfini selon la loi de Bernoulli. La valeur de la variable aléatoire gamma[s,r] égale à 0,5 signifie une loi de probabilité de type "pile ou face", - en BO-2, chaque élément du vecteur c[r] désigne la capacité (en paquets par seconde) qu'une source pourrait avoir de la part d'un routeur si la capacité totale de ce routeur était idéalement partagée entre les sources utilisant ce routeur r,
- en B0-3, chaque élément de la matrice a[s,r] désigne une proportion du nombre de sources de classe s sur le nombre de sources utilisant le routeur r, - en BO-4, chaque élément du vecteur m-rtt[r] désigne la somme sur s des a[s,r] divisées chacune par leur temps aller-retour minimum de la classe considérée au carré,
- B0-5, chaque élément de la matrice g[s,r] désigne un entier entre 0 et 1 calculé en fonction du taux de synchronisation,
- en B0-6, la phase d'initialisation consiste à initialiser les débits moyens pour toutes les classes et pour toutes les époques de congestion n variant de 1 à N (n et N étant des entiers), avec la fonction f() donnée décrivant la condition initiale. Cette fonction peut être telle que, par exemple, f(s)=0 pour toute classe s. Il y a une seule contrainte sur f() : cette fonction doit être telle que pour tout 'r', tau_l [r] de l'étape 1, définie en annexe B0, doit être positif ou nul. Cela signifie que la charge initiale doit être compatible avec les capacités du réseau.
La formulation B0-1 est prédéfinie dans le cas où l'hypothèse suivante est faite: - les routeurs ont une mémoire tampon de taille nulle.
De plus, pour l'exemple de réalisation du procédé, en Al -5 , le type de routeur utilisé est de type FIFO et en A2-2, le type de session est de type FTP.
Les étapes 410, 420, 430 représentent l'itération de l'annexe Bl-0 sur chaque époque de congestion des étapes 1, 2 et 3 définies ci-après.
A l'étape 410, un traitement de variables est effectué pour chaque routeur r. Ainsi, V étape 1 en annexe Bl-1 définit, pour chaque routeur r à une époque de congestion n, une somme des débits de source de classes sur l'ensemble des classes selon l'époque de congestion n-1. Ainsi, som_n[r] représente la charge (ou débit) totale sur le routeur 'r' à la fin de l'itération précédente (lors de la première itération, som_l [r] représente la charge totale sur le routeur 'r' définie par la condition initiale). Le calcul de tau -n[r] définit un temps entre l'époque de congestion n-1 donnée et l'époque de congestion n consécutive, appelé temps intercongestion virtuel pour chaque routeur r. En d'autres termes, tau_n[r] est la durée virtuelle de l'inter-congestion du routeur V qui serait effective si par exemple tous les autres routeurs étaient à capacité (c[r]) infinie.
U étape 2 de l'annexe Bl-2 permet de déterminer le temps inter-congestion minimal sur l'ensemble des temps inter-congestion virtuel des routeurs r, encore appelé temps inter- congestion du réseau tau_n. Ce temps inter-congestion minimal désigne le temps entre l'ancienne époque de congestion et l'actuelle époque de congestion. En d'autres termes, la valeur de tau_n donne la n-ième durée inter-congestion du réseau.
A l'étape 420, un traitement de débits moyens est effectué pour chaque classe s. Ainsi à V étape 2 de l'annexe Bl-2, il est calculé en (1) le débit moyen courant x_n[s] de chaque classe s à la n ème époque de congestion. (1) applique à toutes les sources le mécanisme de croissance linéaire (AI développé dans les documents présentant le modèle AIMD). La date absolue de la n-ième congestion du réseau est donné par la valeur de tempsjn. Pour le routeur, appelé n ième routeur ou routeur congestionné à l'instant n, dont le temps inter-congestion virtuel est égal au temps inter-perte du réseau et qui appartient au trajet de la classe (appelé aussi chemin bout-en-bout de la classe), il est ensuite calculé en (2) de Y étape 3 de l'annexe Bl-3, le nouveau débit moyen x_n[s] de chaque classe s défini à l' époque de congestion n. Ce nouveau débit moyen x_n[s] calculé est plus faible que le débit moyen précédent pour éviter une congestion, une perte de paquet ou autre au niveau du ou des routeur(s) congestionné(s) à l'époque de congestion n. Le nouveau débit moyen x__n[s] est calculé en fonction du taux de synchronisation et de l'ancien débit moyen correspondant. (2) de l'annexe Bl-3 applique aux sources traversant le routeur congestionné le mécanisme de décroissance multiplicative (MD) du mécanisme AIMD en moyenne.
A l'étape 430, il est vérifié que les débits calculés correspondent à un état des débits déjà rencontré au préalable ou que le nombre d' itérations des étapes 410 et 420 atteint un nombre déterminé d'itérations(nombre défini par la variable Max_iter de Y étape 0 dans Bl-0). Dans le cas d'une réponse négative, l'itération des étapes 410 et 420 continue pour déterminer le prochain temps minimal inter- virtuel des routeurs et les débits correspondants. Cette itération des étapes 410 et 420 illustre la formule mathématique de l'annexe D comprenant des sommes sur les classes pour calculer le temps inter-congestion d'un routeur, un minimum à trouver parmi les temps inter-congestion des routeurs et ces opérations se répétant pour chaque époque de congestion. Ainsi les débits moyens sont calculés grâce à la matrice de synchronisation représentée par γn+1.
Dans le cas d'une réponse positive à l'étape 430, l'équation de récurrence vectorielle a une solution (sous certaines hypothèses) qui est une orbite périodique à l'étape 440. La théorie garantit l'unicité et l'existence d'une telle orbite finie. En effet, si des congestions (provoquant des pertes) arrivent infiniment souvent sur chaque routeur, une unique solution existe à l'équation de l'annexe D qui a une période finie n indépendante des conditions initiales du vecteur x_n[]. Cette solution est définie comme une orbite dite périodique car elle serait retrouvée dans le cas d'un nouveau cycle d'itérations. Cette orbite est caractérisée par une suite finie du type B 1 -4 dans laquelle r_n est la suite des routeurs où ont eu lieu une congestion (provoquant la perte ou les pertes de paquets), x_n[s] est la suite des débits moyens de classe s, tau_n est la suite des temps inter-congestion du réseau, les suites étant définies aux n époques de congestion. Cette orbite à temps discret définit complètement la trajectoire continue par linéarisation des débits définis en annexe Bl-5. Elle définit le 'squelette' du processus du débit instantané.
Dans une variante de l'invention, cette orbite peut être déterminée en utilisant un modèle d'évolution de trafic autre que le modèle de type croissance additive et décroissance multiplicative.
A l'étape 450, les débits moyens sont analysés. Ainsi, à cette étape, des débits instantanés sont calculés par une approche stochastique si le nombre de sources par classe est élevé (SN). Dans ce cas, les débits instantanés sont calculés à partir des suites de débits moyens obtenus. Les débits instantanés X_n[s,i] sont calculés suivant la formule B2-1 dans laquelle le temps inter-congestion du réseau à l'instant n est ajouté au précédent débit instantané X_{n-1 } [s,i] et ceci pour chaque classe s et pour chaque source i. Pour chaque routeur de la suite r-n compris dans le trajet que définit une classe s SR[s], le nouveau débit instantané X_n[s,i] est calculé suivant la formule B2-2. La variable aléatoire gamma[s,r] correspond au rapport des débits X_n[s,i] juste après et avant congestion.
Ainsi, il est possible de connaître l'évolution des débits instantanés de chaque classe et de prévoir ainsi la performance du réseau.
Quand une orbite périodique est trouvée avant un nombre maximal d'itérations, Max_iter, les résultats sur le régime stationnaire découlent de l'exploitation de l'orbite ainsi obtenue. Les résultats sur le régime transitoire (par exemple le temps nécessaire pour atteindre le régime stationnaire) peuvent également être obtenus. Si l'itération s'arrête lorsque un nombre maximal d'itérations est atteint, Max_iter, sans qu'une orbite périodique soit trouvée, il est possible visuellement d'observer si le régime stationnaire est approximativement atteint en traçant l'évolution de x_n. Dans le cas où cette visualisation est difficile, on obtient un régime transitoire qui est toujours exploitable. Dans ce cas également, le temps de convergence vers le régime stationnaire est supérieur au temps de simulation temps_{Max_iter} . Une valeur typique du nombre maximal d'itérations se situe entre 103 et 106 selon la taille du réseau et le nombre de sources. Dans la figure 4, le graphe d'évolution du débit moyen x dans un routeur appartenant au trajet d'une classe s est une illustration des débits moyens calculés sur un nombre d'itérations égal à 4. A l'époque de congestion n=l , le débit moyen de la classe s est x-1. A l'époque de congestion n=2 est calculé le débit moyen au point A. Dans l'exemple, le temps inter- congestion virtuel du routeur considéré est égal au temps inter-congestion du réseau entre les époques de congestion 1 et 2. Ainsi, pour ce routeur appartenant au trajet de la classe s considérée, à l'époque de congestion n=2, le débit moyen x-2 du routeur est calculé en fonction du taux de synchronisation et correspond au point A'.
A l'époque de congestion n=3 est calculé le débit moyen au point B. Dans l'exemple, le temps inter-congestion virtuel du routeur considéré est égal au temps inter-congestion du réseau entre les époques de congestion 2 et 3. Ainsi, pour ce routeur appartenant au trajet de la classe s considérée, à l'époque de congestion n=3, le débit moyen x-3 du routeur est calculé au point B' en fonction du taux de synchronisation.
A l'époque de congestion n=4 est calculé le débit moyen au point C. Dans l'exemple, le temps inter-congestion virtuel du routeur n'est pas égal au temps inter-congestion du réseau entre les époques de congestion 3 et 4. Ainsi, pour ce routeur appartenant au trajet de la classe s considérée, aucune congestion (entraînant une perte de paquets) n'a lieu, le débit moyen x-4 est celui calculé au point C.
A l'époque de congestion n=5 est calculé le débit moyen au point D. Dans l'exemple, le temps inter-congestion virtuel du routeur considéré est égal au temps inter-congestion du réseau entre les époques de congestion 4 et 5. Ainsi, à l'époque de congestion n=5, pour ce routeur appartenant au trajet de la classe s considérée, le débit moyen du routeur est calculé au point D' en fonction du taux de synchronisation.
Comme ce débit moyen x-5 est égal au débit moyen x-1, et qu'il en est de même pour les autres classes auxquelles appartient ce routeur et pour d'autres routeurs du réseau, un ensemble de valeur de débits moyen définit l'orbite périodique recherchée.
Une variante de l'ordinogramme représenté figure 3 est maintenant développée en référence aux annexes B3 et B4. L'algorithme proposé est une procédure directe de calcul des débits instantanés dans le cas d'une valeur petite de nombre de sources par classe SN, c'est-à-dire une valeur inférieure à une centaine de sources.
Ainsi, l'initialisation des débits instantanés s'effectue à Y étape 0 de l'annexe B3. Chaque débit instantané X-n[s,i] prend la valeur d'une fonction F(s,i). Cette valeur est soit une valeur fixe donnée, soit une valeur obtenue par tirage aléatoire. Comme précédemment, l'itération de l'annexe B4-0 correspond à l'itération des étapes 1, 2 et 3 des annexes B4-1 , B4-2, B4-3. Dans cette variante de réalisation, on n'attend pas l'obtention d'une orbite périodique. La valeur du nombre maximal d'itérations Max_iter varie suivant, par exemple, la durée sur laquelle le réseau (temps_{Max_iter}) est étudié ou les contraintes pratiques, comme le temps de simulation. Comme précédemment, l'observation visuelle graphique a posteriori permet d'avoir une idée sur le fait d'avoir atteint un régime stationnaire ou non.
Ainsi, Y étape 1 de l'annexe B4-1 calcule les temps inter-congestion virtuels de chaque routeur, les débits x_n étant stochastiques (en 0b). V étape 2 de l'annexe B4-2 calcule le temps inter-congestion virtuel du réseau et, en (lb), le débit instantané courant X_n[s] de chaque classe s à la n ème époque de congestion, (lb) applique à toutes les sources le mécanisme de croissance linéaire (AI développé dans les documents présentant le modèle AIMD).
A Y étape 3 de l' annexe B4-3 , le mécanisme décroissance multiplicative (MD) du mécanisme AIMD est appliqué aux débits instantanés des sources traversant le routeur congestionné (en 2b).
Une autre variante de l'ordinogramme représenté figure 3 est maintenant développée en référence aux annexes B5 et B6. Comme l'algorithme 2 en référence aux annexes B3 et B4, l'algorithme 3 des annexes B5 et B6 est une procédure directe de calcul des débits instantanés dans le cas d'une valeur petite de nombre de sources par classe SN et correspond au cas d'une mémoire tampon non négligeable (B[]>0).
L'algorithme 3 correspond à l'algorithme 2 dans lequel ont été ajoutés des éléments d'algorithme précédés d'une étoile. Les variables suivantes ont également été ajoutées concernant la mémoire tampon des routeurs: - bb_n[r]: taille de file d'attente intermédiaire à l'étape n.
- bn_n[r]: taille de file d'attente du routeur 'r' à l'étape n.
- tauO_n[r] représente le tau_n[r] de l'algorithme 2, c'est-à-dire le temps virtuel intercongestion obtenu si les autres routeurs sont de capacité c[r] infinie et si le routeur 'r' considéré n'a pas de mémoire tampon (buffer).
Ainsi, dans l'étape 0 de l'annexe B5, les éléments d'algorithme ajoutés à Palgorithme 2 sont l'initialisation à zéro des tailles de file d'attente bb_n[r] et bn_n[r].
A l'étape 1 de l'annexe B5-1, le calcul d'un temps inter-congestion virtuel d'un routeur à l'époque de congestion n prend en compte le temps inter-congestion virtuel du routeur sans mémoire tampon et le calcul de la taille de file d'attente intermédiaire du routeur.
A l'étape 2 de l'annexe B5-2, après le calcul des temps inter-congestion du réseau tau_n aux époques de congestion n et la mise à jour des débits, les files d'attente bn-n[r] sont mises à jour suivant que, pour une époque de congestion n et un routeur donnés, le temps intercongestion du réseau est supérieur au temps tau0_n[r] ou non.
D'autres modes de réalisation de l'invention sont envisagés ci-après.
Ainsi, le taux de synchronisation, au lieu d'être prédéfini, est estimé dans ce qui suit. Plusieurs estimations sont possibles.
En supposant la synchronisation indépendante du débit (cas RI), on aurait une approximation du taux de synchronisation du type Cl-1, L étant la probabilité de perte de paquet sur une durée de delta[s,r] en partant d'une mémoire tampon (buffer) pleine, et delta étant le délai de réaction du protocole, TCP par exemple, à une perte. Cette formule est obtenue par 1 ' approximation que le rapport B [r]/C [r] est très inférieur à la moyenne pour chaque routeur des temps inter-congestion virtuel tau_n[r], en d'autres termes B[rj7C[r] « moyenne de (tau_n[r]). Lorsqu'un débit d'entrée d'un routeur est pratiquement égal au débit de sortie de ce même routeur, et lorsque la taille de la mémoire tampon B[r] est négligeable, les variables de la formulation Cl-1 sont calculées de la façon suivante : -la probabilité L de perte de paquet est calculé selon Cl -2 et - delta[s,r] est calculé comme une proportion de temps aller-retour rtt[s] d'une classe s qui dépend de la position du routeur r.
Lorsqu'un débit d'entrée d'un routeur est différent du débit de sortie de ce même routeur, et lorsque la taille de la mémoire tampon B[r] n'est pas négligeable, les variables de la formulation Cl-1 sont calculées de la façon suivante :
- il faut appliquer une modification sur L telle que proposée en C3-1, où rhô représente le rapport débit d'entrée d'un routeur sur le débit de sortie.
Dans le cas d'une synchronisation indépendante du débit, la variable aléatoire gamma[s,r] est déterminée suivant par exemple la loi de Bernoulli comme précédemment vu. En supposant la synchronisation dépendante du débit (cas RI), le taux de synchronisation est calculé par une approximation du type C2-1.
Dans tous les cas d'estimation, le taux de synchronisation est estimé pour chaque routeur et pour chaque classe auquelle ce routeur appartient. Dans tous les cas d' estimation, la variable aléatoire gamma[s,r] est déterminée suivant par exemple un modèle linéaire, ou un modèle fonction du débit de manière exponentielle ou polynomiale.
Le procédé décrit suppose donnés les paramètres du réseau et les paramètres de chaque source TCP.
Le dispositif et le procédé correspondant peuvent avoir les applications typiques suivantes.
Une application directe est la prédiction de la performance de la connexion pour un utilisateur typique dans une configuration de réseau donnée. La performance recherchée est par exemple le débit moyen obtenu par un utilisateur, et plus généralement un débit garanti durant un certain pourcentage du temps de connexion, un taux de perte ou toutes autres valeurs qui dépendent de la fluctuation temporelle du débit instantané. Une autre application directe est la réalisation d'un générateur de trafic TCP optimisé.
D'autres application indirectes découlent de la première des applications précédentes. Ainsi, une architecture locale peut être optimisée pour un objectif de performance fixé grâce:
- au dimensionnement des capacités de routeurs,
- au dimensionnement de taille de mémoire tampon. Peuvent également être optimisés :
- la disposition géométrique des routeurs (structure hiérarchique), - le choix de la connectivité des routeurs (hiérarchique ou peer-to-peer),
- la compréhension et le diagnostic de rarchitecture global par une classification des routeurs selon leur performance, la localisation des routeurs de type "goulots d'étranglement".
L'invention couvre le produit logiciel comprenant les fonctions utilisées dans le procédé de test. L'invention couvre également le produit logiciel définissant les éléments du module de traitement du dispositif selon l'invention.
Il est entendu que l'invention n'est pas limitée à la forme décrite ci-dessus mais s'étend â d'autres variantes de réalisation.
Ainsi, dans une autre réalisation de l'invention, les sources sont de type HTTP. Dans une variante de réalisation, le taux de synchronisation est directement estimé par simulation indépendante. Selon un autre mode de réalisation, les routeurs sont de type fair queing (FQ).
Cette simulation peut en outre s'appliquer à d'autres applications que celle des réseaux informatiques, par exemple à tout type de topologie réseau dans diverses domaines (réseau routier, hydraulique, ...). Annexe A
Al Paramètres du réseau
Al-1 N_Router : nombre de routeurs;
Al -2 C[N_Router] : capacité des routeurs (unité en paquet/s);
Al-3 B[N_Router]: taille de buffer des routeurs (unité en paquet/s);
Al -4 L[N_Router][N_Router] : délai de transmission (propagation pure);
Al -5 RT[N_Router] : type de routeur: FIFO, FQ, RED etc.
A2 Paramètres des classes
A2-1 N_Classe nombre de classe de sources; A2-2 ST[N_Classe] type de session, FTP ou HTTP, de la classe; A2-3 SN[N_Classe] nombre de sources par classe; A2-4 SR[N_Classe] chemin bout-en-bout d'une classe; A2-5 SB[N_Classe] délai de propagation (source)-(routeur d'accès); A2-6 SE[N_Classe] délai de propagation (routeur d'accès terminal)- (destina- tion);
A3 Description des Variables du Modèle
A3-1 X_n[s,i] : débit instantané de la source 'i' de la classe 's' à la n-ième itération;
A3 -2 x_n[s,i] : débit moyen de la source 'i' de la classe 's' à la n-ième itération; x_n[s,i] est indépendant de 'i': on pose x_n[s] = x_n[s,i]
A3 -3 N[r] : nombre de sources utilisant le routeur V;
A3-4 rtt[s] : temps aller-retour de la classe 's';
A3 -5 tau_n : n-ième temps inter-congestion du réseau;
A3 -6 tau _n[r] : n-ième temps inter-congestion virtuel du routeur V; A3 -7 gamma[s,r] : variable aléatoire de synchronisation ; Annexe B
BO Initialisation
BO-1' pts ] :=P(£aιr-ma[s,r]-l/2); B0-2 c[r] :=C[r]/N[rJ; B0-3 a[s,r] := SN[sj7Njr], si 'r' dans SR[s];
== U sinon; BO-4 m_rtt[r] :≈ sum_saLs,r]/ιtt[s]Λtt[s); BO-5 g[s,r] :=1 -p[s,τ]/2: BO-6 Etape 0 n = 0: temps_n = 0; for (s=0;s^N_Classe;s++) x_n[s] - (s);
Bl Itération
B 1 -0 for (n=l ;n<Maχ_iter;n++) { do Etape! (n); do Etaρe2(n); do Etape3(n);
» J
Bl-1 Etape 1 for (r=0;r<N_Router;r++) { som_n[r] ≈ 0; for (s=0;s<N_Clas$e;s++) som_u[rJ += afs,r] * x_{n-l}LsJ;
tau_n[r| := (c[r] - somjn[r]) / (m_rtt[r]); Bl-2 Etape 2: tau_n := min_{r=0..N_Router} (tau_n[r]);
(1) x_n[s] := x_{n-l } [s] + tau_n / rtt[s] / rtt[s]; tempsjn := temps_{n-l} + tau_n;
Bl-3 Etape 3: si (tau = tau[r] et 'r' dans SR[s])
(2) x_n[s] := g[s,r] * x_n[s];
Bl-4 {r_n, x[s]_n, tau_n} Bl-5 x_n[s] x_n[s]+tau_{n+l }/rtt[s]/rtt[s]
B2 Algorithme 1
B2-1 X_n[s,i] := ( X_{n-1 } [s,i] + tau_n/rtt[s]/rtt[s] ); B2-2 si ( 'r_n' dans SR[s] )
X_n[s,i] := gamma[s,r] * X_n[s,i];
B3 Algorithme 2- initialisation
Etape 0 n = 0; temps_n = 0; for (s=0;s<N_Classe;s++) for (i=0;i<SN[s];i++) X_n[s,i] := F(s,i);
B4 Algorithme 2
B4-0 for (n=l ;n<Max_iter;n++) { do Etape l(n); do Etape2(n); do Etape3(n);
}
B4-1 Etape 1 for (r=0;r<N_Router;r++) { som_n[r] = 0; for (s=0;s<N_Classe;s++) { x_{n-l}[s] = 0; si (V dans SR[s] ) { for (i=0;i<SN[s];i++) x_{n-l}[s] += X_{n-l}[s,i]; (0b) x_{n-l}[s] /= SN[s];
} som_n[r] += a[s,r] * x_{n-l } [s] ;
} tau_n[r] := (c[r] - som_n[r]) / (m_rtt[r]);
}
B4-2 Etape 2 tau_n := min_{r=0..N_Router} (tau_n[r]); (lb) X_n[s,i] := X_{n-1 } [s,i] + tau_n / rtt[s] / rtt[s]; temps_n := temps_{n-l} + tau_n;
B4-3 Etape 3 si (tau = tau[r] et 'r' dans SR[s]) (2b) X_n[s,i] := gamma[s,r] * X_n[s,i];
B5 Algorithme 3- initialisation
Etape 0 n = 0; tempsjti = 0; for (s=0;s<N_Classe;s++) for (i=0;i<SN[s];i++) X_n[s,i] := F(s,i);
* for (r=l;r<N_Router;r-H-){
* bb_n[r] := 0;
* bn_n[r] := 0;
}
B6 Algorithme 3
B6-0 for (n=l;n<Max_iter;n++){ do Etape l(n); do Etape2(n); do Etape3(n);
}
B6-1 Etape 1 for (r=0;r<N_Router;r++) { som_n[r] = 0; for (s=0;s<N_Classe;s++) { x_{n-l}[s] = 0; si ('r' dans SR[s] ) { for (i=0;i<SN[s];i++) x_{n-l}[s] += X_{n-l}[s,i]; x_{n-l}[s] /= SN[s];
} som_n[r] += a[s,r] * x_{n-l}[s];
} * tau0_n[r] := (c[r] - sorn_n[r]) / (m_rtt[r]);
* bb_n[r] := MAX(0,bn_{n-l } [r]-tau0_n[r]*tau0_n[r]/2*m_rtt[r]);
* tau_n[r] := tauO_n[r]+sqrt(2/m_rtt[r]*((double)B[r]/N[r]-bb_n[r])); } B6-2 Etape 2 tau_n := min_{r=0..N_Router} (tau_n[r]); X_n[s,i] := X_{n-1 } [s,i] + tau_n / rtt[s] / rtt[s]; temps_n := temps_{n-l } + tau_n;
* for (r=0;r<N_Router;r++)
* if ( tau_n > tauO_n[r] ) bn_n[r] :≈ bb_n[r] + pow(tau_n-tau0_n[r],2)/2*m_rtt[r]; else * bn_n[r] := MAX(0,bn_{n- 1 } [r]-pow(tau_n,2)/2*m_rtt[r]);
* }
B6-3 Etαpe 3- idem B4-3
Annexe C
Cl Estimation du Taux de synchronisation indépendant du débit (cas RI)
Cl-1 p(RI)[s,r] := (l-exp(-C[r]*delta[s,r]*L/N[r])) / (l-exp(-C[r]*delta[s,r]*L)); Cl-2 L = l/(B[r]+l)
C2 Estimation du Taux de synchronisation dépendant du débit (cas RD)
C2-1 p(RD)[s,r] := p(RI)[s,r] * x_n[s] / som[r];
C3 Probabilité de perte L dans le cas d'une mémoire tampon non négligeable
C3-1 L=rhoΛB[r] * (rho - 1) / (rhoΛ(B[r]+l) - 1);
Annexe D
^(rn+i.s) CI , 1 . τ cn+l In+l J.+ ^mιn — 2 u-.r€Pu °u-r γi Ri τeτι ∑ ûu,r UXTÇLP ~W

Claims

Revendications
1. Procédé de test et de prédiction du comportement d'un réseau informatique, caractérisé par les étapes suivantes: a. mémoriser d'une part une représentation du réseau (8), comprenant des routeurs (r), leurs propriétés propres de transmission (C, Al -2), et des temps de transit entre routeurs, d' autre part une configuration d'usage du réseau (9) comprenant des classes de trafic, à chacune de ces classes est associé un nombre de sources (SN, A2-3) et un trajet à travers les routeurs (SR, A2-4), b. à partir de conditions initiales choisies (400), appliquer répétitivement un modèle d'évolution du trafic (410, 420), de type croissance additive et décroissance multiplicative, pour simuler une évolution de débits dans le réseau, en mémorisant à chaque fois un jeu de variables de débits des classes ou des sources, et c. si la répétition de l'étape b. produit une orbite périodique (430), revenant sensible- ment sur un jeu de variables de débits des classes ou des sources déjà rencontré, examiner la suite des routeurs rencontrés, comme responsables des pertes pour évaluer le débit obtenu par chaque classe ou source (450).
2. Procédé selon la revendication 1, caractérisé en ce que l'étape c. est également effectuée lorsque le nombre de répétitions de l'étape b. atteint un seuil (430).
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'étape b. comprend b 1. le calcul et la mémorisation d'un temps inter-congestion virtuel (tau_n[r] , A3 -6) pour chaque routeur.
4. Procédé selon la revendication 3, caractérisé en ce que l'étape bl. comprend également le calcul d'un temps inter-congestion virtuel minimum, en tant que temps inter-congestion effectif du réseau (tau_n, A3 -5).
5. Procédé selon l'une des revendications 3 et 4, caractérisé en ce que l'étape b. comprend en outre: b2. à chaque instant donné, le calcul et la mémorisation d'au moins un débit de classe dont le trajet passe par un routeur congestionné (x_n[s], X_n[s]).
6. Procédé selon la revendication 5, caractérisé en ce que le routeur congestionné de l'étape b2. est choisi de manière à ce qu'il vérifie une condition donnée, qui inclut le fait que le temps inter-congestion du réseau (tau_n, A3-5) est égal au temps inter-congestion virtuel (tau_n[r], A3-6) pour ce routeur congestionné.
7. Procédé selon l'une des revendications 5 et 6, caractérisé en ce que la condition donnée de l'étape b2. inclut le fait que le routeur est un des routeurs d'un trajet donné défini par une classe de trafic.
8. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape a. comprend, pour chaque routeur, une valeur de capacité (C, A 1-2), une valeur de taille de mémoire tampon (B, Al -3), une indication de type (RT, Al -5), ainsi que des valeurs de temps de propagation pure entre routeurs.
9. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape a. comprend, pour chaque classe de trafic, un nombre de sources par classe (SN, A2-3), un trajet d'une source à une destination (SR, A2-4), une indication de type (ST, A2-2), ainsi que des valeurs de temps de propagation entre une source et un routeur d' accès (SB, A2-5) d'une part et entre un routeur d'accès terminal et une destination (SE, A2-6) d'autre part.
10. Procédé selon l'une des revendications précédentes, caractérisé en ce que le modèle d'évolution du trafic de l'étape b. comprend des variables comprenant le nombre de sources utilisant un routeur donné (N[r], A3-3), un temps aller-retour (rtt, A3-4) d'une classe défini de la source à la destination.
11. Procédé selon l'une des revendications précédentes, caractérisé en ce que le modèle d'évolution du trafic de l'étape b. comprend des variables définies selon des conditions initiales, ces variables comprenant une valeur moyenne de débit d'un routeur, valeur en théorie utilisable pour chaque source partageant ce routeur (c(r), BO-2), une valeur de proportion représentant un nombre de sources d'une classe par rapport au nombre total de sources partageant un routeur (a(s,r), B0-3), une valeur d'accélération pour un routeur (m- rtt[r], B0-4) représentant la somme sur les classes du rapport de la valeur de proportion sur un temps aller-retour de la source à la destination au carré, un taux de synchronisation (p, C1-1;C2-1).
12. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'étape b2. comprend une formulation mathématique conforme essentiellement à l' annexe B 1 -3.
13. Procédé selon la revendicationlO, caractérisé en ce que le taux de synchronisation est estimé de façon indépendante du débit.
14. Procédé selon la revendication^, caractérisé en ce que le taux de synchronisation est estimé de façon conforme à la formulation mathématique présentée en annexe Cl-1 comprenant une probabilité L de perte de paquets .
15. Procédé selon la revendication 10, caractérisé en ce que le taux de synchronisation (p) est estimé conformément à la formulation mathématique de l'annexe Cl-1 de façon dépendante du débit.
16. Procédé selon la revendication 15, caractérisé en ce que le taux de synchronisation (p) est estimé conformément à la formulation mathématique de l'annexe C2-1 comprenant une probabilité de perte de paquets L.
17. Procédé selon la revendication 12 et 14, caractérisé en ce que la probabilité de perte de paquets L est estimée conformément à la formulation mathématique de l'annexe Cl-2.
18. Procédé selon l'une des revendications 15 et 16, caractérisé en ce que la probabilité de perte de paquets L est estimée conformément à la formulation mathématique de 1 ' annexe C3 - 1.
19. Procédé selon l'une des revendications précédentes, caractérisé en ce que le taux de synchronisation est calculé par simulation indépendante.
20. Procédé selon l'une des revendications précédentes, caractérisé en ce que la session représente un flux contrôlé par un protocole de type TCP.
21. Procédé selon la revendications 3, caractérisé en ce que l'étape b. comprend d'être effectuée répétitivement pour chaque routeur et pour chaque classe.
22. Dispositif de test et de prédiction du comportement d'un réseau informatique, caractérisé en ce qu'il comprend:
- une mémoire (4) pour stocker:
* des paramètres du réseau (8) comprenant des routeurs (r), leurs propriétés propres de transmission (C, Al -2), et des temps de transit entre routeurs,
* des paramètres de configuration d'usage du réseau (9) comprenant des classes de trafic, à chacune de ces classes associé un nombre de sources (SN, A2-3) et un trajet à travers les routeurs (SR, A2-4),
* un module de calcul (5) selon un modèle d'évolution du trafic, de type croissance additive et décroissance multiplicative (AEVID),
- un module de traitement (3) propre à: * à partir de conditions initiales choisies, appliquer répétitivement le modèle d'évolution du trafic, de type croissance additive et décroissance multiplicative (AIMD), pour simuler une évolution des débits dans le réseau, en mémorisant à chaque fois un jeu de variables de débits des classes ou des sources (I),
* arrêter l'application répétitive du modèle d'évolution du trafic lorsqu'une orbite périodique revenant sensiblement sur un j eu de variables de débits des classes ou des sources (I) déjà rencontré est obtenue
* examiner la suite des routeurs rencontrés, comme responsables de pertes pour évaluer le débit obtenu par chaque classe ou source.
23. Dispositif selon la revendication 22, caractérisé en ce que le module de traitement (3) est propre à arrêter l'application répétitive du modèle d'évolution du trafic lorsque le nombre de répétitions atteint un seuil.
24. Dispositif selon l'une des revendications 22 et 23, caractérisé en ce que le module de traitement (3) est propre à calculer et à mémoriser un temps inter-congestion virtuel (tau_n[r], A3 -6) pour chaque routeur.
25. Dispositif selon la revendication 24, caractérisé en ce que le module de traitement est propre à calculer et à mémoriser un temps inter-congestion virtuel minimum, en tant que temps inter-congestion effectif du réseau (taujn, A3 -5).
26. Dispositif selon l'une des revendications 24 et 25, caractérisé en ce que le module de traitement est propre en outre à calculer et à mémoriser des valeurs de débit des classes dont le trajet passe par un routeur congestionné (x_n[s], X_n[s] ).
27. Dispositif selon la revendication 26, caractérisé en ce que le routeur choisi l'est de manière à ce qu'il vérifie une condition donnée, qui inclut le fait que le temps intercongestion du réseau (taujn, A3 -5) est égal au temps inter-congestion virtuel (tau_n[r], A3- 6) pour ce routeur.
28. Dispositif selon la revendication 27, caractérisé en ce que la condition donnée inclut le fait que le routeur est un des routeurs d'un trajet donné défini par une classe de trafic.
29. Dispositif selon l'une des revendications précédentes, caractérisé en ce que chaque routeur comprend une valeur de capacité (C, Al -2), une valeur de taille de mémoire tampon (B, Al-3), une indication de type (RT, Al-5), ainsi que des valeurs de temps de propagation pure entre routeurs.
30. Dispositif selon Tune des revendications précédentes, caractérisé en ce que chaque classe de trafic comprend un nombre de sources par classe (SN, A2-3), un trajet d'une source à une destination (SR, A2-4), une indication de type (ST, A2-2), ainsi que des valeurs de temps de propagation entre une source et un routeur d' accès (SB, A2-5) d'une part et entre un routeur d'accès terminal et une destination (SE, A2-6) d'autre part.
31. Dispositif selon Tune des revendications précédentes, caractérisé en ce que le modèle d'évolution du trafic comprend des variables comprenant le nombre de sources utilisant un routeur donné (N[r], A3-3), un temps aller-retour (rtt, A3-4) d'une classe défini de la source à la destination.
32. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le modèle d'évolution du trafic comprend des variables définies selon des conditions initiales, ces variables comprenant une valeur moyenne de débit d'un routeur, valeur en théorie utilisable pour chaque source partageant ce routeur (c(r),B0-2)), une valeur de proportion représentant un nombre de sources d'une classe par rapport au nombre total de sources partageant un routeur (a(s,r), B0-3)), une valeur d'accélération pour un routeur (m-rtt[r], BO-4) représentant la somme sur les classes du rapport de la valeur de proportion sur un temps aller-retour de la source à la destination au carré, un taux de synchronisation.
33. Dispositif selon la revendication 12, caractérisé en ce que le calcul et la mémorisation des valeurs de débit des classes dont le trajet passe par un routeur congestionné (x_n[s], X_n[s]) est effectué selon une formulation mathématique conforme essentiellement à l' annexe B 1 -5.
34. Dispositif selon la revendicationlO, caractérisé en ce que le taux de synchronisation est estimé de façon indépendante du débit.
35. Dispositif selon la revendication^, caractérisé en ce que le taux de synchronisation est estimé de façon conforme à la formulation mathématique présentée en annexe Cl-1 comprenant une probabilité de perte de paquets L.
36. Dispositif selon la revendication 10, caractérisé en ce que le taux de synchronisation est estimé de façon dépendante du débit.
37. Dispositif selon la revendication 15 , caractérisé en ce que le taux de synchronisation est estimé conformément à la formulation mathématique de l'annexe C2-1 comprenant une probabilité de perte de paquets L.
38. Dispositif selon la revendication 12 et 14, caractérisé en ce que la probabilité de perte de paquets L est estimée conformément à la formulation mathématique de l'annexe Cl -2.
39. Dispositif selon l'une des revendications 1 5 et 16, caractérisé en ce que la probabilité de perte de paquets L est estimée conformément à la formulation mathématique de l'annexe C3-1.
40. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le taux de synchronisation est calculé par simulation indépendante.
41. Dispositif selon l'une des revendications précédentes, caractérisé en ce que la session représente un flux contrôlé par un protocole de type TCP.
42. Produit logiciel, comprenant les fonctions utilisées dans le procédé de test selon l'une des revendications 1 à 21.
43. Produit logiciel, définissant les éléments du module de traitement du dispositif selon l'une des revendications 22 à 41.
EP02793213A 2001-11-12 2002-11-07 Dispositif et procede d'analyse resau a prediction autonome Withdrawn EP1444808A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0114608A FR2832276B1 (fr) 2001-11-12 2001-11-12 Dispositif et procede d'analyse reseau a prediction autonome
FR0114608 2001-11-12
PCT/FR2002/003825 WO2003043264A2 (fr) 2001-11-12 2002-11-07 Dispositif et procede d'analyse resau a prediction autonome

Publications (1)

Publication Number Publication Date
EP1444808A2 true EP1444808A2 (fr) 2004-08-11

Family

ID=8869303

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02793213A Withdrawn EP1444808A2 (fr) 2001-11-12 2002-11-07 Dispositif et procede d'analyse resau a prediction autonome

Country Status (6)

Country Link
US (1) US20050251702A1 (fr)
EP (1) EP1444808A2 (fr)
JP (1) JP2005510129A (fr)
CA (1) CA2466314A1 (fr)
FR (1) FR2832276B1 (fr)
WO (1) WO2003043264A2 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1569404B1 (fr) * 2004-02-25 2007-08-22 Research In Motion Limited Système et méthode pour maintenir une connexion de réseau
US7426569B2 (en) 2004-02-25 2008-09-16 Research In Motion Limited System and method for maintaining a network connection
JP4514501B2 (ja) * 2004-04-21 2010-07-28 株式会社日立製作所 ストレージシステム及びストレージシステムの障害解消方法
WO2006012211A2 (fr) * 2004-06-24 2006-02-02 Meshnetworks, Inc. Systeme et procede pour le choix de debit adaptatif pour des reseaux sans fil
US7975184B2 (en) * 2006-04-03 2011-07-05 Donald Goff Diagnostic access system
US7961605B2 (en) * 2006-07-31 2011-06-14 International Business Machines Corporation System and method for enabling management of a plurality of messages in a communication network
US9552550B2 (en) * 2014-05-13 2017-01-24 Cisco Technology, Inc. Traffic shaping based on predicted network resources

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6028846A (en) * 1997-09-11 2000-02-22 U S West, Inc. Method and system for testing real-time delivery of packets of data
US6515967B1 (en) * 1998-06-30 2003-02-04 Cisco Technology, Inc. Method and apparatus for detecting a fault in a multicast routing infrastructure
US6480892B1 (en) * 1998-12-16 2002-11-12 Siemens Information And Communication Networks, Inc. Apparatus and method for inserting predetermined packet loss into a data flow
FR2805945B1 (fr) * 2000-03-01 2002-05-03 Inst Nat Rech Inf Automat Surveillance et simulation perfectionnees de systemes complexes, notamment de mecanismes et de controles de flux et de congestions dans des reseaux de communication
US6842427B1 (en) * 2000-05-09 2005-01-11 Itxc Ip Holdings S.A.R.L. Method and apparatus for optimizing transmission of signals over a packet switched data network
US7111073B1 (en) * 2000-05-30 2006-09-19 Cisco Technology, Inc. Apparatus for estimating delay and jitter between network routers
US6868068B1 (en) * 2000-06-30 2005-03-15 Cisco Technology, Inc. Method and apparatus for estimating delay and jitter between network routers
US6912203B1 (en) * 2000-07-31 2005-06-28 Cisco Technology, Inc. Method and apparatus for estimating delay and jitter between many network routers using measurements between a preferred set of routers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03043264A2 *

Also Published As

Publication number Publication date
WO2003043264A3 (fr) 2003-12-18
US20050251702A1 (en) 2005-11-10
JP2005510129A (ja) 2005-04-14
WO2003043264A2 (fr) 2003-05-22
FR2832276A1 (fr) 2003-05-16
CA2466314A1 (fr) 2003-05-22
FR2832276B1 (fr) 2005-02-25

Similar Documents

Publication Publication Date Title
CN101313521B (zh) 使用滤波和主动探测来评估数据传输路径
EP2033380B1 (fr) Procede de routage de liens virtuels dans un reseau a commutation de trames a determinisme garanti
WO2015193570A1 (fr) Méthode de routage de donnée et commutateur dans un réseau
FR2830094A1 (fr) Procede et dispositif de simulation du comportement d&#39;un reseau, permettant un dimensionnement a la demande
WO2008056041A1 (fr) Methode et appareil pour fournir un equilibrage de charge base sur le flux
US20210234791A1 (en) Service assurance of ecmp using virtual network function hashing algorithm
US20230131255A1 (en) Selective fidelity rates for network traffic replication by a digital twin device
Mohammed et al. Machine learning-based network status detection and fault localization
EP1444808A2 (fr) Dispositif et procede d&#39;analyse resau a prediction autonome
CA2398366C (fr) Procede d&#39;optimisation dynamique de la qualite de service dans un reseau de transmission de donnees
Mittal Performance evaluation of openflow SDN controllers
EP1958393B1 (fr) Procede et dispositif de controle a distance de la congestion de flux mailles dans un reseau de telecommunication en mode paquet
FR2805945A1 (fr) Surveillance et simulation perfectionnees de systemes complexes, notamment de mecanismes et de controles de flux et de congestions dans des reseaux de communication
Roughan et al. Performance of estimated traffic matrices in traffic engineering
EP1864451B1 (fr) Procede d&#39;evaluation numerique d&#39;un reseau de transmission de donnees
Andrew Fast simulation of wavelength continuous WDM networks
Salamatian et al. A framework for interpreting measurement over Internet
Wasielewska et al. Bandwidth estimation using network calculus in practice
Alouf Parameter estimation and performance analysis of several network applications
Lee et al. Design and experimental validation of SFC monitoring approach with minimal agent deployment
FR3081581A1 (fr) Procede d&#39;envoi de donnees, programme d&#39;ordinateur et systeme associes
Boussada et al. Numerical key results for studying the performance of tcp traffic under class-based weighted fair queuing system
Sadiku et al. Performance measures
FR2846170A1 (fr) Procede d&#39;optimisation du trafic sur internet.
Zhang et al. A shortest path algorithm for satellite time-varying topological network

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040514

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BACCELLI, FRANEOIS

Inventor name: HONG, DOHY

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: N2NSOFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080603