WO2023078542A1

WO2023078542A1 - An apparatus and a method for congestion control for multiple heterogeneous flows

Info

Publication number: WO2023078542A1
Application number: PCT/EP2021/080490
Authority: WO
Inventors: Neta ROZEN-SCHIFF; Amit Navon; Leon Bruckman; Itzcak PECHTALT
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-11-03
Filing date: 2021-11-03
Publication date: 2023-05-11

Abstract

An apparatus and a method for controlling congestion for multiple flows with heterogeneous quality of service, QoS, requirements, are presented. The method comprises generating for each of the multiple flows a utility function with coefficients which are based on heterogeneous QoS requirements of bandwidth, reliability and latency received from applications installed at an end point and parameters which are based on flow metrics of loss rate, sending rate and round trip time, RTT. Measuring the flow metrics, for each one of the multiple flows, and in each of a plurality of time intervals, changing the sending rate of each of the multiple flows according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function. And updating the flow utility function coefficients in case the measured loss rate and RTT do not match the heterogeneous QoS requirements.

Description

AN APPARATUS AND A METHOD FOR CONGESTION CONTROL FOR

MULTIPLE HETEROGENEOUS FLOWS

Field of Invention

The present disclosure, in some embodiments thereof relates to congestion control in computer systems data flow. More specifically, but not exclusively to an apparatus and method for congestion control for multiple heterogeneous flows.

Background

In data networking, Quality of Service (QoS) requirements are the main assessment and measuring tool to evaluate the network congestion. When a node or link in the network is carrying more data than it can handle, a network congestion occurs. Congestion control prevents senders from overwhelming the network. Congestion control modulates traffic entry into a telecommunication network in order to avoid congestive collapse resulting from oversubscription, usually by reducing the rate of packets sent to the network by the senders.

Summary

It is an object of the present disclosure to describe an apparatus and a method for endpoint congestion control for multiple heterogeneous flows.

It is another object of the present disclosure to provide an apparatus and a method, which creates a customized performance profile for each of the heterogeneous flows, based on the flow QoS requirements. Each flow profile guarantees multidimensional and multi-level requirements, and can co-exist with several other profiles at the same endpoint and/or at other endpoints. In addition, the performance profile may be updated in real-time when flow performance properties are too low/high or when flow requirements are modified. The apparatus method of the present disclosure uses the endpoints, independently of network equipment, providing QoS at per flow granularity, which thereby improves layers 1-3 (L1-L3) QoS techniques as they operate at service-class granularity.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures. In one aspect the present disclosure relates to an apparatus for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, comprising: a processing circuitry for: receiving heterogeneous QoS requirements of bandwidth, reliability and latency of the multiple flows from a plurality of applications installed at an end point; generating for each of the multiple flows a utility function with coefficients which are based on the received heterogeneous QoS requirements and parameters which are based on flow metrics of a loss rate, a sending rate and a round trip time, RTT; measuring the flow metrics of the loss rate, the sending rate and the RTT, of each one of the multiple flows and assigning the measured flow metrics in the utility function of each multiple flow; in each of a plurality of time intervals: changing the sending rate of each of the multiple flows according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function; and comparing the measured loss rate and RTT to the heterogeneous QoS requirements and updating the flow utility function coefficients in case the measured loss rate and RTT do not match the heterogeneous QoS requirements.

In a second aspect, the present disclosure relates to a method for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, comprising: receiving heterogeneous QoS requirements of bandwidth, reliability and latency of the multiple flows from a plurality of applications installed at an end point; generating for each of the multiple flows a utility function with coefficients which are based on the received heterogeneous QoS requirements and parameters which are based on flow metrics of a loss rate, a sending rate and a round trip time, RTT; measuring the flow metrics of the loss rate, the sending rate and the RTT, of each one of the multiple flows and assigning the measured flow metrics in the utility function of each multiple flow; in each of a plurality of time intervals: changing the sending rate of each of the multiple flows according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function; and comparing the measured loss rate and RTT to the heterogeneous QoS requirements and updating the flow utility function coefficients in case the measured loss rate and RTT do not match the heterogeneous QoS requirements.

In a further implementation of the first and second aspects, the sending rate of each of the multiple flows is calculated by inspecting packet headers of the flow.

In a further implementation of the first and second aspects, the RTT and loss rate are measured by extracting selective acknowledgements from a remote endpoint and comparing the headers of incoming and outgoing packets per each flow.

In a further implementation of the first and second aspects, the heterogeneous requirements are represented as minimum and/or maximum bounds.

In a further implementation of the first and second aspects, the heterogeneous requirements are represented as an average value and acceptable margins per each requirement.

In a further implementation of the first and second aspects, the utility function is based on a known utility function.

In a further implementation of the first and second aspects, mapping the received requirements values to parameters of the utility function is done by a mathematical formula applied to the requirements values.

In a further implementation of the first and second aspects, mapping the received requirements values to parameters of the utility function is done by converting the requirements values to integers and using the integers as indexes to read from predefined arrays of parameter values.

In a further implementation of the first and second aspects, converting the requirements values to integers is done by using a rounded value of logarithm of an average requirement value.

In a further implementation of the first and second aspects, the utility function comprises two parts: a first part is monotonically increasing with respect to a sending rate variable and a second part is monotonically decreasing with respect to loss rate and RTT variables.

In a further implementation of the first and second aspects, the second part of the utility function is also monotonically decreasing with respect to the sending rate variable.

In a further implementation of the first and second aspects, for each one of the multiple flows, history of each requirement, the utility function outcomes and the last sending rate for which the flow metrics matches the QoS requirements, are stored, for further use at a next time a flow with the same requirements arrives, to initialize the utility function and sending rate accordingly. In a further implementation of the first and second aspects, comparing the measured flow metrics to flow QoS requirements, is done once every predefined time intervals.

In a further implementation of the first and second aspects, comparing the measured flow metrics to flow QoS requirements, is done when a condition which is based on a predefined number of last sending rates is satisfied.

In a further implementation of the first and second aspects, the condition is satisfied when the last predefined number of sending rates indicate a stabilization of the sending rate.

In a further implementation of the first and second aspects, the utility function is ( (rate)^a — rate ■ (J3 ■ loss + y ■ dRTT + <p ■ aRTTy) where (a,P,y,(p) are the coefficients which are based on the received heterogeneous QoS requirements, wherein, P is based on the reliability requirements, y is based on the latency requirement and a and (p are based on the bandwidth requirement; and rate, loss, RTT, dRTT and a RTT are parameters which are based on the measured flow metrics where rate, denotes the sending rate, RTT, dRTT and a RTT denotes the RTT, the gradient of RTT and standard deviation of the RTT respectively and loss denotes the loss rate.

Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

Brief Description of the Several Views of the Drawings

Some embodiments of the disclosure are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments of the disclosure. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments of the disclosure may be practiced.

In the drawings:

FIG. 1 schematically shows a block diagram, of an apparatus for congestion control for multiple heterogeneous flows, according to some embodiments of the present disclosure;

FIG. 2 schematically shows an example of a class labeling option, according to some embodiments of the present disclosure;

FIG. 3 schematically shows a flow chart of a method for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, according to some embodiments of the present disclosure; and

FIG. 4 schematically shows an exemplary flowchart of an update methodology for a utility function, according to some embodiments of the present disclosure.

Detailed Description

The present disclosure, in some embodiments thereof relates to congestion control in computer systems data flow. More specifically, but not exclusively to an apparatus and a method for congestion control for multiple heterogeneous flows.

In modern daily life, network dependable applications are intensively used. For example: at home, people use application of video streaming, Voice over Internet Protocol (VoIP), file transfer, and the like. While traveling, people use applications of multimedia, navigation, hazards, and the like, and at work, applications of conference calls, high performance computing, and the like are commonly used. The network flows of these applications are heterogeneous, each of them has unique and dynamic Quality of Service (QoS) requirements and they may connect endpoints through different administrative domains. Therefore, there is a problem to satisfy the requirements of multiple co-existing flows when controlling only the endpoints rather than the entire network. For example, consider VoIP, file transfer and video streaming applications. A VoIP application requires low bandwidth while the video streaming application and file transfer application require higher bandwidth. Both the video streaming and VoIP applications need low latency, while the file transfer application may be satisfied with high latency. Moreover, VoIP and video streaming applications need medium reliability, while a file transfer application may handle low reliability.

In order to overcome this problem, two solutions exist. The first, is to use network management methods, which handle the congestion at the network administrative level. The second solution is to use distributed congestion control methods that operate at the network endpoint level (for example: Multipath Transmission Control Protocol (MPTCP), Performance- oriented Congestion Control (PCC), Multipath PCC (MPCC), Performance-oriented Congestion Control (PCC) Vivace, Bottleneck Bandwidth and Round-trip propagation time (BBR), TCP CUBIC, LEDBET and Performance-oriented Congestion Control (PCC) Proteus.

Methods of the first solution, require network manager privileges, and need full knowledge regarding the network topology, rates per node, and the like. Moreover, they also have full control over the network, including the congested part. Usually these methods are too slow to respond to network congestion incidents.

Methods of the second solution follow one of two approaches. The first approach is fair share methods, which divide the bandwidth equally between the flows (such as MPCTP, MPCC, PCC Vivace, BBR). The second approach is the exclusive methods, which give higher priority to one of the flows. The rest of the flows, which have lower priority, may be nearly starved (such as Cubic with LEDBAT, Proteus).

However, in heterogeneous scenarios as considered by the present disclosure, for example consider VoIP, file transfer and video streaming applications, a dynamic bandwidth allocation is needed, not extreme to one side but still able to provide different levels of performance, including for example reliability and delay. Only this way, the heterogeneous flows may co-exists and satisfy their requirements (for example, streaming and VoIP applications).

The present disclosure discloses a new endpoint congestion control method and apparatus that support heterogeneous requirements. It supports multi-dimensional QoS requirements profile for each flow, including bandwidth, reliability and latency, and it supports high video resolution requirements.

The apparatus and method of the present disclosure may change QoS profiles on the fly, when flow performance properties are too low/high or when flow requirements are modified. It may be added on top of any connection oriented transport protocol that uses packet confirmations, such as TCP, and it does not interfere with existing network services (e.g., routing) and middle boxes (e.g., firewalls).

The method of the present disclosure uses the endpoints, independently of network equipment, providing QoS at per flow granularity. This improves L1-L3 QoS techniques as they operate at service-class granularity.

Before explaining at least one embodiment of the disclosure in detail, it is to be understood that the disclosure is not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. The disclosure is capable of other embodiments or of being practiced or carried out in various ways.

The present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

The computer readable program instructions may execute entirely on the user's computer and /or computerized device, partly on the user's computer and /or computerized device, as a stand-alone software package, partly on the user's computer (and /or computerized device) and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer and /or computerized device through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions. The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Reference is now made to FIG. 1, which schematically shows a block diagram, of an apparatus for congestion control for multiple heterogeneous flows, according to some embodiments of the present disclosure. Apparatus 100 includes a congestion controller 101, with a processing circuitry, which receives heterogeneous QoS requirements of bandwidth, reliability and latency of multiple flows from a plurality of applications 102. The congestion controller 101 also receives flow metrics, of lose rate, sending rate and round trip time (RTT), which are measured by network monitor 103, which monitors the performance of each flow of the multiple flows, to verify compliance with the QoS requirements received by the congestion controller 101.

The network monitor receives the incoming flows from the applications 102 and the outgoing flows from the network to the applications 102, this is in order to compare the incoming and outgoing flows, to evaluate the performance of the multiple flows. The network monitor 103 accesses header of packets of each flow, to record the sending rates of each packet. Then, the network monitor 103 receives a selective acknowledgment (ACK) from the packet header, and compares the incoming and outgoing traffic. This way, two metrics are calculated: the flows RTTs and their loss rates. These metrics are then forwarded to the congestion controller 101, for regulating the sending rates.

According to some embodiments of the present disclosure, the congestion controller 101, generates for each of the multiple flows a utility function with coefficients which are based on the received heterogeneous QoS requirements and parameters which are based on the measured flow metrics. The utility function provides a number as an outcome, which indicates whether the sending rate should be increased or decreased, when the measured flow metrics do not fit the QoS requirements, or stay the same, when the measured flow metrics fit the QoS requirements of the heterogeneous flows. In each of a plurality of time intervals, the congestion controller 101, changes the sending rate of each of the multiple flows according to the outcomes of the utility function when assigning the measured loss rate and RTT in the utility function. According to some embodiments of the present disclosure, the performance profile is defined by the required QoS requirements levels of bandwidth, latency and reliability. The number of labeled levels may vary between the QoS requirements.

For example, when five levels are used per each QoS requirement of bandwidth, latency and reliability, 125 different classes may be used. FIG. 2 schematically shows an example of a class labeling option, according to some embodiments of the present disclosure. Three applications of VoIP, streaming and file transfer are used. Each application has different QoS requirements. Each requirement is divided into five levels. The VoIP application has low bandwidth requirement - level 1, low latency requirement - level 1 and medium reliability requirement - level 3. The streaming application has high bandwidth requirement - level 5, medium-low latency requirement - level 2, and medium reliability requirement - level 3. The file transfer application has medium bandwidth requirement - level 3, high latency requirement - level 5 and low reliability requirement - level 1. According to some embodiments of the present disclosure, a unique performance profile is generated for each class, as a utility function, with sensitivity coefficients, which are based on the QoS requirements.

According to some embodiments of the present disclosure, when the QoS requirement are still not satisfied, then, the congestion controller 101 (see FIG. 1) compares the measured loss rate and RTT to the heterogeneous QoS requirements. In case the measured loss rate and RTT do not match the heterogeneous QoS requirements, the congestion controller 101 updates the flow utility function coefficients. It is noted that the coefficients of the flow utility function are usually constant; however, according to some embodiments of the present disclosure, the coefficients of the flow utility function are changed and updated to bring to the satisfaction of the QoS requirements of the heterogeneous flow.

According to some other embodiments, the present disclosure, discloses an endpoint congestion control method that supports heterogeneous requirements. In the method of the present disclosure, flow performance (QoS) requirements such as bandwidth, reliability and latency are received, for example as a list of values. Based on the QoS requirements, a performance profile is generated by the congestion controller 101. The profile consists of a utility function that modulates flow sending rates based on flow performance measurements, i.e. flow metrics of loss rate, RTT and sending rate.

Reference is now made to FIG. 3, which schematically shows a flow chart of a method for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, according to some embodiments of the present disclosure. At 301, the congestion controller, which comprises a processing circuitry, receives heterogeneous QoS requirements of bandwidth, reliability and latency of the multiple flows from a plurality of applications installed at an end point. At 302, the congestion controller 101, generates for each of the multiple flows a utility function with coefficients, which are based on the received heterogeneous QoS requirements and parameters, which are based on flow metrics of sending rate, loss rate and RTT. At 303, the network monitor 103, measures the flow metrics of loss rate, sending rate and RTT, of each one of the multiple flows and sends the results of the measured flow metrics to the congestion controller 101, for assigning the measured flow metrics in the flow utility function of each multiple flow. For each flow, performance is monitored to verify compliance with the requested QoS requirements. The network monitor uses the headers of the flow packets, to extract the sending rates of the flow. Then, the network monitor 103 gets a selective acknowledgment (ACK), and compares the incoming and outgoing traffic. This way, two metrics are calculated: the flows RTTs and the flows loss rate. These metrics are then forwarded to the congestion controller 101, for regulating the sending rates. Then, in each of a plurality of time intervals, the congestion controller 101, at 304, changes the sending rate of each of the multiple flows, according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function. Sometimes, the change of the sending rate is enough to bring the flow metrics measurements of the multiple heterogeneous flows to match the QoS requirements. Then, In some embodiments of the present disclosure, at 305 the congestion controller 101, compares the measured loss rate and RTT to the heterogeneous QoS requirements and in case the measured loss rate and RTT do not match the heterogeneous QoS requirements, the congestion controller 101 updates the flow utility function coefficients. In some embodiments of the present disclosure, the change of the sending rate is done more frequently than the update of the flow utility function coefficients. After the sending rate is changed a predefined number of times and the measured flow metrics still do not match the QoS requirements, the coefficients are updated.

In some embodiments of the present disclosure, the utility function is generated by mapping flow requirement values to coefficients values, substituted in a utility function template. These coefficients may be adjusted over time in order to improve flow allocation when the QoS requirements are under-satisfied or over- satisfied.

The congestion controller 101 operates at each endpoint, regulating the sending rates of the endpoint flows based on network congestion and the performance requirements of each flow. The operation of the congestion controller 101, may be divided into three tasks: (i) generation of performance profile from flow QoS requirements, (ii) continues usage of performance profile, and (iii) updating the performance profile when needed.

According to some embodiments of the present disclosure, the congestion controller 101, receives each flow QoS requirements from the application (as can be seen in FIG. 1). The QoS requirements may be represented for example by minimum and maximum bounds of flow properties such as bandwidth (in Kbps), latency (in micro-second), and loss rate ratio. Another way to represent requirements may be by average value and acceptable margins per property. The two representations are interchangeable. According to the QoS requirements of each flow, a performance profile is generated. The performance profile consists of a utility function. The utility function is generated by mapping the QoS requirements to the coefficients of the utility function, and substituting the QoS requirements in the utility function coefficients. Mapping the QoS requirements to the coefficients of the utility function may be done, for example, by a mathematical formula applied to the QoS requirements values or by first converting the QoS requirements values to integers used as indexes to read from predefined arrays of parameter values. For example, converting a QoS requirement to integer may be done by taking the integer part of the logarithmic value of the average required property value. As a more detailed example assume there is a predefined parameter values array [5000, 4000, 3000, 2000, 1000, 0] indexed from 0 to 5 and assume a bandwidth requirement is of 500 Kbps-2500 Kbps. First the average bandwidth requirement of 1500 Kbps is taken and its log (base 10) is calculated arriving to 3.17. Then the integer part 3 is used as an index, which reads from the array, returning the value 2000 as a function coefficient, which is later substituted in the function template to get the utility function. The congestion controller may use utility function templates that reward flow’s high sending rate, but also add penalties for high loss rate and long RTT, where penalties may be proportional to the sending rate. According to some embodiments of the present disclosure, the function template may be based on known utility functions, for example:

(1) ( (rate)^a — rate ■ (J3 ■ loss + y ■ dRTT + <p ■ aRTTy)

Where (a,P,y,(p) are the coefficients which are sensitive to the QoS requirements, for example, P is sensitive to the reliability requirements, y is sensitive to the latency requirement and a and (p are sensitive to the bandwidth requirement. After substituting the (a,P,y,(p) coefficients, the outcome function has parameters which accept flow performance metrics of rate, which denotes the last sending rate, RTT or derivatives of RTT, such as RTT gradient (dRTT) and standard deviation (o(RTT)) and loss which denotes the loss rate.

According to some embodiments of the present disclosure, once every predefined time interval (called regulate-interval), for each flow, the congestion controller 101 receives the flow performance metrics (for example last sending rate, RTT and loss rate) from the network monitor 103. Then, the performance metrics are fed into the performance profile utility function. The function outcomes indicate the required change to the sending rate. For example, positive value or positive gradient may indicate that the sending rate should be increased and vice versa. The new rate value is sent to rate limiter 104 in order to take effect on the flow. At the beginning the flow rate may be determined as the average between the maximum and minimum QoS bandwidth requirements. According to some embodiments of the present disclosure, for faster convergence, the congestion controller 101 may keep the history of each flow requirements, utility functions, as well as the flows last rate in which the flow was not unsatisfied or over- satisfied. This way, the next time a flow with the same QoS requirements arrives, the congestion controller 101 initializes the utility function and sending rate accordingly, to speed up convergence.

According to some embodiments of the present disclosure, in each of a plurality of time interval, for each flow, the congestion controller 101 checks whether the flow has unsatisfied or over- satisfied requirements by comparing the flow performance metrics received from the network monitor 103 and the flow minimum and maximum QoS requirements. The frequency of these checks may be either fixed or based on the last several sending rates. For example - waiting for stabilization (stable state) or for a good approximation of the convergence rate. A stable state may be defined by two parameters: stabilization threshold, and integer K. If for K sequential time intervals, the difference in sequential sending rates is lower than stabilization threshold, then the state is stabilized. Otherwise, the state is not stable. Another definition may use a threshold over the variance of the last K rates.

According to some embodiments of the present disclosure, when a flow has unsatisfied or over-satisfied requirements its utility function may be modified based on the actual performance of the relevant requirements. A possible modification method may be to map a lower flow property value to parameter when the actual property value is over-satisfied (and vice-versa) and replace the parameter value in the utility function accordingly.

FIG. 4 schematically shows an exemplary flowchart of the update methodology for the utility function of equation (1), according to some embodiment of the present disclosure. At 401, it is checked if the reliability is too low. In case that the reliability is too low, at 402, the relevant sensitivity coefficient P is updated, in order to increase the “penalty” over the reliability requirement. At 403, it is checked if the latency is too high, and at 404, in case the latency is too high, the relevant coefficient y is updated and increased accordingly. At 405, it is checked if the bandwidth is too low. In case the bandwidth is too low, at 406 the sensitive coefficient (p is decreased to relax the penalty related with the competition between flows. This way, the flow increases its sending rate and achieves higher bandwidth. At 407, it is checked if the bandwidth is too high. When it is too high, at 408, the relevant coefficients P,y ,(p are increased. Moreover, when the requirements are over-satisfied, for example when the sending rate exceeds the threshold over the required bandwidth, then the congestion controller 101 updates the flow utility function by increasing all the penalties, for decreasing its sending rate rapidly. At 409, in case the bandwidth is not too high, the check ends and a time interval of t second is awaited before restarting from 401.

According to some embodiments of the present disclosure, the update procedure may be bounded so that a current coefficient will always match a requirement value within the profile required minimum and maximum. If the boundary is exceeded the congestion controller 101 may warn the application that a flow requirement cannot be fulfilled, allowing it to change the requirements or to shut down.

The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant methods and apparatuses for congestion control for multiple heterogeneous flows will be developed and the scope of the term methods and apparatuses for congestion control for multiple heterogeneous flows is intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of' and "consisting essentially of'.

The phrase "consisting essentially of' means that the composition or method may include additional ingredients and/or steps, but only if the additional ingredients and/or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

As used herein, the singular form "a", "an" and "the" include plural references unless the context clearly dictates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment of the disclosure may include a plurality of “optional” features unless such features conflict.

Throughout this application, various embodiments of this disclosure may be presented in a range format. It should be understood that the description in range format is merely for convenience and brevity and should not be construed as an inflexible limitation on the scope of the disclosure. Accordingly, the description of a range should be considered to have specifically disclosed all the possible subranges as well as individual numerical values within that range. For example, description of a range such as from 1 to 6 should be considered to have specifically disclosed subranges such as from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6 etc., as well as individual numbers within that range, for example, 1, 2, 3, 4, 5, and 6. This applies regardless of the breadth of the range.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween. It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the disclosure. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present disclosure. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

1. An apparatus for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, comprising: a processing circuitry for: receiving heterogeneous QoS requirements of bandwidth, reliability and latency of the multiple flows from a plurality of applications installed at an end point; generating for each of the multiple flows a utility function with coefficients which are based on the received heterogeneous QoS requirements and parameters which are based on flow metrics of a loss rate, a sending rate and a round trip time, RTT; measuring flow metrics of the loss rate, the sending rate and the RTT, of each one of the multiple flows and assigning the measured flow metrics in the utility function of each multiple flow; in each of a plurality of time intervals: changing the sending rate of each of the multiple flows according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function; and comparing the measured loss rate and RTT to the heterogeneous QoS requirements and updating the flow utility function coefficients in case the measured loss rate and RTT do not match the heterogeneous QoS requirements.

2. The apparatus of claim 1, wherein the sending rate of each of the multiple flows is calculated by inspecting packet headers of the flow.

3. The apparatus of claim 1, wherein the RTT and loss rate are measured by extracting selective acknowledgements from a remote endpoint and comparing the headers of incoming and outgoing packets per each flow.

4. The apparatus of claim 1, wherein the heterogeneous requirements are represented as minimum and/or maximum bounds.

5. The apparatus of claim 1, wherein the heterogeneous requirements are represented as an average value and acceptable margins per each requirement.

6. The apparatus of claim 1, wherein the utility function is based on a known utility function.

7. The apparatus of claim 1, wherein mapping the received requirements values to parameters of the utility function is done by a mathematical formula applied to the requirements values.

8. The apparatus of claim 1, wherein mapping the received requirements values to parameters of the utility function is done by converting the requirements values to integers and using the integers as indexes to read from predefined arrays of parameter values.

9. The apparatus of claim 8, wherein converting the requirements values to integers is done by using a rounded value of logarithm of an average requirement value.

10. The apparatus of claim 1, wherein the utility function comprises two parts: a first part is monotonically increasing with respect to a sending rate variable and a second part is monotonically decreasing with respect to loss rate and RTT variables.

11. The apparatus of claim 10, wherein the second part of the utility function is also monotonically decreasing with respect to the sending rate variable.

12. The apparatus of claim 1, wherein for each one of the multiple flows, history of each requirement, the utility function outcomes and the last sending rate for which the flow metrics matches the QoS requirements, are stored, for further use at a next time a flow with the same requirements arrives, to initialize the utility function and sending rate accordingly.

13. The apparatus of claim 1, wherein comparing the measured flow metrics to flow QoS requirements, is done once every predefined time intervals.

14. The apparatus of claim 1, wherein comparing the measured flow metrics to flow QoS requirements, is done when a condition, which is based on a predefined number of last sending rates is satisfied.

15. The apparatus of claim 14, wherein the condition is satisfied when the last predefined number of sending rates indicate a stabilization of the sending rate.

16. The apparatus of claim 1, wherein the utility function is

( (rate)^a — rate ■ (J3 ■ loss + y ■ dRTT + <p ■ aRTTy) where (a,P,y,(p) are the coefficients which are based on the received heterogeneous QoS requirements, wherein, P is based on the reliability requirements, y is based on the latency requirement and a and (p are based on the bandwidth requirement; and rate, loss, RTT, dRTT and a RTT are parameters which are based on the measured flow metrics where rate, denotes the sending rate, RTT, dRTT and a RTT denotes the RTT, the gradient of RTT and standard deviation of the RTT respectively and loss denotes the loss rate.

17. A method for controlling congestion in data communication for multiple flows with heterogeneous quality of service, QoS, requirements, comprising: receiving heterogeneous QoS requirements of bandwidth, reliability and latency of the multiple flows from a plurality of applications installed at an end point; generating for each of the multiple flows a utility function with coefficients which are based on the received heterogeneous QoS requirements and parameters which are based on flow metrics of a loss rate, a sending rate and a round trip time, RTT; measuring flow metrics of the loss rate, the sending rate and the RTT, of each one of the multiple flows and assigning the measured flow metrics in the utility function of each multiple flow; in each of a plurality of time intervals: changing the sending rate of each of the multiple flows according to outcomes of the utility function when assigning the measured loss rate and RTT in the utility function; and comparing the measured loss rate and RTT to the heterogeneous QoS requirements and updating the flow utility function coefficients in case the measured loss rate and RTT do not match the heterogeneous QoS requirements.

18