Title of Invention

METHOD AND DEVICE FOR CONTROLLING A QUEUE BUFFER

Abstract A method and device of controlling a queue buffer, in which a congestion notification procedure is conducted if a queue length parameter exceeds a threshold value, said threshold value being adapted automatically by a procedure that takes into account a flow control parameter.
Full Text FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
The Patents Rules, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
METHOD AND DEVICE FOR CONTROLLING
A QUEUE BUFFER"
TELEFONAKTIEBOLAGET LM ERICSSON (publ), a Swedish Company, of S-164 83 Stockholm, SWEDEN.
The following specification particularly describes the invention and the manner in which it is to be performed.

WO 2005/W4861 PCT/EP2003/D14788

[Title]
Method and device for controlling a queue buffer
5 [Field of the invention]
The present invention relates to a method and device for controlling a queue buffer, where said queue buffer is connected to a link and queues data unit of a flow in a 10 queue.
[Background of the invention]
In data unit based communication, i.e. in which an 15 information to be transmitted is divided into a plurality of units, and the individual units are sent over a communication network, it is known to provide queue buffers at links along the network, such that data units transported over such a link may be buffered. The buffer may be a sending or output 20 buffer (i.e. a buffer for data units that are to be sent over the outgoing link) or a receiving or input buffer (i.e. a buffer for data units that have been sent over the incoming link).
25 Such units for transporting data may carry a variety of names, such as protocol data units, frames, packets, segments, cells, etc., depending on the specific context, the specific protocol used and certain other conventions. In the context of the present document, all such units of data shall
30 generically be referred to as data units.
The procedures for placing data units into a queue, advancing them in the queue, and removing data units from the queue are referred to as queue management or queue control. 35
Many concepts of queue management are known, including such concepts in which a queue length parameter (e.g. the absolute

WO 2005/W4861 PCT/EP2003/D14788
-3-
length of queue or an average length) is monitored and compared with a length threshold value, in order to perform a congestion notification procedure if the threshold value is exceeded. Such a congestion notification procedure can
5 consist in dropping a data unit and/or in marking data units (e.g. setting a congestion notification flag in data units) . Various examples for such management concepts, like drop-on-full or random early detection (RED) are described in the introduction of EP-A-1 249 972. As a consequence, a
1O repetition is not necessary here.
EP-A-1 249 972 proposes a scheme in which the length threshold value that is to be compared with the queue length parameter is automatically updated on the basis of one or
15 more characteristics - of the link over which the queued data units are to be sent. By adapting the automatic threshold to one or more link characteristics, a very flexible form of active queue management is obtained that may provide improved throughput and reduced delay, especially over links that have
20 time varying characteristics such as wireless links.
[Object of the invent ion]
It is the object of the present invention to provide an 25 improved method and device of queue buffer management.
[Summary of the invention]
This object is achieved by a method and device as described 30 in the independent claims of the present application.
Advantageous embodiments are described in the dependent claims.
In accordance with the present invention, in a system where 35 queue buffer control or management comprises determining a value of a length parameter related to the queue length, comparing this value with a threshold and performing a

WO 2005/W4861 PCT/EP2003/D14788
congestion notification procedure if the threshold is exceeded, and in which an automatic threshold adaptation procedure is provided that comprises a procedure for adjusting the length threshold value on the basis of one or
5 more flow control parameters.
By taking into account one or more flow control parameters associated with a queued data unit flow, the queue buffer management becomes more flexible and is better able to act in
10 such a way that the impact of buffer management actions or decisions on the flow control does not produce undesired effects, and/or better able to react to the flow control in a more direct and intelligent way than in prior art systems.
15 The one or more flow control parameters can be determined in any suitable or desirable way. As an example, they can be predetermined values stored in the buffer controller. Preferably, they are in this case associated with known flow control procedures for data unit receivers. In other words,
20 if it is known that certain flow control procedures (e.g. as given by widely used computer programs that comprise flow control routines) use predetermined flow control parameters, then these known flow control parameters can be employed as a basis for adjusting the length threshold value.
25
As an alternative or in addition to deriving at least some the one or more flow control parameters on the basis of predetermined values, a procedure may be provided for determining at least some of said one or more flow contro
30 parameters from a flow control parameter introduced by o? a sender and a receiver of said flow queued in said quev
The buffer management can be tuned in any way that is
35 desirable with *respect to the given network context, control principle and the desired effects (or the nee effect that it is desired to avoid) . According to a

WO 2005/064861 PCT/EP2003/014788
5
embodiment, the adaptation of the queue buffer management to a determined flow control parameter is used to avoid a link under-utilization. Link under-utilization means that there are periods in which the link is idle (i.e. not transporting
5 data units) . More specifically, in this preferred embodiment it is checked whether a desired length threshold value could lead to congestion notification operations that in turn could potentially provoke link under-utilization due to the reaction of the sender that sends data units, and the length
10 threshold value is adapted differently in order to avoid this link under-utilization. As a result, network resources are used more efficiently.

15
[Brief description of drawings]
become apparent from the following detailed description of preferred embodiments, where reference will be made to the accompanying figures in which:
20
Pig. 1 shows a schematic block diagram representation of a buffer and buffer controller according to an embodiment of the invention,
25 Fig. 2 shows a flow chart of a method embodiment of the present invention,
Fig. 3 shows a schematic block diagram representation of a
buffer and buffer controller according to another
30 embodiment of the invention, and
Fig. 4 shows a flow chart of another method embodiment of the present invention.
35 [Detailed description of the embodiments]


WO 2005/W4861 PCT/EP2003/D14788
Although the following preferred embodiments of the present invention will often refer to systems using window-based flow control, and more specifically to systems transporting IP (Internet Protocol) data units, the present invention is
5 neither restricted to window-based flow control nor to IP based systems. The present invention can be applied to the queuing of any type of data unit, regardless of the specific protocol, and can be applied to any type of flow control, e.g. also to rate-based flow control, as long as it is
10 possible for the buffer management procedure to determine a flow control parameter.
Furthermore, the method of the present invention may be applied to any known queue management scheme in which a queue
15 length related parameter is compared to at least one length threshold value, and where a congestion notification procedure is conducted if the threshold is exceeded. Hamely, the method is e.g. applicable to any known RED scheme, to schemes that drop data units when a queue is full, such as
20 tail-drop, random-drop or front-drop, and to any known scheme that perform explicit congestion notification instead of or in addition to dropping.
It is preferable to apply the method and device of the 25 present invention in connection with the active queue
management disclosed in EP-A-1 249 972. The entire disclosure of this document and its US counter-part application, are herewith incorporated by reference.
30 Fig. 1 shows a schematic representation of a queue buffer controller 10 that is capable of implementing the present invention for controlling the management of data units in a queue buffer 20. Reference numeral 3 represents a communication network over which data units 30 arrive at the
35 queue buffer 20, in order to be placed in a queue 21 before being sent over link 40.

WO 2005/W4861 PCT/EP2003/D14788
length or an average queue length, and the congestion notification procedure can equally be chosen as is suitable or desirable, e.g. be a data unit dropping procedure and/or an explicit data unit marking procedure.
5
In accordance with this embodiment of the present invention; a flow control parameter determinator 105 is provided for determining a flow control parameter introduced by one of a sender and a receiver of a flow queued in queue 21.
10 Furthermore, the threshold adaptor 104 is arranged in such a way that the length threshold value is adjusted on the basis of the determined flow control parameter «.
It is noted that the above-described elements 101-105 can be
15 provided as hardware, software or any suitable combination of hardware and software. Preferably, the controller 10 is a programmable data processor, and the elements 101 to 105 are software elements, e.g. program code parts.
20 Pig. 2 shows a flow chart of a method embodiment of the method of the present invention, which method can be performed with the controller 10 shown in Fig. 1. In first step SI, a value of a length parameter related to the length of the queue 21 is determined. This queue length related
25 parameter can be related to the queue length in any desirable or suitable way, e.g. can be the actual or momentary queue length QL or a parameter derived from the actual or momentary queue length, such as an average value QLav-
30 In the example of Fig. 2, the queue length related parameter is the actual queue length QL. If it is desirable to use an average queue length Qlav this average value can be determined in accordance with any known suitable averaging algorithm, and such an algorithm may typically consist in
5 updating an old average value by calculating the sum of the old average multiplied by a first weight factor and the

WO 2005/W4861 PCT/EP2003/D14788
The data units 30 queued in queue 21 will belong to one or more flows. A flow is generically identified by a source and destination host address, the source and destination Service Access Point (SAP identifier and a protocol identifier- The
5 definition and concept of a flow is well known in the art, e.g. from TCP/IP, in which case the SAP identifiers are referred to as port numbers, and the source and destination host addresses are called IP addresses, such that a further explanation is not necessary here.
10
Queue 21 can be arranged in such a way that all of the data units in said queue 21 are from the same flow, or they may be from a plurality of flows. It is possible that buffer 20 is managed in such a way that there are a plurality of queues,
15 each queue being associated with a corresponding flow.
Now specific elements will be described for embodying tine concept of the present invention in queue buffer controller 10. It is noted that a queue buffer controller will generally
20 comprise more than these elements, namely known elements for processing received data units and managing the buffer, which are not explicitly described for the sake of simplicity. Also, the controller 10 may have elements for specifically embodying a system as described in EP-A-1 249 972.
25
Reference numeral 101 describes a queue length determinator for determining a value of a length parameter related to the length of queue 21. Furthermore, a comparator 102 is provided for comparing the determined length value with a length
30 threshold value provided by a threshold adaptor 104, which is arranged to automatically adapt the length threshold
35 values. The comparator 102 is connected to a congestion notifier 103 that performs a congestion notification procedure if the determined length value is greater than the length threshold 5 value. As shall be explained in more detail further on, the length parameter to be determined can be chosen in any suitable or desirable way, e.g. be the absolute length queue

WO 2005/W4861 PCT/EP2003/D14788
momentary queue length multiplied by a second weight factor. For example, QLav can be calculated as
QLav (new) = QLav (old) - (1-1/2n) + (QL • l/2n)
5
where QL represents the momentary queue length value and n is an exponential weight factor adjustable between 0 and 1.
Returning to Fig. 2, the queue length parameter QL is
10 compared with a length threshold value Lth. If the length threshold value L^-jj is exceeded, then a congestion notification procedure S3 is performed, otherwise the congestion notification procedure S3 is skipped.
15 As already mentioned above, the congestion notification
procedure can be chosen in any suitable or desirable way. For example, it can consist in dropping/marking one or more predetermined or one or more randomly selected data units from the queue 21, or in dropping/marking one or more newly
20 arrived data units before placing them into queue 21, or
performing such a dropping/marking operation in dependence on a predetermined probability function. The marking can e.g. be achieved by setting an explicit congestion notification flag in one or more of the queued data units.
25
After step S2 or S3, the procedure goes to step S4, in which it is determined whether an adaptation triggering event for adapting the length threshold parameter Lth has occurred. It is noted that step S4 is optional. If step S4 decides that an
30 adaptation triggering event has occurred, then the procedure goes to step S5, in which a flow control parameter introduced by one of a sender and a receiver of a flow queued in queue 21 is determined. Then the procedure goes to step S6, where an adaptation procedure for Lth 1S conducted, which adjusts
35 the length threshold value Lth on the basis of the flow control parameter determined in step S5.

WO 2005/W4861 PCT/EP2003/D14788


It may be noted that the specific arrangement of steps shown in Fig. 2 is only an example. Especially, steps SI, S2 arid S3, which form a procedure for deciding on the performance of a congestion notification procedure, are independent of the
5 adaptation procedure constituted by steps S4, S4 and S6. Consequently, steps SI, S2 and S3 may be arranged independently of S4, S5 and S6, such that steps S4-S6 can be performed prior to steps SI-S3 or in parallel thereto. Especially, it may be noted that steps SI-S3 on the one hand
1O and steps S4-S6 on the other hand will generally be contained in a larger method of controlling or managing the queue buffer, which larger method has more steps and procedures, but where these additional steps and procedures are not shown, as they do not pertain to the present invention. The
15 method of Pig. 2 nay be implemented as software, and the
steps Si-S3 can e.g. be implemented in one thread, while S4-S6 may be implemented in another, independent thread. However, the method can also directly be implemented in the form of hardware.
20
It is noted that the adaptation procedure for 1^^ of step S6 will generally not only take the determined flow control parameter into account, but also other parameters relevant to queue management, such as the link related characteristics
25 suggested by EP-A-1 249 972.
Furthermore, it is noted that the adaptation triggering event in step S4 that leads to the initiation of an automatic threshold adaptation procedure S6 may be chosen as is
30 suitable of desirable. For example, it is possible to
initiate the automatic threshold adaptation procedure at regular intervals, such that the adaptation triggering event in step S4 can be a certain time condition becoming true, or the event that a counter reaches a predetermined value. The
35 adaptation triggering event can also consist in a change in one or more parameters that play a role in the adaptation procedure S6, e.g. the measured flow control parameter or one

WO 2005/W4861 PCT/EP2003/D14788
or more link characteristic parameters. It may be noted that in practice a change will only be- determined with a certain granularity. In other words, not any ever so small change in a parameter will be considered a triggering event, but much
5 rather only when a change the predetermined magnitude has occurred.
The procedure of determining a flow control parameter may determine one or more flow control parameters involved in the
10 flow control of the flow in question. Preferably, one flow
control parameter is monitored and the flow control parameter is preferably introduced by the receiver of the flow. This can e.g. be done by inserting the flow control parameter into acknowledgment data units sent from the receiver to the
15 sender for acknowledging the correct receipt of data units.
Schemes of this nature are well known in the art, such as ARQ (Automatic Retransmission request) , such that a further explanation is not necessary here.
20 Por example, if the flow control is window-based, then the
flow control parameter may be a control window introduced by the receiver, said control window expressing a limitation of how many data units the receiver can handle. For example, the measured flow control parameter can be the receive window or
25 advertised window rwnd known from TCP. However, the measured flow control parameter can also be introduced by the sender and express a limitation of how many data units the sender can send.
30 On the other hand, in a rate-based flow control system, the measured flow control parameter can be a control rate introduced by the receiver, e.g. which expresses a data rate limitation for arriving data units that the receiver can handle, which can also be referred to as rlfr (Receiver
35 Limitation Flow Rate) . On the other hand, one of the flow
control parameters could also be a data rate announced by the sender of the flow. 13, e.g. expressing a data rate







WO 2005/W4861 PCT/EP2003/D14788
limitation for the rate of data units that the sender can send, a current sending rate of said sender or a target sending rate for said sender. A target sending rate can e.g. be announced by an application that is sending video
5 information and intends to send at a certain quality.
The controller 10 and buffer 20 shown in Fig. 1 will generally be provided within a network node of communication network 3. Such a communication node can e.g. be a server
10 and/or a router in network 3.
If a flow control parameter is extracted from the above mentioned acknowledgement data units, then this can be done at the network node in which the controller 10 and buffer 20
15 are provided, or it can be done at a different network node, in which latter case the extracted flow control parameter is sent from said other network node to the network node In which the controller 10 and buffer 20 are provided.
20 Pig:. 1 shows an example of the former case, where it is additionally assumed that the buffer 20 also holds the
acknowledgment data units, such that the flow control parameter determinator 105 can extract the desired flow control parameter from the buffered acknowledgment data
25 units.
It is generally preferred that the extraction of the flow control parameter occur in the node in which the buffer and buffer controller are provided. However, it is possible that
30 the network is arranged in such a way that this is very
difficult or impossible, e.g. due to the data units being handled by the buffer having higher layer data units embedded within themselves, and an additional encryption having been performed in the embedded higher layer data units, such that
35 any control parameter contained within said higher layer data units can not be extracted. It is noted that the term "embedding" means encapsulation and/or segmentation.

WO 2005/W4861 PCT/EP2003/D14788
In such a case, where the extraction is not feasible at the network node at which the controller and buffer are provided, a procedure should be implemented such that a different
5 network node, at which the embedded higher layer data units are decipherable, performs the extraction of the desired flow control parameter, and sends the extracted flow control parameter to the network node in question. The sending can be performed by a dedicated connection, or by providing a
10 dedicated location within data units sent from the other network node to the network node in question.
In the latter case, the flow control parameter determinator 105 is itself connected to network 3, in order to receive the
15 extracted flow control parameter (not shown in Pig. 1).
Now, further embodiments will be described with reference to Figures 3 and 4. It is noted that the sane reference numerals as contained in Figures 1 and 2 relate to corresponding
20 elements in Figures 3 and 4, such that a repeated description is not necessary.
The arrangement shown in Fig. 3 is almost the same as that shown in Fig. 1, except that the flow control parameter
25 determinator 105 has been replaced by a storage device 106 for storing one or more predetermined values that are based upon flow control parameters used by known flow control procedures. Fig. 4 shows a flow chart that is identical to that of Fig. 2, except that step S5 has been omitted, and the
30 adaptation procedure for La. in S6 is arranged to take the
one or more values stored in storage device 106 into account when adapting Lth.
Parameters used in flow control procedures can e.g. be 35 known from the fact that certain computer programs that
contain flow control routines consistently use one or more specific flow control parameters. It is then not necessary

WO 2005/W4861 PCT/EP2003/D14788
to obtain such parameters from data units or acknowledgement messages. As an example, the well known operating system Windows 2000 of Microsoft Corporation specifies specific values for the calculation of the TCP
5 receive window, i.e. the window that a TCP receiver
advertises to the TCP sender. These values are based on 16 KB or 64 KB. The exact value used in an initial condition is 16384 bytes, and for Ethernet the window is normally set to 17520 bytes (16 KB rounded up to twelve 14 60-byte
10 segments, see Microsoft Windows 2000 TCP/IP Implementation Details, White Paper, by Dave MacDonald and Warren Barkley, 2000, pages 31 and 32. As a consequence, the values 16 KB and 64 KB (and possibly 16384 bytes and/or 17520 bytes) can be stored as predetermined flow control
15 values.
It is noted that the embodiments shown in Figures 1 and 3 can be combined, i.e. in the form of an embodiment that makes use of both predetermined stored flow control parameters as well as flow control parameters introduced
20 by the sender and/or receiver and obtained from data units or acknowledgment messages.
As already mentioned above, the automatic threshold adaptation procedure can be arranged in any suitable or
25 desirable way. Preferably, it is arranged in such a way that it comprises estimating a link capacity value LC, analysing whether the performance of a congestion notification procedure will lead to an under-utilization of this estimated link capacity due to a reaction of the sender to the
30 congestion notification, under the condition that the length threshold value is set equal to the estimated link capacity value, and adapting the length threshold value on the basis of a result of the analysing step, by setting the link threshold value equal to the estimated link capacity value if
35 the analysing step indicates no under-utilization, and

WO 2005/W4861 PCT/EP2003/D14788
-insetting the length threshold value larger than the estimated link capacity value otherwise.
The link capacity value can be understood as the minimal
5 amount of data that the sender of the flow under
consideration must send out, such that the bandwidth that link 40 allocates to said flow is fully used. Full utilization means that the proportion of link bandwidth allocated to the given flow is always in full use. Expressed .
10 somewhat differently, if one considers the simplified example of link 40 only serving a single flow, then this means that the sender of that flow sends so much data that link 40 is constantly busy, i.e. constantly sending data units, without any idle time in between. Again in other words, the link
15 capacity is the amount of data that the sender brings into flight, such that any additional data brought into flight will not increase throughput, as the additional data is queued.
20 The link capacity can also be understood as the product of the data rate provided by the link 40 to the flow in question, multiplied by the round trip time (RTT) associated with said flow for the case of an unloaded network. An unloaded network means that there is no queuing delay. As a
25 onsequence, the value of the unloaded RTT is equal to the difference between the actual RTT of the flow and all queuing delays for said flow.
The estimation of the link capacity value will therefore
30 generally consist in determining a time value indicative of the unloaded RTT, and multiplying this value with the data rate DR provided by link 40 for the flow in question. The determination of this unloaded RTT can be done in any suitable or desirable way. One example is to calculate the
35 sum of a constant RTTWC and the provided by link 40.
RTTwc is a worst-case estimation of the overall unloaded RTT excluding the RTT of the link 40 in question, and may have a

W0 2M5/M4861 PO7EP2003/0147WI
value of 150 to 300 ms, more preferably 150 to 250 ras. An alternative possibility of estimating the unloaded RTT >£c>r the given flow consists in calculating the queuing delay at buffer 20, e.g. by keeping an average of the amount of time
5 that a buffered data unit 30 spends in queue 21, and
calculating the difference between the actual RTT of the flow and this queuing delay. The value of the actual RTT for the flow can e.g. be inserted into the data units of said flow by the sender and read by controller 10.
10
It is noted that the estimate LC of the link capacity will generally not be identical to the actual momentary link capacity. The process of estimating the link capacity is preferably such that the estimated value exceeds the real
15 link capacity, i.e. the estimate is conservative. This can be achieved in any suitable or desirable way, e.g. by using the above' mentioned worst case estimates for the unloaded KIT, and/or by adding predetermined positive factors to one or more of the parameters used in estimating the link capacity.
20 In other words, one can add a predetermined factor to the
unloaded RTT and/or to the RTT of the link and/or to DR, and one can add a predetermined positive factor to the calculation result, i.e. replacing the calculated value of LC by LC + 8: LC 25
The step of analysing whether the performance of a congestion notification procedure will lead to under-utilization of the estimated link capacity will depend on the specific type of flow control used for the flow under consideration. Specific
30 examples will be given further on. In any case, if, under the condition that the length threshold value is considered to be set equal to the estimated link capacity value, no under-utilization is expected due to the flow control reaction of the sender to the congestion notification, then the actual
35 length threshold value can be set to this estimated link
capacity. On the other hand, if the analysis indicates under-utilization, i.e. a situation where one or more idle periods

WO 2M5A*t861 , _, PCTIEF2003/014788
of the bandwidth allocated to the particular flow can be expected, then the length threshold value Lth is set larger than the estimated link capacity value. In doing so, the tendency to perform a congestion notification procedure is
5 reduced, as the probability of exceeding the length threshold value Lth is decreased. As a consequence, the probability of a link under-utilization is also decreased. Therefore, the link resources are less likely to be wasted due to under-utilization.
10
Preferably, the length threshold value Lth is set to a value derived on the basis of the flow control parameter, if the analysing step indicates under-utilization.
15 This shall be explained in the context of an example, where the flow control between sender and receiver is window-based. More specifically, the sender is arranged to send data units in a predetermined sequence and the receiver is arranged to send acknowledgment messages for acknowledging the correct
20 receipt of the data units. Bach acknowledgment message identifies the last data unit correctly received in the sequence, and the receiver sends to the sender a window value that expresses a limitation of how many data units the receiver can handle. The sender of the flow performs window-
25 based flow control using a send window that is selected as the minimum of the window advertised by the receiver and a second window value, such that the sender must not send data units with a sequence number higher than the sum of the highest acknowledged sequence number and the send window. As
30 a reaction to a congestion notification, the sender divides
the second window value by k, k > 1, and thereafter increases the second window by a predetermined increment for each duplicate acknowledgment message it receives. A duplicate acknowledgment message is an acknowledgment data unit that
35 identifies the correct receipt of a sequence number that has already been acknowledged in a previous acknowledgment data unit.

WO 2005/W4861 PCT/EP2003/D14788

An example of a system working this way is 5 process of reacting to a congestion notification is known as fast recovery. For TCP, k=2. However, it is noted that the present embodiment is not restricted to TCP, and can be applied to any system that operates as generically described above.
LO
In accordance with this embodiment, the flow control parameter used for buffer management is the first window value contained in the acknowledgment data units, i.e. the window value that expresses a limitation of how many data
15 units the receiver can handle. Furthermore, the length threshold value Lth. is initially (i.e. when starting to manage the data units of the flow in question) set to the above described estimated link capacity value LC. Then, the automatic threshold adaptation procedure S6 is performed in
20 such a way that the length threshold value I^-fr is set equal to the estimated link capacity value LC if the first window value (e.g. rwnd) is greater than (Ltto+2xLC), which is initially equal to three times the estimated link capacity value LC.
25
The reason for this will be explained in the following. In a flow control system that operates as described above, if the queue length threshold Lth is set to the estimated link capacity value LC, then the send window size at the time of a
30 congestion notification procedure will be Lth + LC = 2 x LC.
This is due to the fact that if the send window size is equal to the link capacity, then the queue length will be zero. Furthermore, in order to utilize the link during the phase of congestion notification response (i.e. when the second window
35 value is divided by two and is incremented by a predetermined increment for each duplicate acknowledgment message thereafter) , this second window needs to be able to inflate

WO 2005/W4861 PCT/EP2003/D14788
-18—
to 1.5 tiroes the send window size at the time of the congestion notification procedure. As a consequence, if the send window is unable to inflate beyond 2 x 1.5 x I»C, the congestion notification will lead to a link under-
5 utilization. Therefore, the step of comparing the window advertised by the receiver with 3 x LC is an example of a step for analysing whether a link under-utilization will occur in response to a congestion notification.
10 When generalizing the above considerations, it may be taken into account that La. could change and no longer be equal to LC, such that the condition is to compare the advertised window with (I** + LC) x 1.5.
15 Using TCP as an example, this embodiment can also be
expressed in pseudo-coder
If (rwnd > 1.5 x (LC+ 1^) {
Lth = LC;
} else {
20 Lth = X;
}
It is noted that in the above example the length threshold Lth is set equal to the estimated link capacity LC if rwnd is
25 greater than 1.5 x (LC+ Lth) . However, it is also possible to set Lth =I»C if rwnd =1.5 x (LC+ Lth) .
The value of X can be chosen in any suitable of desirable way, as long as it is larger than LC. For example, it can be
30 chosen as a function of the first window value (rwnd in the example) . Preferably, it is set equal to the first window value minus a predetermined reduction value, where said predetermined reduction value may be zero or may be itself a function of the maximum segment size of the data units of the
35 flow. For example, the predetermined reduction value can be two times the maximum segment size.

WO 2M5/fttl8f 1 PCT/EF2003/014788
The benefit of setting the length threshold value in dependence on the window value advertised by the receiver of the flow is that the length threshold value will not be reached if the flow is limited by the receiver. If the length
5 threshold value is not reached, no congestion notification procedure is conducted, and consequently no link under-utilization is unnecessarily provoked. As a consequence, a better utilization of link resources is achieved while at the same time not negatively affecting the flow control perform
10 at the sender and receiver.
Now a further TCP example will be described that is based upon an arrangement and method as explained in connection with Figures 3 and 4. It is assumed that two known receiver
15 window values are stored, referred to as LIM1 and LIM2. LIM1 is larger than I*IM2. For example, LIM1=64KB and LIM2=16KB, see above example described in connection with the operating system Windows 2000. Naturally, LIMl can also be a value chosen on the basis of 64KB, e.g. any value in a given range
20 around 64 KB, and equally KEM2 can also be a value chosen on the basis of 16KB, e.g. any value in a given range around 16 KB. Expressed in pseudo-code:
If 1.5 x(LC+ Lth) > LIM1 { 25 Lth = X1;
} else if 1.5 x (LC+ Lth) > LIM2 {
Lth = X2; } else {
Lth = LC
30 }
XI is larger than X2, and both are larger than LC. Preferably, XI is a function of LIM1 and/or X2 is a function of LIM2. For example, the function can be the value of LIM1
35 or LIM2 minus a predetermined reduction value, where said
predetermined reduction value may be zero or may be itself a function of the maximum segment size of the data units of the

WO 2005/W4861 PCT/EP2003/D14788


flow. For example, the predetermined reduction value can be two times the maximum segment size.
Although the present invention has been described by way of
5 specific examples, these are not intended to be limiting, as the scope of the invention is defined by the appended claims. Reference signs in the claims only serve to make the claims easier to read and are also not intended to have any limiting effect.

05-12-2005 EP0314788
WO 2005/W4861 PCT/EP2003/D14788
Claims
5 1. A method of controlling a queue buffer (20), said queue buffer (20) being connected to a link (40) and being arranged to queue data units (30) of a flow in a queue (21), comprising
10 determining (Si) a value of a length parameter (QL; QLav) related to the length of said queue,
comparing (S2) said value (QL; QLav) with a length threshold value (Lth) and performing (S3) a congestion 15 notification procedure if said value (QL; QLav) is greater than said length threshold value (Lth) , and
an automatic threshold adaptation procedure (S6),
20 characterized in that
said automatic threshold adaptation procedure (S6) comprises a procedure for adjusting said length threshold value (Lth) on the basis of one or more flow 25 control parameters (LIM1, LIM2; rwnd; rlfr).
2. The method of claim 1, wherein said one or more flow control parameters (LIM1, LIM2) are predetermined values.
30
The method of claim 2, wherein said predetermined values are associated with known flow control procedures for one or both of data unit senders and data unit receivers.
35

05-12-2005

EP0314788

4. The method of one of claims 1 to 3, furthermore
comprising a procedure (S5) for determining one or more
of said one or more flow control parameters (LIM1, LIM2,-
rwnd; rlfr) from a flow control parameter (rwnd; rlfr)
5 introduced by one of a sender and a receiver of said flow queued in said queue (21).
5. The method of claim 4, wherein said flow control
parameter is introduced by said receiver and inserted
10 into acknowledgment data units sent from said receiver to said sender for acknowledging the correct receipt of data units.
6. The method of claim 5, and said buffer being provided in
15 a network node of a communication network connecting
said sender and said receiver, wherein said procedure for determining said flow control parameter comprises extracting said flow control parameter from said acknowledgement data units at said network node. 20
7. The method of claim 5 or 6, and said buffer being
provided in a first network node of a communication
network connecting said sender and said receiver,
wherein said procedure for determining said flow control
25 parameter comprises extracting said flow control
parameter from said acknowledgement data units at a second network node different from said first network node and sending said flow control parameter from said second network node to said first network node.
30
8. The method of one of claims 1 to 7, and a flow control
performed for said flow in said queue (21) being window-based, wherein one of said one or more flow control parameters is a control window.
35

05-12-2005 EP0314788
9. The method of claim 8, wherein said control window is introduced by said receiver and expresses a limitation of how many data units the receiver can handle.
5 10. The method of claim 8, wherein said control window is
introduced by said sender and expresses a limitation of how many data units the sender can send.
11. The method of one of claims 1 to 7, and a flow control
10 performed for said flow in said queue (21) being rate-
based, wherein one of said one or more flow control
parameters is a control rate.
12. The method of claim 11, wherein said control rate is
15 introduced by said receiver and expresses a data rate
limitation for arriving data units that the receiver can handle.
13. The method of claim 11, wherein said control rate is
20 introduced by said sender and expresses one of a data
rate limitation for the rate of data units that the sender can send, a current sending rate and a target sending rate.
25 14. The method of one of claims 1 to 13, wherein said automatic threshold adaptation procedure comprises
estimating a link capacity value (LC)
30 analyzing whether the performance of a congestion
notification procedure will lead to an underutilization of said link due to a reaction of said sender to the congestion notification under the condition that said length threshold value (Lth) is set equal to said
35 estimated link capacity value (LC), and

15"
adapting said length threshold value (Lth) on the basis of a result of said analyzing step by setting said length threshold value (Lth) equal to said estimated link capacity value (LC) if said analyzing step
5 indicates no underutilization, and setting said length threshold value (Lth) larger than said estimated link capacity value (LC) otherwise.
15 The method of claim 14, wherein said length threshold
10 alue (Lth) is set to a value derived on the basis of one of said flow control parameters (LIM1, LIM2; rwnd; rlfr) if said analyzing step indicates underutilization.
16 The method of claim 14 or 15, and a sender of said flow
15 in said queue (21) sending said data units in a predetermined sequence, a receiver of said flow in said queue (21) sending to said sender acknowledgment messages for acknowledging the correct receipt of said data units, where each acknowledgment message identifies
20 the last data unit correctly received in said sequence, and said receiver sending to said sender a first window value expressing a limitation of how many data units the receiver can handle, a flow control performed by said sender being window-based using a send window, said send
25 indow being selected as the minimum of said first window value and a second window value, such that said sender must not send data units with a sequence number higher than the sum of the highest acknowledged sequence number and the send window, and
30 said sender dividing said second window value by two as a reaction to a congestion notification, and thereafter increasing the second window by a predetermined increment for each duplicate acknowledgment message it receives,
wherein

05-12-2005 EP0314788

21. A queue buffer controller (10) for controlling a queue
buffer (20) that is connected to a link (40) and is
arranged to queue data units (30) of a flow in a queue
(21), comprising
5
a queue length determinator (101) for determining a value of a length parameter (QL; QLav) related to the length of said queue,
10 a comparator (102) for comparing said value with a length threshold value,
a congestion notifier (103) for performing a congestion notification procedure if said value is greater than
15 said length threshold value, and
a threshold adaptor (104) for automatically adapting said length threshold value,
20 characterized in that
said threshold adaptor (104) being arranged for adjusting said length threshold value on the basis of one or more flow control parameters (LIM1, LIM2; rwnd; 25 rlfr).
22. The queue buffer controller (10) of claim 21, wherein
said one or more flow control parameters (LIM1, LIM2)
are predetermined values.
30
23. The queue buffer controller (10) of claim 22, wherein
said predetermined values are stored in said queue
buffer controller (10) and associated with known flow
control procedures for data unit receivers.
35
24. The queue buffer controller (10) of one of claims 21 to
23, further comprising a flow control parameter

05-12-2005 EP0314788
2-^
determinator (105) for determining one or more of said one or more flow control parameters (LIM1, LIM2; rwnd rlfr) from a flow control parameter (rwnd; rlfr) introduced by one of a sender and a receiver of said 5 flow queued in said queue (21).
25. The queue buffer controller (10) of claim 24, wherein
said flow control parameter is introduced by said
receiver and inserted into acknowledgment data units
10 sent from said receiver to said sender for acknowledging the correct receipt of data units, and said queue buffer (20) being provided in a network node of a communication network (3) connecting said sender and said receiver, wherein said flow control parameter determinator (105)
15 is arranged for extracting said flow control parameter from said acknowledgement data units at said network node.
26. The queue buffer controller (10) of claim 24, wherein
20 said flow control parameter is introduced by said
receiver and inserted into acknowledgment data units sent from said receiver to said sender for acknowledging the correct receipt of data units, and wherein said queue buffer (20) is provided in a first network node of 25 a communication network (3) connecting said sender and said receiver, wherein said flow control parameter determinator (105) is arranged for receiving said flow control parameter from a second network node at which said flow control parameter was extracted.

30
35

27. The queue buffer controller (10) of one of claims 21 to 26, wherein said threshold adaptor (104) comprises
an estimator for estimating a link capacity value (LC),
an analyzer for analyzing whether the performance of a congestion notification procedure will lead to an

under utilization of said link due to a reaction of said sender to the congestion notification under the condition that said length threshold value is set equal to said estimated link capacity value (LC), and
5
an adaptor for adapting said length threshold value on the basis of a result of said analyzing step by setting said length threshold value equal to said estimated link capacity value (LC) if said analyzing step indicates no
10 underutilization, and setting said length threshold value larger than said estimated link capacity value (LC) otherwise.
28 The queue buffer controller (10) of claim 27, wherein s
15 said threshold adaptor (104) is arranged to set said length threshold value to a value derived on the basis of one of said flow control parameters (LIMl, LIM2; rwnd; rlfr) if said analyzer indicates underutilization.
20 29. The queue buffer controller (10) of claim 27 or 28, a sender of said flow in said queue sending said data units in a predetermined sequence, a receiver of said flow in said queue sending to said sender acknowledgment messages for acknowledging the correct receipt of said
25 data units, where each acknowledgment message identifies the last data unit correctly received in said sequence, and said receiver sending to said sender a first window value expressing a limitation of how many data units the receiver can handle, a flow control performed by said
30 sender being window-based using a send window, said send window being selected as the minimum of said first window value and a second window value, such that said sender must not send data units with a sequence number higher than the sum of the highest acknowledged sequence
35 number and the send window, and said sender dividing said second window value by two as a reaction to a congestion notification, and thereafter increasing the

second window by a predetermined increment for each duplicate acknowledgment message it receives,
wherein
5
one of said one or more flow control parameters (LIM1, LIM2; rwnd; rlfr) is said first window value and said threshold adaptor (104) is arranged to initially set said length threshold value equal to said estimated link
10 capacity value, and to set said length threshold value equal to said estimated link capacity value if said first window value is greater than 1.5 times the sum of said estimated link capacity value (LC) and the momentary value of said length threshold value (Lth).
15
30 The queue buffer controller (10) of claim 29, wherein said threshold adaptor (104) is arranged for setting said length threshold value equal to said estimated link capacity value if said
20 first window value is greater or equal to 1.5 times the sum of said estimated link capacity value (LC) and the momentary value of said length threshold value (Lth).
The queue buffer controller (10) of claim 29 or 30,
25 wherein said threshold adaptor (104) is arranged to set said length threshold value equal to a function of said first window value if said first window value does not fulfil the condition for setting said length threshold value equal to said estimated link capacity value.
30
The queue buffer controller (10) of claim 31, wherein said function is the difference between said first window value and a predetermined reduction value.

31
33. A method of controlling a queue buffer, said queue buffer being connected to a link and being arranged to queue data units of a flow in a queue substantially as herein described with reference to the accompanying drawings.
34. A computer program product substantially as herein described with reference to the accompanying drawings.
35. A queue buffer controller for controlling a queue buffer that is connected to a link and is arranged to queue data units of a flow in a queue substantially as herein described with reference to the accompanying drawings.


Dated this 13* day of June, 2006.
OF K&S PARTNERS AGENT FOR THE APPLICANTS

32
ABSTRACT
METHOD AND DEVICE FOR CONTROLLING A QUEUE BUFFER
A method and device of controlling a queue buffer, in which a congestion notification procedure is conducted if a queue length parameter exceeds a threshold value, said threshold value being adapted automatically by a procedure that takes into account a flow control parameter.

Documents:

705-MUMNP-2006-ABSTRACT(14-6-2006).pdf

705-MUMNP-2006-ABSTRACT(28-3-2011).pdf

705-MUMNP-2006-ABSTRACT(29-6-2011).pdf

705-MUMNP-2006-ABSTRACT(AMENDED)-(28-3-2011).pdf

705-MUMNP-2006-ABSTRACT(GRANTED)-(3-8-2011).pdf

705-mumnp-2006-abstract.doc

705-mumnp-2006-abstract.pdf

705-MUMNP-2006-CANCELLED PAGES(29-6-2011).pdf

705-MUMNP-2006-CLAIMS(14-6-2006).pdf

705-MUMNP-2006-CLAIMS(AMENDED)-(28-3-2011).pdf

705-MUMNP-2006-CLAIMS(AMENDED)-(29-6-2011).pdf

705-MUMNP-2006-CLAIMS(GRANTED)-(3-8-2011).pdf

705-MUMNP-2006-CLAIMS(MARKED COPY)-(28-3-2011).pdf

705-mumnp-2006-claims.pdf

705-mumnp-2006-correspondance-received.pdf

705-MUMNP-2006-CORRESPONDENCE(17-10-2006).pdf

705-MUMNP-2006-CORRESPONDENCE(3-8-2010).pdf

705-mumnp-2006-correspondence(3-9-2007).pdf

705-MUMNP-2006-CORRESPONDENCE(IPO)-(3-8-2011).pdf

705-MUMNP-2006-CORRSPONDENCE(13-7-2010).pdf

705-mumnp-2006-description (complete).pdf

705-MUMNP-2006-DESCRIPTION(COMPLETE)-(14-6-2006).pdf

705-MUMNP-2006-DESCRIPTION(GRANTED)-(3-8-2011).pdf

705-MUMNP-2006-DRAWING(14-6-2006).pdf

705-MUMNP-2006-DRAWING(28-3-2011).pdf

705-MUMNP-2006-DRAWING(GRANTED)-(3-8-2011).pdf

705-MUMNP-2006-FORM 1(28-3-2011).pdf

705-MUMNP-2006-FORM 1(29-6-2011).pdf

705-mumnp-2006-form 18(3-9-2007).pdf

705-MUMNP-2006-FORM 2(COMPLETE)-(14-6-2006).pdf

705-MUMNP-2006-FORM 2(GRANTED)-(3-8-2011).pdf

705-MUMNP-2006-FORM 2(TITLE PAGE)-(14-6-2006).pdf

705-MUMNP-2006-FORM 2(TITLE PAGE)-(28-3-2011).pdf

705-MUMNP-2006-FORM 2(TITLE PAGE)-(29-6-2011).pdf

705-MUMNP-2006-FORM 2(TITLE PAGE)-(GRANTED)-(3-8-2011).pdf

705-MUMNP-2006-FORM 26(13-7-2010).pdf

705-MUMNP-2006-FORM 26(17-10-2006).pdf

705-MUMNP-2006-FORM 26(28-3-2011).pdf

705-MUMNP-2006-FORM 26(29-6-2011).pdf

705-MUMNP-2006-FORM 3(28-3-2011).pdf

705-MUMNP-2006-FORM 3(3-8-2010).pdf

705-MUMNP-2006-FORM 5(28-3-2011).pdf

705-mumnp-2006-form-1.pdf

705-mumnp-2006-form-2.doc

705-mumnp-2006-form-2.pdf

705-mumnp-2006-form-3.pdf

705-mumnp-2006-form-5.pdf

705-MUMNP-2006-PETITION UNDER RULE 137(28-3-2011).pdf

705-MUMNP-2006-REPLY TO EXAMINATION REPORT(28-3-2011).pdf

705-MUMNP-2006-REPLY TO HEARING(29-6-2011).pdf

705-MUMNP-2006-SPECIFICATION(AMENDED)-(28-3-2011).pdf

705-MUMNP-2006-US & CHINESE PATENT DOCUMENT(28-3-2011).pdf

705-MUMNP-2006-WO INTERNATIONAL PUBLICATION REPORT(14-6-2006).pdf

705-mumnp-2006-wo international publication report(3-9-2007).pdf

abstract1.jpg


Patent Number 248673
Indian Patent Application Number 705/MUMNP/2006
PG Journal Number 31/2011
Publication Date 05-Aug-2011
Grant Date 03-Aug-2011
Date of Filing 14-Jun-2006
Name of Patentee TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
Applicant Address S-164 83 Stockholm,
Inventors:
# Inventor's Name Inventor's Address
1 SCHLIWA-BERTLING Paul Trumslagaregaten 62,S-58216 Linkoping,
2 EKSTROM,Hannes Hubertusstrasse 59,D-52064 Aachen.Germany
3 LUDWIG,Reiner Bergstrasse 18,D-52393 Huertgenwald,Germany
PCT International Classification Number H04L12/56
PCT International Application Number PCT/EP2003/014788
PCT International Filing date 2003-12-23
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA