WO2006117448A1 - Procede d'ordonnancement de paquets appartenant à des flots et equipement associé - Google Patents

Procede d'ordonnancement de paquets appartenant à des flots et equipement associé Download PDF

Info

Publication number
WO2006117448A1
WO2006117448A1 PCT/FR2006/000878 FR2006000878W WO2006117448A1 WO 2006117448 A1 WO2006117448 A1 WO 2006117448A1 FR 2006000878 W FR2006000878 W FR 2006000878W WO 2006117448 A1 WO2006117448 A1 WO 2006117448A1
Authority
WO
WIPO (PCT)
Prior art keywords
stream
flow
packet
fair
reference time
Prior art date
Application number
PCT/FR2006/000878
Other languages
English (en)
Inventor
James Roberts
Abdesselem Kortebi
Luca Muscariello
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Priority to US11/919,752 priority Critical patent/US7933204B2/en
Priority to EP06755432A priority patent/EP1878180B1/fr
Publication of WO2006117448A1 publication Critical patent/WO2006117448A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/52—Queue scheduling by attributing bandwidth to queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/17—Interaction among intermediate nodes, e.g. hop by hop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/622—Queue service order
    • H04L47/623—Weighted service order

Definitions

  • the present invention relates to the scheduling of packets belonging to streams, for delivery on a network link for example.
  • a stream includes a succession of data packets, such as IP datagrams ("Internet Protocol") for example. It is identified by a set of attributes present in the header of each of the packets that compose it. These attributes include, for example, a source IP address, a destination IP address, a source port, a destination port, a protocol identification, a flow label, and so on. Thus, all packets with the same attribute values constitute a stream.
  • IP datagrams Internet Protocol
  • a stream is considered to be in progress at a given moment if the time elapsed since the observation of its last packet is below a certain threshold TO 1 of the order of a few seconds for example.
  • Packet scheduling mechanisms using the notion of flow are known. They aim to establish an order in the delivery of packets at the output of a router for example.
  • Fair Queuing algorithms there is abundant literature on Fair Queuing algorithms. These algorithms ensure a certain level of equity between the streams during the delivery of the packets.
  • DRR is a reduced complexity scheduling mechanism based on cyclically processing streams according to a round robin distribution principle.
  • a queue is associated with each stream.
  • Stream i is allowed to transmit at most one quantum
  • SFQ is a mechanism that is part of the fair-sharing algorithm class sometimes called "self-clocked".
  • the scheduling of the packets to be delivered is defined by a stamp assigned to each packet.
  • the stream i is associated with a rate parameter Rj which determines the approximation between the stamps of the packets of this stream.
  • the waves, in a network of packets, are ephemeral in nature.
  • the number of streams in progress at each moment is a variable that can reach a value of several tens of thousands on a high capacity link (2.5 Gbps or more, for example).
  • the number of streams that must be known at each instant of the scheduling mechanism is considerably smaller.
  • the schedule of delivery of the packets established by the scheduling mechanism concerns only the streams, called active streams, which have at least one packet in queue for delivery at the instant in question or, possibly, who had it in a very recent past. This fact makes equitable sharing scheduling feasible even at very high link rates, since the number of active streams is independent of the bit rate of the link and is limited to a few hundred, for example.
  • the traffic can be broken down into two types of flows: forced or "bottlenecked” flows denoted by BKD thereafter (for "bottlenecked") whose input flow of the scheduling exceeds the equitable flow achieved by the scheduling, and the other NBD (non-bottlenecked) flows whose input rate of the scheduling is lower than the fair debit.
  • BKD forced or "bottlenecked” flows denoted by BKD thereafter (for "bottlenecked") whose input flow of the scheduling exceeds the equitable flow achieved by the scheduling
  • NBD non-bottlenecked
  • EP1478140 discloses a mechanism operating an implicit differentiation, that is to say without specific signaling or resource reservation, the quality of service, distinguishing the BKD and NBD flows.
  • the packets of the NBD flows are treated as a priority, whereas the BKD flows undergo IOntribution to equitable sharing.
  • the streams of "real-time" type (streaming audio or video for example) whose flow is relatively low undergo a weak packet delay.
  • the "data” type flows achieve the maximum bit rate compatible with a sharing objective.
  • the NBD streams are momentarily included in the scheduling structure when they issue a packet. This is necessary to allow the detection of new BKD flows, but has the effect of requiring a relatively large capacity for this structure compared to that which is strictly necessary to treat BKD streams.
  • the scheduling proposed in the abovementioned techniques may require taking into account several hundred streams at certain times for a link load served of about 90%.
  • the number of flows depends in fact on the characteristics of the traffic, in particular on the relationship between the bit rate of the link and the maximum flow rate of the streams (that is to say the bit rate that they could reach if the link was of infinite capacity, account other flow limitations in their path).
  • EP1478140 provides an identical allocation for all flows. This limitation can be inconvenient in certain applications, particularly in an access network where one would like to distinguish users according to the conditions provided for in their subscription.
  • An object of the present invention is to limit the disadvantages of the prior art, mentioned above. - AT -
  • an object of the invention is to limit the information to be taken into account by the scheduling and complexity of the processing implemented.
  • Another object of the invention is to increase the robustness of the dimensioning of the structures of the scheduling.
  • Another object of the invention is to allow the taking into account of particular conditions for separate user streams.
  • the invention thus proposes a method for scheduling data packets belonging to streams, comprising the following steps, relative to each new incoming packet:
  • the update mode of the list of active streams makes it possible to ensure that this list contains only flows of the category BKD. Indeed, the comparison between the estimate of the amount of incoming data relative to said flow over the reference time interval and the maximum value makes it possible to determine, before updating the list of active flows, whether the flow considered is of type BKD or NBD. This significantly limits the size of this list, as well as its dependence on traffic characteristics. This reduction in size also makes it possible to limit the complexity of the processing operations to be implemented, in particular to maintain a list of current active streams.
  • the maximum value taken into account may depend on the flow class associated with the stream under consideration. It can also consist of a predetermined fixed value, in particular in the case where the estimation of the quantity of incoming data is limited to a count of the number of incoming packets belonging to this stream.
  • a simple data structure such as a table, can advantageously be used to estimate the amount of incoming data relative to said stream.
  • obtaining an estimate of the quantity of incoming data relative to said stream comprises updating, during said reference time interval, a field of the array whose address corresponds to a function of an identifier of said stream, each field of the array being reset at the beginning of the reference time interval.
  • the function used is for example a hash function that is to say a function for creating a digest of the identifier of said stream, with a limited degree of ambiguity.
  • the method may further comprise a prior admission control in which it is decided whether or not the packet should be rejected before step IBI, based on an available bandwidth and a load level of the queue. priority waiting. Such a control makes it possible to avoid situations of congestion.
  • the method also advantageously comprises the delivery of packets in the following order: first, all the packets introduced into the priority queue are delivered, then at least some of the packets introduced into the scheduling mechanism are delivered to equitable sharing.
  • the invention further proposes an equipment, such as a queue manager in a router for example, capable of contributing to a scheduling of data packets belonging to streams, comprising, with respect to each new incoming packet:
  • IiI means for introducing the packet into a fair-sharing scheduling mechanism for delivery, when said stream is part of a list of active streams, the fair-sharing scheduling mechanism being arranged to deliver the packets of each flow substantially according to the same fair flow rate weighted by the flow class associated with the corresponding flow;
  • the invention also proposes a router arranged to incorporate the aforementioned equipment.
  • the invention finally proposes a computer program product comprising instructions able to implement a scheduling of data packets belonging to streams according to the following steps, relative to each new incoming packet, when said program is loaded and executed by computing means: / a / determining the flow to which the packet belongs, a flow class being associated with said flow;
  • FIG. 1 is a diagram illustrating a simplified architecture for the scheduling of packets
  • FIG. 2 is a diagram illustrating a mode of delivery of the packets
  • FIG. 3 is a diagram of a data structure used for the detection of new flows
  • FIG. 4 is a flowchart representing main stages of the scheduling of the packets to be delivered
  • FIG. 5 is a diagram illustrating a BKD flow detection
  • FIG. 6 is an exemplary structure of a list of active streams according to the DRR scheduling mechanism
  • FIG. 7 is a flow chart showing steps of introducing a packet of an active stream according to the DRR scheduling mechanism
  • FIG. 8 is a flowchart showing steps for introducing a new active stream according to the DRR scheduling mechanism
  • FIG. 9 is a flowchart showing packet delivery steps according to the DRR scheduling mechanism
  • FIG. 10 is an exemplary structure of a list of active flows according to the SFQ scheduling mechanism
  • FIG. 11 is an exemplary structure of a schedule according to the SFQ scheduling mechanism
  • FIG. 12 is a flow chart showing steps of introducing a packet of an active stream according to the SFQ scheduling mechanism
  • FIG. 13 is a flow chart showing steps for introducing a new active stream according to the SFQ scheduling mechanism
  • Fig. 14 is a flowchart showing packet delivery steps according to the SFQ scheduling mechanism.
  • Figure 1 schematically shows the architecture for scheduling incoming data packets in the system.
  • the system in question comprises for example a router comprising, between other elements, a device 2 which receives incoming packets 1 and outputs packets 7 corresponding to at least some incoming packets 1. These packets 7 are delivered on a link controlled by the equipment 2. They are issued in a certain order determined by the scheduling implemented by the system.
  • BKD flows BKD flows and NBD flows.
  • PQ Primary Queue
  • WFQ Weighted Fair Queuing
  • FIG. 2 illustrates the mode of delivery of the packets 7 at the output of the scheduling.
  • the occupancy status of the priority queue PQ (step 8) is checked. If PQ contains at least one pending packet, it must be delivered in priority (step 9). If the queue PQ is of type FIFO, it is then emptied starting with the head, that is to say by the packets entered first in the queue. On the other hand, if PQ is empty, it means that all packets belonging to NBD streams have already been delivered. Then one or more packets, belonging to BKD flows, previously introduced into the scheduling mechanism WFQ 6 (step 10) are delivered. The order of transmission of these packets depends on the scheduling mechanism 6 implemented.
  • an admission control 3 can be implemented, optionally, at the input of the equipment 2.
  • An example of such a mechanism is the implicit admission control described in EP1478140. It aims to limit situations of congestion. For this purpose, it is checked whether the available bandwidth of the link controlled by the equipment 2 is greater than a first threshold and whether the load due to the packets placed in priority queue is less than a second threshold. In the opposite case, only the packets of the protected streams, that is to say of the streams which are admitted to transmit, are accepted. Other packets are rejected before they can be scheduled. This protects the quality of service of the streams already started.
  • P be an incoming packet of length L.
  • This packet belongs to a stream F whose identifier can be deduced from the header of the packet P by the system in question (for example the equipment 2 of FIG. 1).
  • the length L of P is also detected by the system.
  • a logic variable "Silence” can take the value "False” (step 20), which means that there is at least one packet to be delivered in the system. This variable will be used for the calculation of the fair bit rate for the WFQ scheduling mechanism, as will be detailed below.
  • the presence of the stream F is checked, for example using its identifier, in an ActiveList list (step 21). ActiveList is built to understand all active BKD flows only.
  • the flow rate of F is estimated with respect to the fair flow rate achieved at the current time by the WFQ scheduling (steps 23-25). If the flow rate of F is greater than an estimate of the equitable flow rate, the flow F is therefore a flow of BKD type and it will be added to ActiveList (step 27). In this case, the packet P of the stream F is introduced into the scheduling mechanism WFQ for delivery (step 26).
  • This structure is a table comprising M elements of b bits each, with M and b integers. Each element of this array is identified by an address I 1 , I 2 , ... I, ..., I M - These addresses also correspond to values each obtained by the application of a function, for example a hash function, to the identifier of a stream.
  • a function for example a hash function
  • the value I corresponding to the application of said function to the identifier of F is calculated.
  • This value makes it possible to retrieve the field of the array 11, of address I, in order to update the I.Bytes counter value stored therein (step 23).
  • the I.Bytes counter is representative of the amount of data received at the input of the system relative to the stream F 1 during a reference time interval.
  • Each I.Bytes counter is reset to zero at the beginning of each reference time slot.
  • the maximum number of MaxByte bytes that a stream could transmit in a reference time interval without being of BKD type is also calculated.
  • the reference time intervals mentioned above are chosen so that a stream whose bit rate class is the lowest is BKD if it transmits more than a maximum value.
  • MTU bytes for example 1500 bytes. This point will be detailed below.
  • a comparison of the I.Byte and MaxBytes values obtained in the manner indicated above (step 25) then makes it possible to determine whether the stream under consideration is of the BKD or NBD type.
  • the flow rate class of a stream can be deduced, for example, from the fields of the header of each incoming packet belonging to this stream.
  • the class can be derived from the IP addresses or DSCP ("Diffserv Code Point") field included in the packet header.
  • the reference time intervals are independent of the fair bit rate achieved at the current time by the WFQ scheduling.
  • the I.Bytes counter is compared with a maximum value MaxBytes which depends on the equitable flow rate.
  • the reference time intervals and the MaxBytes value each depend on the fair bit rate.
  • the value of the unit is adapted to the MaxBytes limit of the flow concerned. So, for a package of length L, the corresponding I.Bytes counter would be incremented by
  • False positive errors can occur when the result of applying the hash function to the identifiers of two or more active streams is identical. It is then possible that the corresponding I.Bytes field is overestimated because it is incremented by the amount of data received for each of these streams in the reference time interval under consideration (see step 23). This may cause the I.Bytes counter to overflow, so that one of the active streams it corresponds to is incorrectly considered a BKD stream. It is noted that such a collision between two distinct flows leads to a false positive only when it occurs during the same reference time interval.
  • I 1 is too weak. This leads to overestimation of the number of incoming bytes for each stream.
  • the I.Bytes counters can take only two values, 0 or 1.
  • the I.Bytes counter associated with this stream overflows, causing the flow to be identified as a BKD stream.
  • the total amount of data corresponding to the two packets 13 received in this interval may be less than the maximum value MaxBytes, for example if each of the received packets 13 contains 500 bytes, ie a total of 1000 bytes, while MaxBytes is 1500 bytes. , a typical value of MTU.
  • False negative errors can occur when there is a delay in recognizing a BKD stream whose arrival of the packets is misplaced with respect to the terminals of the reference time intervals, which correspond to the reset times of the I.Bytes counters. So in the illustrated example in FIG. 5, incoming packets 13 belonging to a stream are received at a rate of one per reference time slot during the first two intervals [ ⁇ - ⁇ ; ⁇ 2 ] and [ ⁇ 2 ; ⁇ 3 ] represented on FIG. 12. It is only in the following interval [ ⁇ 3 ; ⁇ 4 ] that two packets 13 are detected, so that the flow can then be considered as being BKD, while the flow of arrival of its packages did not vary significantly over the period represented.
  • the probability of false negatives is only significant for flows whose flow rate is close to the fair flow.
  • the first packets of such a stream are sent to the queue PQ, as long as the stream is not identified as a BKD stream, which does not affect the efficiency of the scheduling.
  • any stream is considered to be BKD as soon as it transmits more than one packet in a reference time interval, regardless of its rate class.
  • this choice is attractive because it makes it possible to obtain a very small size for the data structure of FIG. 3. It also presents a reduced complexity due to not taking into account the flow class.
  • the data structure that has been presented with reference to FIG. 3 consists of a simple linear structure of M counters, each corresponding to the single image of a set of stream identifiers. In general, it is possible to reduce the size of the memory required by adopting a more complex structure.
  • Bloom's filter techniques described in B. Bloom's article, "Space / time tradeoffs in hash coding with allowable errors," Common ACM Vol 13, 7, 422-426, JuIy 1970 “, or multi-bitmaps stages described in the article by C. Estan, G. Varghese, "New directions in traffic measurement and accounting, Proceedings of ACM Sigcomm 2002” uses several hash functions applied to the flow identifier and designating a set of counters . In the present application, each counter of the set corresponding to a stream would be updated as previously described. The BKD condition would be presumed if all these counters were to overflow when a new packet arrived.
  • FIG. 6 shows a possible structure for ActiveList.
  • This list includes one line per stream.
  • Each line 31 contains the following data in columns (from left to right in the illustrated example): F: an identifier of the stream;
  • F. Q the quantum expressing the number of bytes that the stream is allowed to transmit during a cycle of the algorithm
  • F.DC the flow deficit counter
  • F.FIFO the set of memory addresses and pointers to identify stream packets in first-come, first-served order
  • - HeadRound refers to the stream that must be served first, when it is the turn of the WFQ scheduling to issue; and - TailRound: refers to the stream still present in ActiveList that issued a packet last or the dummy stream 0 if it received a visit after this broadcast.
  • FIG. 7 illustrates the operations performed during the introduction of a packet P belonging to a stream F already present in ActiveList (which corresponds to step 22 of FIG. 4), assuming that the queue of packets is not saturated for this flow.
  • the packet P is introduced at the end of the queue F.FIFO which is updated accordingly (step 32).
  • the current size of the packet-related queue of F is then increased by the length L of the packet P (step 33).
  • FIG. 8 illustrates the operations performed when adding a new stream F in ActiveList (which corresponds to step 27 of FIG. 4).
  • the corresponding quantum F.Q can be deduced from certain fields of the header of the incoming packet belonging to the stream F, as explained above, by applying a classification function.
  • the deficit F.DC is initialized to the value zero.
  • the queue F.FIFO takes into account the incoming packet P of the stream F and the current size of the queue F. Queue is increased by the length L of the packet P (step 35).
  • the stream F is then inserted into the schedule (step 36).
  • the stream F is considered as the last stream processed in the cycle, while the next stream F becomes the first to be served when it is the turn of the scheduling WFQ to issue.
  • step 40 We first check if ActiveList is empty (step 40). If so, this means that there is no package to issue according to IOrdering DRR. As, moreover, the queue PQ is empty, it is therefore possible to set the Mute variable to the value "True” (step 41), and then to wait for a new packet (step 42).
  • stream F is considered at the beginning of the schedule, which must be served first, ie such as F ⁇ HeadRound (step 43).
  • step 44 It is checked whether this flow F is the stream 0, that is to say the dummy flow (step 44). If so, the value of a FairBytes counter is increased by the MTU number of bytes, which designates the number of bytes that could have been generated by the fictitious flow if it were a real flow class flow. the weakest (step 45). The FairBytes meter is used for the calculation of fair flow, as will be detailed below. We also update the variables TaiIRound and HeadRound, to take the values 0 and O.Next respectively, to indicate that the fictitious flow has been served and to prepare to serve the next stream of ActiveList, which is now the next stream to be served (step 46). The algorithm then continues with step 47.
  • step 47 is also carried out, in which the deficit value F. DC of this flow of its quantum F.Q. is increased. Then we extract a packet P of the F.FIFO file identifying all the stream packets entered in the system (step 48). This packet P is the one that arrived first in this queue and which is therefore at the head of F.FIFO.
  • the length L of this packet P is compared with the value of the deficit F.DC of the corresponding flow F. If L> F.DC, then it is not possible to deliver this packet P and the values of TaiIRound and HeadRound are updated so that the next stream is served at the next cycle (step 50).
  • the priority queue PQ is then revisited (step 51).
  • the packet P can be transmitted.
  • the variables F. Queue and F.DC are reduced by the length L of P to take into account the transmission of the packet P (step 52).
  • F.Queue we then check the value of F.Queue (step 53). If it is equal to zero, this means that the queue relating to the packets of F is empty, that is to say that the stream F is no longer active because it no longer has packets waiting for delivery.
  • the stream F can then be removed from ActiveList.
  • ActiveList is updated so that the next stream is served at the next cycle (step 54).
  • the priority queue PQ is then revisited (step 55).
  • the F.FIFO file is updated, so as to take into account the transmission of the packet P (step 56).
  • FIG. 10 shows a possible structure for ActiveList. This list includes one line per stream. Each line 60 contains the following data in columns (from left to right in the example shown):
  • F.Queue the current size, in bytes, of the packet queue of F;
  • F. R the parameter expressing the relative flow rate of the flow (one imposes without loss of generality that F.R> 1);
  • F.FinishTag a variable allowing the computation of the stamp of the packets and the clearing of BKD flows of ActiveList
  • F.FIFO the set of memory addresses and pointers to identify stream packets in first-come, first-served order.
  • FIG 11 shows a possible structure for a schedule that determines the order of transmission of packets.
  • Each flow F is associated with a timestamp F.TimeStamp.
  • the streams are visited in ascending order of stamp.
  • a stream emits the packet which is at the top of its queue F.FIFO.
  • the two global variables are used:
  • FIG. 12 illustrates the operations performed during the introduction of a packet P belonging to a stream F already present in ActiveList (which corresponds to step 22 of FIG. 4).
  • the packet P is introduced at the end of the corresponding F.FIFO queue (step 62).
  • the current size of the queue is updated to take into account the addition of the packet P, as well as the variable F.FinishTag (step 65).
  • the update of F.FinishTag takes into account the class of flow, the increment being inversely proportional to F.R.
  • FIG 13 illustrates the operations performed when adding a new stream F in ActiveList (which corresponds to step 27 of Figure 4).
  • Stream F is added to ActiveList (step 66).
  • F.FinishTag which is set to the value VirtualTime + L / FR
  • F.FIFO which contains the incoming packet P
  • F .Queue which takes the value of the length L of the packet P
  • the stream F with a timestamp adjusted to the value of VirtualTime, is also added to the schedule (step 68).
  • the main steps implemented with respect to the delivery of packets are shown schematically in FIG. 14.
  • ActiveList is then emptied for the case where there are still flows that are not active, since they do not appear in the schedule (step 72). You can also reset the VirtualTime and LastTime variables to zero.
  • the packet P which is at the head of the file F.FIFO, is then extracted, the current size F. is updated to the queue queue F by subtracting the length L from the packet P and the packet P is transmitted (step 76 ).
  • the fair bit rate can therefore be estimated as the bit rate that would be obtained by a dummy stream that would still be in the BKD state and whose quantum Q would be MTU in the case of a DRR mechanism or whose rate parameter R would be 1 in the case of a SFQ mechanism.
  • the estimation of the fair flow can be carried out according to the principles described in EP1478140.
  • the fair flow rate is used in particular to determine the reference time intervals, as will be explained below. It is recalled that the logical variable Silence makes it possible to detect at all moment if the system is empty or not. It is thus possible to calculate, from this variable, the total silence duration SilenceTime (t1, t2) in any time interval (t1, t2).
  • FairBytes (t) be the FairBytes counter value at time t.
  • the average fair flow rate DE (t1, t2) is estimated over an interval (t1, t2) according to the following formula:
  • the determination of the reference time intervals is such that a stream not yet registered in ActiveList must be detected as BKD if it transmits at a rate higher than a current estimate of the fair bitrate weighted by the weight necessary to take into account the flow class of the flow in question.
  • FairRate "- ⁇ FairRate + (1- ⁇ ) DE (n), with 0 ⁇ ⁇ 1.
  • ⁇ 1 be the start of a reference time interval, such as represented in FIG. 5. It is recalled that such an instant corresponds to a reset of the I.Bytes counters contained in the data structure as illustrated in FIG. 3.
  • the next instant ⁇ 2, which corresponds to the end a reference time interval (and at the beginning of another), is calculated: ⁇ 2 ⁇ 1 + MTU * 8 / FairRate where FairRate is the current estimate of the fair flow rate at time ⁇ 1.
  • T and ⁇ determines the reactivity of the algorithm.
  • T should be large enough to allow the transmission of at least MTU bytes in an interval ((n-1) T, nT) for any BKD stream.
  • ⁇ is close to 1, the shorter the short-term changes in the fair bit rate are dimmed.
  • the invention makes it possible to limit the capacity of the scheduling to a hundred or so flows, against several hundred waves according to known techniques, for a link load served of about 90%. This performance is accompanied by a reduction in the memory required for the scheduling structure and also significantly limits the complexity of the processing.
  • the invention also extends to any equipment capable of contributing to a packet scheduling according to the method described above, such as the equipment 2 of Figure 1 for example. It also extends to a router incorporating such equipment.
  • the invention also extends to a computer program comprising instructions able to implement the method described above.
  • a program can advantageously be installed and executed on equipment contributing to the scheduling of packets, such as a router for example.

Abstract

On détermine le flot (F) auquel appartient chaque nouveau paquet entrant (P). Lorsque ledit flot (F) fait partie d'une liste des flots actifs, on introduit le paquet dans un mécanisme d'ordonnancement à partage équitable (6). Lorsque ledit flot (F) ne fait pas partie de la liste des flots actifs : on obtient une estimation de la quantité de données entrantes (I.Bytes) relativement audit flot sur un intervalle de temps de référence ; on compare cette estimation et une valeur maximale (MaxBytes), l'intervalle de temps de référence ou la valeur maximale étant déterminé en fonction du débit équitable ; on ajoute ledit flot à la liste des flots actifs et on introduit le paquet (P) dans le mécanisme d'ordonnancement à partage équitable (6), si ladite estimation surpasse la valeur maximale ; et on introduit le paquet (P) à la fin d'une file d'attente prioritaire (5), dans le cas contraire.

Description

PROCEDE D'ORDONNANCEMENT DE PAQUETS APPARTENANT À DES FLOTS ET EQUIPEMENT ASSOCIÉ
La présente invention concerne l'ordonnancement de paquets appartenant à des flots, en vue de leur délivrance sur un lien de réseau par exemple.
Un flot comprend une succession de paquets de données, tels que des datagrammes IP ("Internet Protocol") par exemple. Il est identifié par un ensemble d'attributs présents dans l'en-tête de chacun des paquets qui le composent. Ces attributs comprennent par exemple une adresse IP source, une adresse IP de destination, un port source, un port de destination, une identification de protocole, un identifiant de flot ("flow label"), etc. Ainsi, tous les paquets comportant les mêmes valeurs d'attributs constituent un flot.
Un flot est considéré comme étant en cours à un instant donné si le temps écoulé depuis l'observation de son dernier paquet est inférieur à un certain seuil TO1 de l'ordre de quelques secondes par exemple.
Des mécanismes d'ordonnancement de paquets utilisant la notion de flot sont connus. Ils visent à établir un ordre dans la délivrance des paquets en sortie d'un routeur par exemple. Il existe en particulier une littérature abondante sur des algorithmes à partage équitable ("Fair Queuing"). Ces algorithmes assurent un certain niveau d'équité entre les flots lors de la délivrance des paquets. Parmi ceux-ci, on citera à titre illustratif le DRR ("Déficit Round Robin") qui a été décrit par Shreedar et Varghese dans "Efficient fair queuing using Déficit Round Robin", IEEE/ACM Transactions on Networking, Volume: 4, Issue: 3, June 1996, Pages:375 - 385 et le SFQ ("Start-time Fair Queueing") qui a été décrit par Goyal, Vin et Cheng dans "Start-time fair queueing: A scheduling algorithm for integrated services packet switching networks". IEEE/ACM ToN, Vol 5, No 5, Octobre 1997.
Le DRR est un mécanisme d'ordonnancement de complexité réduite basé sur le traitement des flots de manière cyclique selon un principe de répartition à permutation circulaire ("round robin"). Une file d'attente est associée à chaque flot. Le flot i est autorisé à transmettre au plus un quantum
Qj fixe d'octets par cycle. Il obtient ainsi un débit proportionnel à la valeur de son quantum Qj. Ce mécanisme permet d'obtenir un degré d'équité raisonnable grâce au maintien d'un compteur de déficit qui compense la différence éventuelle de taille entre les paquets des différents flots. La complexité est d'ordre 0(1), c'est-à-dire qu'elle est indépendante du nombre de flots en cours.
Le SFQ est un mécanisme faisant partie de la classe d'algorithme à partage équitable parfois appelée "self-clocked". L'ordonnancement des paquets à délivrer est défini par une estampille attribuée à chaque paquet. Le flot i est associé à un paramètre de débit Rj qui détermine le rapprochement entre les estampilles des paquets de ce flot.
Les flots, dans un réseau de paquets, sont de nature éphémère. Le nombre de flots en cours à chaque instant est une variable qui peut atteindre une valeur de plusieurs dizaines de milliers sur un lien de grande capacité (de 2,5 Gbps ou plus, par exemple). Cependant, le nombre de flots qui doivent être connus à chaque instant du mécanisme d'ordonnancement est considérablement plus faible. En effet, l'échéancier de délivrance des paquets établi par le mécanisme d'ordonnancement ne concerne que les flots, dits flots actifs, qui ont au moins un paquet en file d'attente en vue de sa délivrance à l'instant considéré ou, éventuellement, qui en ont eu dans un passé très récent. Ce fait rend réalisable l'ordonnancement à partage équitable même à des débits de lien très élevés, car le nombre de flots actifs est indépendant du débit du lien et se limite à quelques centaines par exemple.
En fait, à chaque instant, le trafic peut être décomposé en deux types de flots : des flots contraints ou "goulottés" notés BKD par la suite (pour "bottlenecked") dont le débit en entrée de l'ordonnancement dépasse le débit équitable réalisé par l'ordonnancement, et les autres flots notés NBD (pour "non-bottlenecked") dont le débit en entrée de l'ordonnancement est plus faible que le débit équitable.
EP1478140 divulgue un mécanisme opérant une différentiation implicite, c'est-à-dire sans signalisation spécifique ni réservation de ressource, de la qualité de service, en distinguant les flots BKD et NBD. Les paquets des flots NBD sont traités de façon prioritaire, alors que les flots BKD subissent IOrdonnancement à partage équitable. Ainsi, les flots de type "temps réel" (streaming audio ou vidéo par exemple) dont le débit est relativement faible subissent un délai paquet faible. A l'inverse, les flots de type "données" réalisent le débit maximal compatible avec un objectif de partage. Cependant, dans le mécanisme proposé par EP1478140, les flots NBD sont momentanément inclus dans la structure de l'ordonnancement lorsqu'ils émettent un paquet. Ceci est nécessaire pour permettre la détection des nouveaux flots BKD, mais a pour effet de requérir une capacité relativement importante pour cette structure par rapport à celle qui est strictement nécessaire pour traiter les flots BKD.
A titre illustratif, l'ordonnancement proposé dans les techniques susmentionnées peut nécessiter la prise en compte de plusieurs centaines de flots à certains instants pour une charge du lien desservi d'environ 90%. Le nombre de flots dépend en réalité des caractéristiques du trafic, notamment du rapport entre le débit du lien et le débit maximal des flots (c'est-à-dire le débit qu'ils pourraient atteindre si le lien était de capacité infinie, compte tenu des autres limitations de débit sur leur chemin). Plus ce rapport est élevé, pour une majorité de flots, plus le nombre de flots NBD est grand. Les flots NBD entrent alors plus souvent dans la structure de l'ordonnancement. Cet effet implique la nécessité d'utiliser une mémoire importante pour identifier les flots actifs. De plus, il implique une complexité de traitement relativement élevée.
On comprend en outre que la dépendance de la mémoire nécessaire à l'ordonnancement vis-à-vis des caractéristiques de trafic rend le dimensionnement des structures de l'ordonnancement assez peu robuste.
Par ailleurs, l'ordonnancement à partage équitable proposé par
EP1478140 prévoit une allocation identique pour tous les flots. Cette limitation peut être gênante dans certaines applications, notamment dans un réseau d'accès où l'on souhaiterait distinguer les utilisateurs selon les conditions prévues dans leur abonnement.
Un but de la présente invention est de limiter les inconvénients des techniques antérieures, rappelés plus haut. - A -
En particulier, un but de l'invention vise à limiter les informations à prendre en compte par l'ordonnancement et la complexité des traitements mis en œuvre.
Un autre but de l'invention vise à augmenter la robustesse du dimensionnement des structures de l'ordonnancement.
Un autre but de l'invention vise à permettre la prise en compte de conditions particulières pour des flots d'utilisateurs distincts.
L'invention propose ainsi un procédé d'ordonnancement de paquets de données appartenant à des flots, comprenant les étapes suivantes, relativement à chaque nouveau paquet entrant :
/a/ déterminer le flot auquel le paquet appartient, une classe de débit étant associée audit flot ;
IbI lorsque ledit flot fait partie d'une liste des flots actifs, introduire le paquet dans un mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Ici lorsque ledit flot ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes relativement audit flot sur un intervalle de temps de référence ;
- comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale, l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ;
- ajouter ledit flot à la liste des flots actifs et introduire le paquet dans le mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et - introduire le paquet à la fin d'une file d'attente prioritaire en vue de sa délivrance, dans le cas contraire.
Le mode de mise à jour de la liste des flots actifs permet de s'assurer que cette liste ne contient que des flots de la catégorie BKD. En effet, la comparaison entre l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et la valeur maximale permet de déterminer, avant la mise à jour de la liste des flots actifs, si le flot considéré est de type BKD ou NBD. On limite ainsi sensiblement la taille de cette liste, ainsi que sa dépendance vis-à-vis des caractéristiques du trafic. Cette réduction de taille permet en outre de limiter la complexité des traitements à mettre en oeuvre, notamment pour maintenir une liste des flots actifs à jour.
La valeur maximale prise en compte peut dépendre de la classe de débit associée au flot considéré. Elle peut aussi consister en une valeur fixe prédéterminée, en particulier dans le cas où l'estimation de la quantité de données entrantes se limite à un comptage du nombre de paquets entrants appartenant à ce flot.
Une structure de données simple, telle qu'un tableau, peut avantageusement être utilisée pour estimer la quantité de données entrantes relativement audit flot. Dans ce cas, l'obtention de l'estimation de la quantité de données entrantes relativement audit flot comprend la mise à jour, au cours dudit intervalle de temps de référence, d'un champ du tableau dont l'adresse correspond à une fonction d'un identifiant dudit flot, chaque champ du tableau étant remis à zéro au début de l'intervalle de temps de référence. La fonction utilisée est par exemple une fonction de hachage c'est-à-dire une fonction permettant de créer un condensé de l'identifiant dudit flot, avec un degré d'ambiguïté limité.
Le procédé peut en outre comprendre un contrôle d'admission préalable dans lequel on décide si le paquet doit être rejeté ou non avant l'étape IbI, en fonction d'une bande passante disponible et d'un niveau de charge de la file d'attente prioritaire. Un tel contrôle permet d'éviter les situations de congestion. Le procédé comprend aussi avantageusement la délivrance des paquets dans l'ordre suivant : on délivre d'abord l'ensemble des paquets introduits dans la file d'attente prioritaire, puis on délivre certains au moins des paquets introduits dans le mécanisme d'ordonnancement à partage équitable. L'invention propose en outre un équipement, tel qu'un gestionnaire de file d'attente dans un routeur par exemple, apte à contribuer à un ordonnancement de paquets de données appartenant à des flots, comprenant, relativement à chaque nouveau paquet entrant :
/a/ des moyens pour déterminer le flot auquel le paquet appartient, une classe de débit étant associée audit flot ;
IbI des moyens pour introduire le paquet dans un mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, lorsque ledit flot fait partie d'une liste des flots actifs, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Ici des moyens pour, lorsque ledit flot ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes relativement audit flot sur un intervalle de temps de référence ;
- comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale, l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ;
- ajouter ledit flot à la liste des flots actifs et introduire le paquet dans le mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et - introduire le paquet à la fin d'une file d'attente prioritaire en vue de sa délivrance, dans le cas contraire.
L'invention propose aussi un routeur agencé pour incorporer l'équipement susmentionné. L'invention propose enfin un produit programme d'ordinateur comprenant des instructions aptes à mettre en oeuvre un ordonnancement de paquets de données appartenant à des flots selon les étapes suivantes, relativement à chaque nouveau paquet entrant, lorsque ledit programme est chargé et exécuté par des moyens informatiques : /a/ déterminer le flot auquel le paquet appartient, une classe de débit étant associée audit flot ;
IbI lorsque ledit flot fait partie d'une liste des flots actifs, introduire le paquet dans un mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Ici lorsque ledit flot ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes relativement audit flot sur un intervalle de temps de référence ; - comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale, l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ; - ajouter ledit flot à la liste des flots actifs et introduire le paquet dans le mécanisme d'ordonnancement à partage équitable en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et - introduire le paquet à la fin d'une file d'attente prioritaire en vue de sa délivrance, dans le cas contraire. D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels :
- la figure 1 est un schéma illustrant une architecture simplifiée pour l'ordonnancement de paquets ;
- la figure 2 est un schéma illustrant un mode de délivrance des paquets ;
- la figure 3 est un schéma d'une structure de données utilisée pour la détection de nouveaux flots ;
- la figure 4 est un organigramme représentant des étapes principales de l'ordonnancement des paquets à délivrer ;
- la figure 5 est un schéma illustrant une détection de flot BKD ;
- la figure 6 est un exemple de structure d'une liste de flots actifs selon le mécanisme d'ordonnancement DRR ;
- la figure 7 est un organigramme représentant des étapes d'introduction d'un paquet d'un flot actif selon le mécanisme d'ordonnancement DRR ;
- la figure 8 est un organigramme représentant des étapes d'introduction d'un nouveau flot actif selon le mécanisme d'ordonnancement DRR ;
- la figure 9 est un organigramme représentant des étapes de délivrance de paquets selon le mécanisme d'ordonnancement DRR ; - la figure 10 est un exemple de structure d'une liste de flots actifs selon le mécanisme d'ordonnancement SFQ ;
- la figure 1 1 est un exemple de structure d'un échéancier selon le mécanisme d'ordonnancement SFQ ;
- la figure 12 est un organigramme représentant des étapes d'introduction d'un paquet d'un flot actif selon le mécanisme d'ordonnancement SFQ ;
- la figure 13 est un organigramme représentant des étapes d'introduction d'un nouveau flot actif selon le mécanisme d'ordonnancement SFQ ;
- la figure 14 est un organigramme représentant des étapes de délivrance de paquets selon le mécanisme d'ordonnancement SFQ. Principes généraux
La figure 1 montre schématiquement l'architecture permettant l'ordonnancement de paquets de données entrants dans le système. Le système en question comprend par exemple un routeur comprenant, entre autres éléments, un équipement 2 qui reçoit des paquets entrants 1 et délivre en sortie des paquets 7 correspondant à certains au moins des paquets entrants 1. Ces paquets 7 sont délivrés sur un lien contrôlé par l'équipement 2. Ils sont émis dans un certain ordre déterminé par l'ordonnancement mis en œuvre par le système.
Comme expliqué en introduction, les paquets 1 considérés appartiennent à des flots. Une distinction est établie entre les flots BKD et les flots NBD. A cet effet, on détecte, à l'arrivée d'un paquet 1 si le flot auquel ce paquet appartient est de type BKD ou NBD (alternative 4 sur la figure 1). Si le paquet considéré appartient à un flot NBD, il est introduit en fin d'une file d'attente prioritaire 5, notée PQ ("Priority Queue") par la suite. Cette file d'attente est par exemple de type FIFO ("First In First Out"). Si, au contraire, le paquet appartient à un flot BKD, il est alors introduit dans un mécanisme d'ordonnancement à partage équitable 6 de type WFQ ("Weighted Fair Queueing"), en vue de sa délivrance.
La figure 2 illustre le mode de délivrance des paquets 7 en sortie de l'ordonnancement. On vérifie tout d'abord l'état d'occupation de la file prioritaire PQ (étape 8). Si PQ contient au moins un paquet en attente, il doit être délivré en priorité (étape 9). Si la file d'attente PQ est de type FIFO, elle est alors vidée en commençant par la tête, c'est-à-dire par les paquets entrés en premier dans la file. En revanche, si PQ est vide, cela signifie que tous les paquets appartenant à des flots NBD ont déjà été délivrés. On délivre alors un ou plusieurs paquets, appartenant à des flots BKD, préalablement introduits dans le mécanisme d'ordonnancement WFQ 6 (étape 10). L'ordre d'émission de ces paquets dépend du mécanisme d'ordonnancement 6 mis en œuvre. On revient ensuite à la file PQ pour vérifier si elle contient de nouveaux paquets à délivrer. L'instant de retour vers la file PQ dépend également du mécanisme d'ordonnancement 6 mis en œuvre. Des exemples de tels mécanismes seront détaillés plus loin. Ainsi, les paquets des flots NBD peuvent être émis avec priorité sans nuire au débit réalisé par les flots BKD. Un tel traitement prioritaire permet en outre de réduire le délai paquet des flots NBD à faible débit, ce qui est avantageux pour beaucoup d'applications de type streaming.
On notera qu'un contrôle d'admission 3 peut être mis en œuvre, de façon optionnelle, en entrée de l'équipement 2. Un exemple d'un tel mécanisme est le contrôle implicite d'admission décrit dans EP1478140. Il vise à limiter les situations de congestion. A cet effet, on vérifie si la bande passante disponible du lien contrôlé par l'équipement 2 est supérieure à un premier seuil et si la charge due aux paquets mis en file d'attente prioritaire est inférieure à un second seuil. Dans le cas contraire, on n'accepte que les paquets des flots protégés, c'est-à-dire de flots qui sont admis à transmettre. Les autres paquets sont rejetés avant de pouvoir être soumis à l'ordonnancement. On protège ainsi la qualité de service des flots déjà entamés.
Selon l'invention, seuls les flots actifs de type BKD sont considérés relativement à l'ordonnancement WFQ. Le fonctionnement sera mieux compris à la lumière de la figure 4 qui illustre les principales étapes de l'ordonnancement mises en oeuvre pour chaque nouveau paquet entrant dans le système.
Soit P un paquet entrant de longueur L. Ce paquet appartient à un flot F dont un identifiant peut être déduit de l'en-tête du paquet P par le système considéré (par exemple l'équipement 2 de la figure 1). La longueur L de P est également détectée par le système. A l'arrivée de P dans le système, une variable logique "Silence" peut prendre la valeur "Faux" (étape 20), ce qui signifie qu'il existe, dans le système, au moins un paquet à délivrer. Cette variable sera utilisée pour le calcul du débit équitable relatif au mécanisme d'ordonnancement WFQ, comme cela sera détaillé plus loin. On vérifie la présence du flot F, par exemple à l'aide de son identifiant, dans une liste ActiveList (étape 21). ActiveList est construite pour comprendre l'ensemble des flots actifs de type BKD uniquement. Une telle liste a donc une taille limitée, notamment parce qu'elle n'inclut pas de flots de type NBD. Le mode de constitution de cette liste sera apparent plus loin. Si le flot F auquel le paquet P appartient fait déjà partie de ActiveList, ce qui signifie que F est un flot BKD déjà connu comme tel par le système, le paquet P est alors introduit dans le mécanisme d'ordonnancement WFQ, en vue de sa délivrance (étape 22).
Sinon, on estime le débit de F par rapport au débit équitable réalisé à l'instant courant par l'ordonnancement WFQ (étapes 23-25). Si le débit de F est supérieur à une estimation du débit équitable, le flot F est donc un flot de type BKD et il sera ajouté à ActiveList (étape 27). Dans ce cas, le paquet P du flot F est introduit dans le mécanisme d'ordonnancement WFQ en vue de sa délivrance (étape 26).
A l'inverse, si le débit de F est inférieur à l'estimation du débit équitable, cela signifie que F est un flot NBD et il convient alors d'introduire son paquet P à la fin de la file d'attente prioritaire PQ, en vue de sa délivrance (étape 28). On note que, dans ce cas, le flot F, bien qu'ayant un paquet en attente dans le système, n'est pas ajouté à ActiveList. C'est de cette façon qu'on garantit que ActiveList ne contient que des flots actifs de type BKD.
Pour estimer le débit du flot F par rapport au débit équitable réalisé à l'instant courant par l'ordonnancement WFQ, on tire avantageusement profit de la structure de données 11 illustrée sur la figure 3. Cette structure est un tableau comprenant M éléments de b bits chacun, avec M et b entiers. Chaque élément de ce tableau est identifié par une adresse I1, I2, ...I, ..., IM- Ces adresses correspondent par ailleurs à des valeurs obtenues chacune par l'application d'une fonction, par exemple une fonction de hachage, à l'identifiant d'un flot.
Lorsque, dans la succession d'opérations illustrée sur la figure 4, on a identifié le flot F, on calcule la valeur I correspondant à l'application de ladite fonction à l'identifiant de F. Cette valeur permet de retrouver le champ du tableau 11 , d'adresse I, afin de mettre à jour la valeur de compteur I.Bytes qui y est stockée (étape 23). Ainsi, le compteur I.Bytes est représentatif de la quantité de données reçue en entrée du système relativement au flot F1 pendant un intervalle de temps de référence. Chaque compteur I.Bytes est en effet remis à zéro au début de chaque intervalle de temps de référence. A l'étape 24 de la figure 4, on calcule par ailleurs le nombre maximal d'octets MaxBytes qu'un flot pourrait émettre dans un intervalle de temps de référence sans être de type BKD. Dans un exemple de réalisation de l'invention, on choisit les intervalles de temps de référence mentionnés ci-dessus de façon qu'un flot dont la classe de débit est la plus faible soit BKD s'il y émet plus qu'une valeur maximale de MTU octets, par exemple 1500 octets. Ce point sera détaillé plus loin. Lorsque le mécanisme d'ordonnancement WFQ est du type DRR,
MaxBytes peut être calculé comme suit. Si Qj est le quantum en octets d'un flot de classe de débit i, on impose Q_i ≥ MTU pour toute classe. Un flot de classe i est supposé BKD si, au cours d'un intervalle de temps de référence, le compteur correspondant dans le tableau 11 dépasse Q_i. On définit donc MaxBytes = Qj.
Lorsque le mécanisme d'ordonnancement WFQ est du type SFQ, MaxBytes peut être calculé comme suit. Soit Rj le paramètre de débit des flots de classe i, on impose la condition Rj ≥ 1 pour tout i. Un flot de classe i est supposé BKD si, au cours d'un intervalle de temps de référence, le compteur correspondant dans le tableau 11 dépasse Rj.MTU. On définit donc MaxBytes = Rj.MTU.
Une comparaison des valeurs I.Bytes et MaxBytes obtenues de la façon indiquée ci-dessus (étape 25) permet alors de déterminer si le flot considéré est de type BKD ou NBD. On note que la classe de débit d'un flot peut être déduite par exemple de champs de l'en-tête de chaque paquet entrant appartenant à ce flot. Par exemple, la classe peut être déduite des adresses IP ou du champ DSCP ("Diffserv Code Point") inclus dans l'en-tête des paquets.
Dans un autre exemple de réalisation, les intervalles de temps de référence sont indépendants du débit équitable réalisé à l'instant courant par l'ordonnancement WFQ. En revanche, à l'étape 25, le compteur I.Bytes est comparé à une valeur maximale MaxBytes qui dépend du débit équitable. Une combinaison des deux exemples de réalisation peut également être envisagée.
Dans ce cas, les intervalles de temps de référence et la valeur MaxBytes dépendent chacun du débit équitable.
Pour utiliser au mieux les b bits du compteur I.Bytes, on adapte la valeur de l'unité à la limite MaxBytes du flot concerné. Ainsi, pour un paquet de longueur L, le compteur I.Bytes correspondant serait incrémenté de
I = f(2b-1)L / MaxBytesl unités, où fxl désigne l'entier immédiatement supérieur ou égal à x. Ainsi, à l'arrivée d'un paquet qui ferait déborder le compteur, on décide que ce flot est BKD. Une telle décision est parfois erronée. On distingue les erreurs "faux positifs", où un flot est désigné BKD à tort, et les erreurs "faux négatifs", où un flot BKD n'est pas détecté comme tel.
Les erreurs faux positifs peuvent se produire lorsque le résultat de l'application de la fonction de hachage aux identifiants d'au moins deux flots actifs est identique. Il est alors possible que le champ I.Bytes correspondant soit surestimé car il est incrémenté de la quantité de données reçues pour chacun de ces flots dans l'intervalle de temps de référence considéré (voir étape 23). Cela peut conduire le compteur I.Bytes à déborder, si bien que l'un des flots actifs auquel il correspond est considéré à tort comme un flot BKD. On note qu'une telle collision entre deux flots distincts ne conduit à un faux positif que lorsqu'elle survient au cours d'un même intervalle de temps de référence.
Les erreurs faux positifs peuvent aussi se produire lorsque la granularité choisie pour le nombre b de bits des différents champs du tableau
I 1 est trop faible. Cela conduit en effet à une surestimation du nombre d'octets entrants pour chaque flot. Dans un exemple extrême, lorsque b=1 , les compteurs I.Bytes ne peuvent prendre que deux valeurs, 0 ou 1. Ainsi, lorsque dans un intervalle de temps de référence, tel que l'intervalle [τ3;τ4] de la figure 5, plus d'un paquet 13 d'un flot donné est reçu, le compteur I.Bytes associé à ce flot déborde, provoquant l'identification du flot comme un flot BKD. Pourtant, la quantité de données totale correspondant aux deux paquets 13 reçus dans cet intervalle peut être inférieure à la valeur maximale MaxBytes, par exemple si chacun des paquets 13 reçus contient 500 octets, soit un total de 1000 octets, alors que MaxBytes vaut 1500 octets, une valeur typique de MTU.
Les erreurs faux négatifs peuvent se produire lorsqu'on tarde à reconnaître un flot BKD dont l'arrivée des paquets est mal placée par rapport aux bornes des intervalles de temps de référence, qui correspondent aux instants de réinitialisation des compteurs I.Bytes. Ainsi, dans l'exemple illustré sur la figure 5, des paquets entrants 13 appartenant à un flot sont reçus à raison d'un par intervalle de temps de référence lors des deux premiers intervalles [τ-ι;τ2] et [τ2;τ3] représentés sur l'axe des temps 12. C'est seulement dans l'intervalle suivant [τ3;τ4] que deux paquets 13 sont détectés, si bien que le flot peut alors être considéré comme étant BKD, alors que le débit d'arrivée de ses paquets n'a pas sensiblement varié sur la période représentée.
On note que la probabilité de faux positifs dépend du choix de la taille de la structure de données de la figure 3. Plus le nombre M de compteurs dans la structure est grand, plus faible est la probabilité que le hachage des identifiants de deux flots distincts coïncide avec la même adresse de compteur. En outre, plus la taille b d'un compteur est grande, plus le nombre d'octets reçus relativement à un flot donné est pris en compte de façon précise.
La probabilité de faux négatifs n'est, quant à elle, significative que pour les flots dont le débit est proche du débit équitable. Les premiers paquets d'un tel flot sont envoyés à la file d'attente PQ, tant que le flot n'est pas identifié comme un flot BKD, ce qui ne nuit guère à l'efficacité de l'ordonnancement.
Comme cela a été évoqué plus haut, le cas particulier b=1 mérite une attention particulière. Dans ce cas en effet, tout flot est considéré comme BKD dès qu'il émet plus d'un seul paquet dans un intervalle de temps de référence, quelle que soit sa classe de débit. Malgré l'imprécision qui en résulte pour la détermination des flots BKD/NBD, ce choix est attractif car il permet d'obtenir une taille très faible pour la structure de données de la figure 3. Il présente en outre une complexité réduite du fait de la non prise en compte de la classe de débit. On notera que la structure de données qui a été présentée en référence à la figure 3 consiste en une simple structure linéaire de M compteurs, chacun correspondant à l'unique image d'un ensemble d'identifiants de flot. De façon générale, il est possible de réduire la taille de la mémoire nécessaire en adoptant une structure plus complexe. En particulier, les techniques du filtre de Bloom, décrites dans l'article de B. Bloom, "Space/time tradeoffs in hash coding with allowable errors, Commun. ACM, vol. 13, no. 7, pp. 422-426, JuIy 1970", ou de bitmaps multi- étages décrits dans l'article de C. Estan, G. Varghese, "New directions in traffic measurement and accounting, Proceedings of ACM Sigcomm 2002" font appel à plusieurs fonctions de hachage appliquées à l'identifiant de flot et désignant un ensemble de compteurs. Dans l'application présente, chaque compteur de l'ensemble correspondant à un flot serait mis à jour comme décrit précédemment. La condition BKD serait présumée si tous ces compteurs devaient déborder lors de l'arrivée d'un nouveau paquet.
Mode de réalisation de l'invention avec DRR
On décline ci-après les principes de l'invention dans un mode de réalisation particulier, dans lequel le mécanisme d'ordonnancement à partage équitable utilisé est le mécanisme connu DRR.
La figure 6 montre une structure possible pour ActiveList. Cette liste comprend une ligne par flot. Chaque ligne 31 contient les données suivantes en colonnes (de la gauche vers la droite sur l'exemple illustré) : F : un identifiant du flot ;
F. Queue : la taille courante, en octets, de la file d'attente relative aux paquets de F ;
F. Q : le quantum exprimant le nombre d'octets que le flot est autorisé à émettre pendant un cycle de l'algorithme ; F.DC : le compteur de déficit du flot ;
F.FIFO : l'ensemble d'adresses mémoire et de pointeurs permettant d'identifier les paquets du flot dans l'ordre premier arrivé, premier servi ; et
F.Next : le pointeur vers le prochain flot de la liste devant être servi (l'ensemble des pointeurs définit l'échéancier). Une entrée spécifique 30, dans ActiveList, est réservée pour un flot fictif appelé flot 0. Ce flot s'inscrit dans l'échéancier et permet de délimiter les cycles : un nouveau cycle de l'algorithme DRR commence après chaque visite du flot 0 (où bien entendu aucun paquet n'est émis).
Pour compléter la définition de l'échéancier, on utilise deux variables globales :
- HeadRound : désigne le flot qui doit être servi en premier, lorsque c'est au tour de l'ordonnancement WFQ d'émettre ; et - TailRound : désigne le flot encore présent dans ActiveList qui a émis un paquet en dernier ou bien le flot fictif 0 si celui-ci a reçu une visite après cette émission.
La figure 7 illustre les opérations effectuées lors de l'introduction d'un paquet P appartenant à un flot F déjà présent dans ActiveList (ce qui correspond à l'étape 22 de la figure 4), en supposant que la file des paquets n'est pas saturée pour ce flot. Le paquet P est introduit à la fin de la file F.FIFO qui est mise à jour en conséquence (étape 32). La taille courante de la file d'attente relative aux paquets de F est alors augmentée de la longueur L du paquet P (étape 33).
La figure 8 illustre les opérations effectuées lors de l'ajout d'un nouveau flot F dans ActiveList (ce qui correspond à l'étape 27 de la figure 4). Le quantum F.Q correspondant peut se déduire de certains champs de l'entête du paquet entrant appartenant au flot F, comme expliqué plus haut, en appliquant une fonction de classification. Par ailleurs, le déficit F.DC est initialisé à la valeur zéro. La file d'attente F.FIFO prend en compte le paquet P entrant du flot F et la taille courante de la file F. Queue est augmentée de la longueur L du paquet P (étape 35).
On insère ensuite le flot F dans l'échéancier (étape 36). A cet effet, le flot F est considéré comme le dernier flot traité dans le cycle, tandis que le flot suivant F devient le premier à devoir être servi lorsque c'est au tour de l'ordonnancement WFQ d'émettre.
Les principales étapes mises en œuvre relativement à la délivrance de paquets sont schématisées sur la figure 9. Ces étapes ne sont mises en œuvre que lorsque la file d'attente prioritaire PQ est vide.
On suppose ci-après que la file PQ n'est revisitée qu'à la fin du service de l'ensemble des paquets représentant le quantum du flot considéré. On notera qu'une autre hypothèse selon laquelle on permettrait le service d'un éventuel paquet présent dans la file PQ entre deux paquets du quantum d'un même flot est également possible.
On vérifie tout d'abord si ActiveList est vide (étape 40). Dans l'affirmative, cela signifie qu'il n'y a aucun paquet à émettre selon IOrdonnancement DRR. Comme par ailleurs, la file PQ est vide, on peut donc régler la variable Silence à la valeur "Vrai" (étape 41), puis se tenir dans l'attente d'un nouveau paquet (étape 42).
Si, au contraire, ActiveList n'est pas vide, on considère le flot F en tête de l'échéancier, qui doit être servi en premier, c'est-à-dire tel que F≈HeadRound (étape 43).
On vérifie si ce flot F est le flot 0, c'est-à-dire le flot fictif (étape 44). Dans l'affirmative, on augmente du nombre MTU d'octets la valeur d'un compteur FairBytes qui désigne le nombre d'octets qu'aurait pu émettre le flot fictif s'il s'agissait d'un flot réel de classe de débit la plus faible (étape 45). Le compteur FairBytes est utilisé pour le calcul du débit équitable, comme cela sera détaillé plus loin. On met aussi également à jour les variables TaiIRound et HeadRound, pour prendre les valeurs 0 et O.Next respectivement, afin d'indiquer que le flot fictif a été servi et de s'apprêter à servir le flot suivant de ActiveList, qui constitue désormais le prochain flot à servir (étape 46). L'algorithme se poursuit alors avec l'étape 47.
Dans le cas où le flot F n'est pas le flot fictif, on passe également à l'étape 47, dans laquelle on augmente la valeur de déficit F. DC de ce flot de son quantum F.Q. Puis on extrait un paquet P de la file F.FIFO identifiant l'ensemble des paquets du flot entrés dans le système (étape 48). Ce paquet P est celui arrivé en premier dans cette file et qui se situe donc en tête de F.FIFO.
On compare la longueur L de ce paquet P à la valeur du déficit F.DC du flot F correspondant. Si L>F.DC, il n'est alors pas possible de délivrer ce paquet P et l'on met à jour les valeurs de TaiIRound et HeadRound pour que le flot suivant soit servi au prochain cycle (étape 50). La file prioritaire PQ est ensuite revisitée (étape 51).
Si L≤F.DC, le paquet P peut être émis. Les variables F. Queue et F.DC sont diminuées de la longueur L de P pour prendre en compte l'émission du paquet P (étape 52).
On vérifie alors la valeur de F.Queue (étape 53). Si elle est égale à zéro, cela signifie que la file d'attente relative aux paquets de F est vide, c'est- à-dire que le flot F n'est plus actif car il n'a plus de paquets en attente de délivrance. Le flot F peut alors être sorti de ActiveList. En outre, ActiveList est mise à jour pour que le flot suivant soit servi au prochain cycle (étape 54). La file prioritaire PQ est ensuite revisitée (étape 55).
Si, au contraire, la valeur de F.Queue est non nulle, la file F.FIFO est mise à jour, de façon à prendre en compte l'émission du paquet P (étape 56).
Dans l'hypothèse choisie où l'ensemble du quantum du flot est délivré avant de revisiter la file prioritaire PQ, on retourne ensuite à l'étape 48, en vue d'émettre d'autres paquets pour le flot F considéré.
Mode de réalisation de l'invention avec SFQ
On décline ci-après les principes de l'invention dans un mode de réalisation particulier, dans lequel le mécanisme d'ordonnancement à partage équitable utilisé est le mécanisme connu SFQ. La figure 10 montre une structure possible pour ActiveList. Cette liste comprend une ligne par flot. Chaque ligne 60 contient les données suivantes en colonnes (de la gauche vers la droite sur l'exemple illustré) :
F : un identifiant du flot ;
F.Queue : la taille courante, en octets, de la file d'attente relative aux paquets de F ;
F. R : le paramètre exprimant le débit relatif du flot (on impose sans perte de généralité que F.R > 1) ;
F.FinishTag : une variable permettant le calcul de l'estampille des paquets et l'effacement de flots BKD de ActiveList ; et F.FIFO : l'ensemble d'adresses mémoire et de pointeurs permettant d'identifier les paquets du flot dans l'ordre premier arrivé, premier servi.
La figure 11 montre une structure possible pour un échéancier qui détermine l'ordre d'émission des paquets. A chaque flot F est associée une estampille F.TimeStamp. Les flots sont visités en ordre croissant d'estampille. A chaque visite, selon l'échéancier, un flot émet le paquet qui se trouve en tête de sa file d'attente F.FIFO. On utilise en outre les deux variables globales :
- VirtualTime : permet le calcul des estampilles ; et
- LastTime : est utilisée pour mesurer les intervalles de temps de référence. La figure 12 illustre les opérations effectuées lors de l'introduction d'un paquet P appartenant à un flot F déjà présent dans ActiveList (ce qui correspond à l'étape 22 de la figure 4). Le paquet P est introduit à la fin de la file F.FIFO correspondante (étape 62).
Il peut arriver que la file F.FIFO de ce flot soit vide (étape de vérification 63 de la valeur de F.Queue). Si elle l'est, on réinscrit le flot à l'échéancier avec une estampille égale à F.FinishTag (étape 64).
Lorsque F.FIFO n'est pas vide ou une fois le flot réinscrit à l'échéancier, on met à jour la taille courante de la file pour prendre en compte l'ajout du paquet P, ainsi que la variable F.FinishTag (étape 65). La mise à jour de F.FinishTag tient compte de la classe de débit, l'incrément étant inversement proportionnel à F.R.
La figure 13 illustre les opérations effectuées lors de l'ajout d'un nouveau flot F dans ActiveList (ce qui correspond à l'étape 27 de la figure 4). Le flot F est ajouté à ActiveList (étape 66). Puis, on initialise les différents champs de ActiveList correspondant à ce flot F, c'est-à-dire F.R, F.FinishTag qui est réglé à la valeur VirtualTime+L/F.R, F.FIFO qui contient le paquet P entrant et F.Queue qui prend la valeur de la longueur L du paquet P (étape 67).
Le flot F, avec une estampille ajustée à la valeur de VirtualTime, est par ailleurs ajouté à l'échéancier (étape 68). Les principales étapes mises en œuvre relativement à la délivrance de paquets sont schématisées sur la figure 14. On vérifie tout d'abord si l'échéancier est vide (étape 70). Dans l'affirmative, cela signifie qu'il n'y a aucun paquet à émettre selon l'ordonnancement SFQ. Comme par ailleurs, la file PQ est vide, on peut donc régler la variable Silence à la valeur "Vrai" (étape 71). On vide ensuite ActiveList pour le cas où il y resterait des flots qui ne sont cependant pas actifs, puisqu'ils ne figurent pas dans l'échéancier (étape 72). On peut aussi réinitialiser les variables VirtualTime et LastTime à zéro.
Si l'échéancier est non vide, on extrait la tête de l'échéancier, à savoir le flot F associé à l'estampille F.TimeStamp (étape 73). Puis on règle la variable VirtualTime à la valeur de F.TimeStamp (étape 74). On met ensuite à jour un compteur FairBytes mesurant la quantité d'octets qu'aurait pu émettre un flot BKD fictif de paramètre de débit R=1 (un octet pour chaque unité de progression du temps virtuel) s'il s'agissait d'un flot réel. On met également à jour LastTime à l'aide de VirtualTime (étape 75).
On extrait ensuite le paquet P qui se trouve en tête de la file F.FIFO, on met à jour la taille courante F. Queue de la file F en lui retranchant la longueur L du paquet P et on émet le paquet P (étape 76).
Puis, on vérifie si la taille F. Queue est positive. Si elle l'est, on réintroduit le flot F dans l'échéancier avec une nouvelle valeur d'estampille réglée à F.TimeStamp+L/F.R. En outre, la file F.FIFO est mise à jour, de façon à prendre en compte l'émission du paquet P (étape 78).
Finalement, on met à jour ActiveList en supprimant tout flot G qui y figure encore alors que G.Finishtag < VirtualTime, c'est-à-dire tous les flots qui ne sont donc plus dans la catégorie BKD (étape 79).
Débit équitable et prise en compte pour déterminer les flots BKD On rappelle que le débit équitable désigne le débit présenté par les paquets de chaque flot BKD en sortie du mécanisme d'ordonnancement à partage équitable (à la classe de débit dudit flot près).
Le débit équitable peut donc être estimé comme le débit qu'obtiendrait un flot fictif qui serait toujours dans l'état BKD et dont le quantum Q vaudrait MTU dans le cas d'un mécanisme DRR ou dont le paramètre de débit R vaudrait 1 dans le cas d'un mécanisme SFQ. L'estimation du débit équitable peut être réalisée selon les principes décrits dans EP1478140.
Le débit équitable sert notamment pour déterminer les intervalles de temps de référence, comme cela sera explicité plus loin. On rappelle que la variable logique Silence permet de détecter à tout instant si le système est vide ou non. On peut ainsi calculer, à partir de cette variable, la durée totale de silence SilenceTime(t1 ,t2) dans tout intervalle de temps (t1 ,t2).
On rappelle en outre que le compteur FairBytes est incrémenté, dans le cas de DRR, à chaque passage par la file du flot 0 (voir figure 9) et, dans le cas de SFQ, chaque fois que le temps virtuel VirtualTime change (voir figure
14). Il permet ainsi de mesurer le nombre d'octets qu'aurait pu émettre un flot fictif BKD.
Soit FairBytes(t) la valeur du compteur FairBytes à l'instant t. On estime le débit équitable moyen DE(t1 ,t2) au cours d'un intervalle (t1, t2) selon la formule suivante :
DE(t1,t2) =
Max {SilenceTime(t1 ,t2).C / (t2-t1) ; (FairBytes(t2)-FairBytes(t1))*8 / (t2-t1)} où C désigne le débit total offert par le lien considéré. On comprend que le premier terme de cette formule sera prépondérant en cas de faible charge du système, tandis que le second terme sera prépondérant en cas de charge élevée.
Comme cela a été décrit plus haut, la détermination des intervalles de temps de référence est telle qu'un flot non encore inscrit dans ActiveList doit être détecté comme BKD s'il émet à un débit supérieur à une estimation courante du débit équitable pondérée par le poids nécessaire pour tenir compte de la classe de débit du flot en question.
Une méthode possible pour faire cette estimation est la suivante. On évalue tout d'abord le débit équitable DE(n) à des instants nT, où T est un intervalle fixe (par exemple de 100 ms) et n est un entier, de façon que DE(n)=DE((n-1)T,nT). Puis, on effectue un lissage, par exemple un lissage exponentiel, des évaluations DE(n), c'est-à-dire qu'à chaque instant nT, on remet à jour l'estimation FairRate du débit équitable lissé comme suit :
FairRate «- α FairRate + (1-α) DE(n), avec 0 < α < 1. Soit τ1 le début d'un intervalle de temps de référence, tel que celui représenté sur la figure 5. On rappelle qu'un tel instant correspond à une remise à zéro des compteurs I.Bytes contenus dans la structure de données telle qu'illustrée sur la figure 3. L'instant suivant τ2, qui correspond à la fin d'un intervalle de temps de référence (et au début d'un autre), se calcule : τ2 = τ1 + MTU * 8 / FairRate où FairRate est l'estimation courante du débit équitable à l'instant τ1.
On définit ainsi la suite des intervalles de temps de référence. Comme cela est apparent à la lumière de ce qui précède, ces intervalles dépendent donc directement du débit équitable réalisé par le mécanisme d'ordonnancement à partage équitable mis en œuvre.
Le choix de T et de α détermine la réactivité de l'algorithme. T devrait être assez grand pour permettre l'émission d'au moins MTU octets dans un intervalle ((n-1)T, nT) pour tout flot BKD. Plus α est proche de 1 , plus les variations à court terme du débit équitable sont estompées. A titre d'exemple, un choix de T=100 ms et α=0.9 semble produire une réduction importante du nombre de flots dans ActiveList, ainsi qu'une faible dégradation de performance par rapport aux algorithmes WFQ classiques. Le choix semble par ailleurs peu critique dans une plage assez importante.
Des simulations avec traces de trafic réel mettant en œuvre un partage équitable sans pondération (Q_i = MTU ou R_i = 1) ont permis d'observer une réduction du nombre maximal de flots dans ActiveList de 540, avec l'algorithme classique SFQ, à seulement 4 selon la présente invention, pour un lien concentrant le trafic d'utilisateurs ADSL (dont le débit par flot est en principe inférieur à 1 Mbps) et chargé à 90%. Ce gain extrême résulte du fait que, dans cet exemple, aucun flot n'est réellement dans la classe BKD. Pour une trace observée sur un lien du réseau de recherche américain Abilene, la réduction au même taux de charge est de 362 à 128 flots. Ces résultats correspondent au choix pour la structure de données comprenant les valeurs I.Bytes d'un bitmap
(c'est à dire que b=1). La réduction supplémentaire obtenue avec des compteurs de 8 bits permet d'atteindre 106 flots au lieu de 128 dans le dernier cas par exemple. De façon générale, l'invention permet de limiter la capacité de l'ordonnancement à une centaine de flots environ, contre plusieurs centaines de flots selon les techniques connues, pour une charge du lien desservi d'environ 90%. Cette performance s'accompagne d'une réduction de la mémoire nécessaire pour la structure de l'ordonnancement et limite en outre sensiblement la complexité des traitements.
De plus, cette capacité est largement indépendante des caractéristiques du trafic et constitue donc un dimensionnement robuste.
On note que l'invention a été plus particulièrement décrite dans les cas particuliers des mécanismes d'ordonnancement à partage équitable DRR et
SFQ. Toutefois, on comprendra qu'elle s'applique également à tout autre mécanisme d'ordonnancement à partage équitable, tels qu'un mécanisme à répartition par permutation circulaire, un mécanisme à estampillage, ou autre.
L'invention s'étend également à tout équipement apte à contribuer à un ordonnancement de paquets selon le procédé décrit ci-dessus, tel que l'équipement 2 de la figure 1 par exemple. Elle s'étend aussi à un routeur incorporant un tel équipement.
L'invention s'étend en outre à un programme d'ordinateur comprenant des instructions aptes à mettre en œuvre le procédé décrit ci-dessus. Un tel programme peut avantageusement être installé et exécuté sur un équipement contribuant à l'ordonnancement de paquets, tel qu'un routeur par exemple.

Claims

R E V E N D I C A T I O N S
1. Procédé d'ordonnancement de paquets de données appartenant à des flots, comprenant les étapes suivantes, relativement à chaque nouveau paquet entrant (1 ;P) :
/a/ déterminer le flot (F) auquel le paquet (P) appartient, une classe de débit étant associée audit flot ;
IbI lorsque ledit flot (F) fait partie d'une liste des flots actifs, introduire le paquet dans un mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Ici lorsque ledit flot (F) ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes (I.Bytes) relativement audit flot sur un intervalle de temps de référence ;
- comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale (MaxBytes), l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ;
- ajouter ledit flot à la liste des flots actifs et introduire le paquet (P) dans le mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et
- introduire le paquet (P) à la fin d'une file d'attente prioritaire (5) en vue de sa délivrance, dans le cas contraire.
2. Procédé selon la revendication 1 , dans .lequel ladite valeur maximale (MaxBytes) est une quantité de données dépendant de la classe de débit associée audit flot (F).
3. Procédé selon la revendication 1 , dans lequel l'estimation de la quantité de données entrantes (I.Bytes) relativement audit flot (F) comprend une estimation d'un nombre de paquets entrants dudit flot sur l'intervalle de temps de référence et dans lequel ladite valeur maximale (MaxBytes) est un nombre fixe de paquets indépendant de la classe de débit associée audit flot.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'obtention de l'estimation de la quantité de données entrantes
(I.Bytes) relativement audit flot (F) comprend la mise à jour, au cours dudit intervalle de temps de référence, d'un champ d'un tableau (11) dont l'adresse (I) correspond à une fonction d'un identifiant dudit flot, chaque champ du tableau étant remis à zéro au début de l'intervalle de temps de référence.
5. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'estimation du débit équitable comprend des évaluations successives du débit équitable et un lissage de certaines au moins desdites évaluations successives.
6. Procédé selon l'une quelconque des revendications précédentes, dans lequel le mécanisme d'ordonnancement à partage équitable (6) fait partie de l'un au moins d'un mécanisme à répartition par permutation circulaire et d'un mécanisme à estampillage.
7. Procédé selon l'une quelconque des revendications précédentes, comprenant un contrôle d'admission préalable dans lequel on décide si le paquet (P) doit être rejeté ou non avant l'étape IbI, en fonction d'une bande passante disponible et d'un niveau de charge de la file d'attente prioritaire.
8. Procédé selon l'une quelconque des revendications précédentes, dans lequel on délivre l'ensemble des paquets introduits dans la file d'attente prioritaire (5), puis on délivre certains au moins des paquets introduits dans le mécanisme d'ordonnancement à partage équitable (6).
9. Equipement (2) apte à contribuer à un ordonnancement de paquets de données appartenant à des flots, comprenant, relativement à chaque nouveau paquet entrant (1 ;P) :
/a/ des moyens pour déterminer le flot (F) auquel le paquet (P) appartient, une classe de débit étant associée audit flot ;
IbI des moyens pour introduire le paquet dans un mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, lorsque ledit flot (F) fait partie d'une liste des flots actifs, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Id des moyens pour, lorsque ledit flot (F) ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes (I.Bytes) relativement audit flot sur un intervalle de temps de référence ;
- comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale (MaxBytes), l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ;
- ajouter ledit flot à la liste des flots actifs et introduire le paquet (P) dans le mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et
- introduire le paquet (P) à la fin d'une file d'attente prioritaire (5) en vue de sa délivrance, dans le cas contraire.
10. Routeur agencé pour incorporer un équipement selon la revendication 9.
11. Produit programme d'ordinateur comprenant des instructions aptes à mettre en œuvre un ordonnancement de paquets de données appartenant à des flots selon les étapes suivantes, relativement à chaque nouveau paquet entrant (1 ;P), lorsque ledit programme est chargé et exécuté par des moyens informatiques :
/a/ déterminer le flot (F) auquel le paquet (P) appartient, une classe de débit étant associée audit flot ;
Ib/ lorsque ledit flot (F) fait partie d'une liste des flots actifs, introduire le paquet dans un mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, le mécanisme d'ordonnancement à partage équitable étant agencé pour délivrer les paquets de chaque flot sensiblement selon un même débit équitable pondéré par la classe de débit associée au flot correspondant ;
Ici lorsque ledit flot (F) ne fait pas partie de la liste des flots actifs :
- obtenir une estimation de la quantité de données entrantes (I.Bytes) relativement audit flot sur un intervalle de temps de référence ;
- comparer l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence et une valeur maximale (MaxBytes), l'un au moins parmi l'intervalle de temps de référence et la valeur maximale étant déterminé en fonction d'une estimation du débit équitable ;
- ajouter ledit flot à la liste des flots actifs et introduire le paquet (P) dans le mécanisme d'ordonnancement à partage équitable (6) en vue de sa délivrance, si l'estimation de la quantité de données entrantes relativement audit flot sur l'intervalle de temps de référence surpasse la valeur maximale ; et
- introduire le paquet (P) à la fin d'une file d'attente prioritaire (5) en vue de sa délivrance, dans le cas contraire.
PCT/FR2006/000878 2005-05-02 2006-04-20 Procede d'ordonnancement de paquets appartenant à des flots et equipement associé WO2006117448A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/919,752 US7933204B2 (en) 2005-05-02 2006-04-20 Method for organizing packets belonging to streams, and associated equipment
EP06755432A EP1878180B1 (fr) 2005-05-02 2006-04-20 Procede d'ordonnancement de paquets appartenant à des flots et equipement associé

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0504447 2005-05-02
FR0504447A FR2885275A1 (fr) 2005-05-02 2005-05-02 Procede d'ordonnancement de paquets appartenant a des flots et equipement associe

Publications (1)

Publication Number Publication Date
WO2006117448A1 true WO2006117448A1 (fr) 2006-11-09

Family

ID=35276339

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/000878 WO2006117448A1 (fr) 2005-05-02 2006-04-20 Procede d'ordonnancement de paquets appartenant à des flots et equipement associé

Country Status (4)

Country Link
US (2) US7933204B2 (fr)
EP (1) EP1878180B1 (fr)
FR (1) FR2885275A1 (fr)
WO (1) WO2006117448A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2063148B1 (fr) * 2007-11-26 2014-04-30 Getrag Ford Transmissions GmbH Procédé destiné à la commande d'un embrayage
DE102008040662A1 (de) * 2008-07-24 2010-01-28 Zf Friedrichshafen Ag Verfahren zum Betreiben eines Antriebsstrangs
KR101655642B1 (ko) * 2015-01-05 2016-09-07 현대자동차주식회사 하이브리드 차량용 엔진클러치의 키스포인트 학습 방법

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1478140A1 (fr) * 2003-04-24 2004-11-17 France Telecom Procédé et dispositif d'ordonnancement de paquets sur un lien de réseau en fonction d'une priorité basée sur l'analyse du débit d'arrivée des flots

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5404982A (en) * 1993-03-04 1995-04-11 Eaton Corporation Clutch pedal dashpot driveline torque limiter
EP0748086A1 (fr) * 1995-06-09 1996-12-11 Siemens Aktiengesellschaft Procédé pour la planification de cellules de message sortantes d'un réseau ATM
CA2245367A1 (fr) * 1998-08-19 2000-02-19 Newbridge Networks Corporation Ordonnanceur de largeur de bande a deux elements destine aux systemes numeriques de communications multi-classes
US6975638B1 (en) * 2000-10-13 2005-12-13 Force10 Networks, Inc. Interleaved weighted fair queuing mechanism and system
AU2002311074A1 (en) * 2001-04-02 2002-10-15 Luk Lamellen Und Kupplungsbau Beteiligungs Kg Method for controlling an automatic clutch
WO2002088879A2 (fr) * 2001-04-27 2002-11-07 Wanwall, Inc. Procedes par mise en files d'attentes ponderee et equitable et appareil de protection contre les surcharges dans les noeuds d'un reseau distribue
AUPR688201A0 (en) * 2001-08-09 2001-08-30 University Of Melbourne, The An active queue management process
EP1313274A3 (fr) * 2001-11-19 2003-09-03 Matsushita Electric Industrial Co., Ltd. Dispositif de transmission de paquets et méthode de traitement de la transmission des paquets
JP4383072B2 (ja) * 2002-03-26 2009-12-16 ロベルト・ボッシュ・ゲゼルシャフト・ミト・ベシュレンクテル・ハフツング 車両のクラッチ状態の判定方法およびそれを実施する装置
JP4639743B2 (ja) * 2003-12-12 2011-02-23 株式会社デンソー クラッチ状態検出装置
DE102006007740B4 (de) * 2006-02-20 2014-01-02 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Verfahren und Vorrichtung zur Regelung des Antriebsschlupfes angetriebener Räder eines Fahrzeugs mit der Motordrehzahl als Stellgröße
US8489295B2 (en) * 2008-06-23 2013-07-16 GM Global Technology Operations LLC Up-shift control in an automatic transmission with negative input torque

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1478140A1 (fr) * 2003-04-24 2004-11-17 France Telecom Procédé et dispositif d'ordonnancement de paquets sur un lien de réseau en fonction d'une priorité basée sur l'analyse du débit d'arrivée des flots

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
A. KORTEBI, S. OUESLATI AND J. ROBERTS: "Cross-protect: implicit service differentiation and admission control", IEEE HPSR 2004, April 2004 (2004-04-01), Phoenix, USA, XP002354320 *
A. KORTEBI,L. MUSCARIELLO, S. OUESLATI,J. ROBERTS: "On the Scalability of Fair Queueing", ACM HOTNETS-III, November 2004 (2004-11-01), SAN DIEGO, USA,, XP002354321 *
BENNETT J C R ET AL: "High speed, scalable, and accurate implementation of packet fair queueing algorithms in ATM networks", NETWORK PROTOCOLS, 1997. PROCEEDINGS., 1997 INTERNATIONAL CONFERENCE ON ATLANTA, GA, USA 28-31 OCT. 1997, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 28 October 1997 (1997-10-28), pages 7 - 14, XP010258681, ISBN: 0-8186-8061-X *

Also Published As

Publication number Publication date
US20100278053A1 (en) 2010-11-04
EP1878180B1 (fr) 2013-03-13
US20090131223A1 (en) 2009-05-21
US7933204B2 (en) 2011-04-26
EP1878180A1 (fr) 2008-01-16
FR2885275A1 (fr) 2006-11-03

Similar Documents

Publication Publication Date Title
EP1813081B1 (fr) Procede et dispositif d&#39;ordonnancement de paquets pour leur routage dans un reseau avec determination implicite des paquets a traiter en priorite
EP1478140B1 (fr) Procédé et dispositif d&#39;ordonnancement de paquets sur un lien de réseau en fonction d&#39;une priorité basée sur l&#39;analyse du débit d&#39;arrivée des flots
EP1788834B1 (fr) Dispositif et procédé de génération de rafales composites à préservation de priorité
EP1096827A1 (fr) Procédé de mise en conformité à un contrat de trafic d&#39;un flux de paquets d&#39;un réseau de transport de paquets à longueur variable
WO2004095783A2 (fr) Procede et dispositif de controle d’un trafic de paquets de donnees en entrée d’un reseau
FR2846501A1 (fr) Procede et appareil de programmation de la bande passante de liaison disponible entre les flux de donnees commutes par paquets
EP3053303B1 (fr) Procede d&#39;abonnement a des flux en provenance de clients multicast
FR2913156A1 (fr) Procede d&#39;allocation de ressources de transmission d&#39;un contenu de donnees, produit programme d&#39;ordinateur, moyen de stockage et dispositif correspondants
EP2248386B1 (fr) Procédé et dispositif de régulation d&#39;émission dans un réseau de télécommunication sans fil
EP1878180B1 (fr) Procede d&#39;ordonnancement de paquets appartenant à des flots et equipement associé
EP0874533B1 (fr) Procédé d&#39;ordonnancement de paquets à pertes équitables
EP1264439A1 (fr) Surveillance et simulation perfectionnees de systemes complexes, notamment de mecanismes et de controles de flux et de congestions dans des reseaux de communications
EP2119135B1 (fr) Procede de transfert de paquets de donnees a une ressource partagee, dispositif et programme d&#39;ordinateur associes
EP3146681B1 (fr) Procédé de distribution pour une liaison à liens multiples et hétérogènes
EP3539259B1 (fr) Procédé et dispositif d&#39;actualisation d&#39;un modèle prédictif d&#39;une variable relative à un terminal mobile
EP1890437A1 (fr) Procédé de limitation de débit dans un réseau de télecommunications
WO2014135794A1 (fr) Procede de controle de congestion pour reseaux de telecommunications
EP1460812A1 (fr) Transmission de paquets en fonction de leur temps total de traitement
WO2007125259A1 (fr) Procede de transmission d&#39;une pluralite de champs identificateurs dans un reseau a commutation de paquets
FR2856217A1 (fr) Procede pour analyser le fonctionnement d&#39;une interface de reseau de transmission de donnees par parquets
WO2011077047A1 (fr) Procede et dispositif de regulation d&#39;emission dans un reseau de telecommunication sans fil
WO2007148027A2 (fr) Système et procédé de gestion d&#39;accès a un réseau a accès multiple a répartition dans le temps
EP1033014A1 (fr) Procede de dispersion et de remise en ordre de cellules
FR2788183A1 (fr) Procede de resequencement de blocs de donnees, dans un systeme de commutation asynchrone, blocs de donnees, element de commutation et module terminal correspondants
FR2957743A1 (fr) Procede de gestion d&#39;une transmission de donnees par un dispositif emetteur, avec gestion de codage source, produit programme d&#39;ordinateur, moyen de stockage et dispositif emetteur correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006755432

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

NENP Non-entry into the national phase

Ref country code: RU

WWW Wipo information: withdrawn in national office

Country of ref document: RU

WWE Wipo information: entry into national phase

Ref document number: 11919752

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2006755432

Country of ref document: EP