Quality of service management in network gateways

Description of equivalent WO 2004015520 A2

QUALITY OF SERVICE MANAGEMENT IN NETWORK GATEWAYS

0002FIELD OF THE INVENTION [0001] The present invention relates to ensuring quality-of-service in networks, and in particular to ensuring quality-of-service for networks transmitting and receiving realtime and non-realtime data-streams.

0003BACKGROUND OF THE INVENTION [0002] Network users are able to access various types of information from the Internet and other sources. The type of information that the network users can access can be broadly divided into two categories: realtime streams and non-realtime streams. For example, a typical user will be receiving realtime data streams of video or audio and non-realtime data streams like e- mail, web pages, or File-Transfer Protocol (FTP) downloads. Realtime data- streams are generally required to be transmitted or processed within some small upper limit of time. Non-realtime data-streams are broadly understood to be not requiring processing or transmission within the time constraints such as those required for the realtime data-streams. Realtime and non-realtime data- streams have differing characteristics as described next. [0003] The chief characteristics of realtime and non-realtime data- streams of relevance here are their respective bandwidth requirements for providing different levels of Quality-of-service (QoS). QoS is broadly understood as the set of performance properties of given a network service, generally including throughput, transit, delay and priority. In the present context of realtime streams, the additional QoS parameters include bandwidth availability, delay and jitter among other parameters. Those skilled in the art will appreciate that relevancy and importance of any given QoS parameters will depend upon the nature of the realtime data stream used in a particular application. The invention covers and supports any set of QoS parameters for a given realtime data stream. Realtime streams need a guaranteed QoS for providing relatively fast and time constrained information transmission. Non- realtime streams are generally transmitted using the transmission control protocol (TCPyintemet Protocol (IP). Contrastingly, non-realtime streams do not generally require the QoS similar to that required for the realtime streams. A typical example of a network handling realtime and non-realtime data- streams is described next. [0004] A network can be configured to receive both realtime and non- realtime data-streams from an external source. A single transmission channel generally links the user's network to the Internet service provider (ISP). The same transmission channel concurrently carries both the realtime and non- realtime streams. The bandwidth capacity of such a transmission channel generally remains fixed. Therefore, it becomes necessary to balance the allocation of available bandwidth between the conflicting demands made by the realtime and non-realtime streams. The problem of bandwidth allocation is illustrated next in the context of a typical user.

0004[0005] A network user is usually connected to a network like Internet through a service provider who may provide Internet-access and possibly other services like video-on-demand, IP telephony, streaming audio and video. The service provider is linked to the network user by a transmission channel like a dial-up telephone line, xDSL, ISDN, etc. The connecting device at the service provider's end may be an edge router, and at the network user end it would generally be a gateway.

0005[0006] Realtime data-streams require an almost fixed allocation of bandwidth. Realtime data-streams offer little flexibility in adjusting bandwidth requirements without compromising the QoS parameters. In contrast, the non- realtime data-streams are relatively flexible about their bandwidth demands, because they do not usually require a relatively strict QoS. Bandwidth availability may change over a given period of time. Therefore, the non- realtime stream traffic from the service provider to the network user needs to be controlled in order to ensure that the realtime streams get the required bandwidth for maintaining its QoS. Possible methods for controlling the sharing of bandwidths are considered next.

0006[0007] A conventional approach using a packet pacing method is discussed next. Non-realtime traffic transmitted from the router located at the service provider to the gateway will generally be the Internet communication traffic transmitted using the TCP protocol. The TCP sender at the Internet site controls the non-realtime traffic by pacing the non-realtime packets to ensure that the realtime traffic gets the required bandwidth. The packet pacing method and its associated problems are described next.

0007[0008] Packet pacing is generally performed by controlling the rate of packet transmission. Implementing such packet pacing method requires significant changes in the operations of a TCP sender. In a typical network user scenario the TCP sender, i.e., a HTTP server, is under control of an external agency like a university, hospital, or company. The ISP may not be expected to employ any particular bandwidth management techniques. An ISP typically will be servicing a large number of users in a situation where each one of the users has several active TCP connections operating at the same time. Such packet pacing approach is not feasible to implement at an ISP site due to scalability problems associated with supporting a large number of users. Thus, there is a need for an improved bandwidth management technique that is implemented at the gateway side of the network.

0008[0009] Another approach involves controlling the TCP traffic for the non-realtime streams from a conventional user gateway. The difficulty with this approach is that the TCP-receiver at the user gateway has almost no operatively effective control over the TCP-sender, which is typically a Hypertext Transfer Protocol (HTTP) server or a FTP server. Hence, there is a need for an apparatus and method that allows controlling the non-real time traffic at the gateway end, and which is feasible in a TCP environment without using any special apparatus at the user end.

0009[0010] Above described known methods for bandwidth management in networks where realtime and non-realtime traffic share the available bandwidth of a channel have several drawbacks as described above. Thus, there is a need for a bandwidth management solution that allows controlling the non-realtime streams bandwidth demands so that the realtime streams can provide a desired QoS. Further, there is a need for implementing such a solution on the gateway located at the user's end of the network. SUMMARY OF THE INVENTION [0011] A system for ensuring quality of service in a network is disclosed. The network uses a single communication channel sharing realtime and non-realtime transmissions, e.g. TCP traffic, that is connected to a gateway. The non-realtime streams are transmitted using non-realtime senders that have flow control parameters or windows. The gateway is further connected to a network including various network elements. The gateway includes a bandwidth control unit that controls the bandwidth demands of the non-realtime transmissions by adjusting the flow control parameter on the non- realtime senders. The realtime streams require consistent bandwidth to support quality of service parameters like delay and jitter. The bandwidth control regulates the non-realtime connections bandwidth requirement, and hence ensures the bandwidth required by realtime streams. The bandwidth control can also dynamically allocate bandwidth between multiple non-realtime TCP connections, so that the unused bandwidth available during a TCP slow- start of a given TCP connection can be allocated to other steady state TCP connection.

0010[0012] Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.

0011BRIEF DESCRIPTION OF THE DRAWINGS [0013] The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:

0012[0014] Figure 1 shows a network configuration for illustrating the invention's implementation of bandwidth management;

0013[0015] Figure 2 shows an exemplary network configuration having a single TCP sender and implementing the invention's bandwidth management; [0016] Figure 3 is a graph showing the average bandwidth for the realtime and non-realtime streams in the absence of any bandwidth management;

0014[0017] Figure 4 shows the average inter-packet time for the VoD stream;

0015[0018] Figure 5 shows network configuration having multiple TCP connections and implementing bandwidth management;

0016[0019] Figure 6 is a graph showing the average bandwidth of each stream and the aggregate bandwidth of all streams; and [0020] Figure 7 is a graph showing performance characteristics of dynamic bandwidth management.

0017DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0021] The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.

0018[0022] Figure 1 shows a network configuration 10 for illustrating bandwidth management. Bandwidth management mechanism employing the principle of the invention will be illustrated using the exemplary network configuration 10. Hence, the network configuration 10 is described next in detail. The constituent elements of the network configuration 10 are described next. A VoD server 12 and an Internet Protocol (IP) phone 14 are connected to a private network 16. The VoD server 12 provides video-on-demand transmissions and the IP phone 14 provides phone-like communication service using the IP protocol to the network user. A FTP server 18 and a HTTP server 20 are connected to an Internet server 22. Typically, the VoD server 12 and the IP phone 14 transmit in a realtime manner with strict time constraints. In contrast, the FTP server 18 and the HTTP server 20 transmit information in a non-realtime manner with relatively stringent time constraints. Those skilled in the art will appreciate that the following description of the network is only an illustration and that invention covers any suitable type of network configuration. [0023] Internet server 22 and the private network 16 are both connected to an ISP edge router 24. An access segment 26 connects the edge router 24 to a gateway 28. Access segment 26 is a communication channel for transmitting and receiving data to and from said ISP edge router 24 and the gateway 28. Access segment 26 is generally a broadband connection like xDSL, ISDN or coaxial cable, but it can also be a dial-up telephone connection. Access segment 26 simultaneously carries both realtime and non-realtime streams transmitted via the edge router 24. Streams are logical channels of data-flow. Realtime streams carry realtime data for applications like video-on demand. Non realtime streams in the present context are generally TCP or similar logical communication exchange using an appropriate protocol. Those skilled in the art will appreciate that the term "streams" in used in a generally broad manner to indicate a sequence of data or information.

0019[0024] Realtime streams share the bandwidth of the same access segment 26 with the non-realtime TCP traffic, and hence bandwidth management methods or algorithms are required to apportion the available bandwidth between realtime and non-realtime streams. Such a bandwidth management method or algorithm should limit the incoming TCP traffic in such a manner that sufficient bandwidth out of the aggregate bandwidth is left for the realtime streams that have strict QoS requirements. Preferable characteristics of the edge router 24 are described next.

0020[0025] Edge router 24 is a connection point for the network user communicating with the service provider. Edge router 24 can be any general purpose device generally having the capability to forward packets from the Internet hosts to the gateway 28. Edge router 24 must be able to transmit and receive IP packets between the gateway 28 and the Internet server 22. Hence, any router providing such service can be used here as the edge router 24. Edge router 28 may have other capabilities, e.g. ability to multiplex Internet and other traffic, but additional capabilities are not relevant for the present invention. The only capability that is relevant here is the ability to transmit and receive IP packets from the Internet hosts to the gateway 28. Next, the features of the data-streams carried over the access segment 26 are described.

0021[0026] The realtime media streams may be transmitted as IP or non- IP traffic. One of the characteristics of the realtime streams that is considered relevant here is that they are packetized, i.e., sent in packets, and have stringent time constraints, and any packet delays are detrimental to their performance characteristics. Realtime streams carried over the access segment 26 have strict QoS requirements such as sufficient bandwidth, minimal delay and minimal or no jitter. The media streams from the VoD server 12 and the IP phone 14 are merely examples of any realtime streams, and the invention is not limited by the number or types of realtime streams of information. The modalities of transmitting realtime streams are not considered here as they may vary across configurations. The principle of the invention encompasses any type of realtime transmission having certain definite bandwidth requirements necessary to ensure a given set of QoS parameters. The preferable network location for implementing the bandwidth management method is the gateway 28. Preferable characteristics of the gateway 28 are described next.

0022[0027] Gateway 28 connects the access segment 26 and the network 30. Network 30 may be constructed by using multiple networking technologies, for example, IEEE 1394, Ethernet, 802.11 wireless LAN, and powerline networks. Gateway 28 can be a conventional gateway or a router installed as a separate unit. The gateway 28 is an interconnection point in the network for connecting the network 30 to the edge router 24. The gateway 28 can also be integrated in an appliance such as digital television or a set-top-box. The function of the gateway 28 is to provide a point of connection between the Internet connection on its one interface and the network 30 connected components on its other interface. Gateway 28 serves as a connection point for a network 30 to the edge router 24. The network 30 and associated network elements are described next.

0023[0028] A range of network elements can be connected to the gateway 28 through the network 30 . Various devices like television 32, computers 34 and IP phones 14 can be connected to the network 30. Those skilled in the art will appreciate that the network elements shown here are used only to illustrate the type of devices that can be connected to the network 30. Above listed devices or appliances are merely illustrations and many other devices can also be connected to the network 30.

0024[0029] Figure 2 shows an exemplary network configuration having a single TCP sender and implementing bandwidth management. The invention can be better understood by those in skilled in the art from a comparison between a network with bandwidth management and a network without bandwidth management. Bandwidth management for a network having a single TCP sender is described in two steps. In the first step, the performance of the network is simulated and analyzed while assuming that no bandwidth management is performed. Such a simulation provides a background for making a comparison between the network without and with bandwidth management. In the second step, the same network is simulated and analyzed, but with a bandwidth control being used to implement the invention's principle for a single TCP sender network. Therefore, first the network shown in Figure 2 is simulated and analyzed assuming that there is no bandwidth control as described below. [0030] The following description establishes the need for bandwidth control. An assumption is made that the bandwidth control shown in the figure 2 does not exist in order to provide a comparison further-on in the description below. The network described here is used to simulate the performance characteristics of a typical network that does not use any bandwidth management. VoD server 12, HTTP server 20, Internet server 22, edge router 24 and the gateway 28 are interconnected as described in the context of figure 1.

0025[0031] In the present network the access segment 26 is a dedicated asymmetric link, for example, an ADSL link, with a downstream bandwidth of 2.0 Mbps and an upstream bandwidth of 0.7 Mbps. The delay in context of the access segment 26 is a negligible 1 ms, since typically the edge router 24 and the gateway 28 would be relatively close to each other. [0032] VoD server 12 is connected to the edge router 24 by a full- duplex VoD link 36 having a 20 ms delay. VoD server 12 transmits video signal having a constant bit rate (CBR) in a realtime manner at the rate of 1.0 Mbps. The HTTP server 20 is configured as a constituent part of the Internet server 22 (as shown) or it may be externally connected (as shown in figure 1) to the Internet server 22. The HTTP server 20 transmits non-realtime data packets over a full duplex HTTP link 38 having 1.5 Mbps bandwidth and a 20 ms delay. [0033] Edge router 24 includes a first-in-first-out (FIFO) queue 40 having a capacity to hold 20 packets. Realtime stream from the VoD server 12 requires 1 Mbps bandwidth from the aggregate 2 Mbps downward capacity 42 of the access segment 26. As a result, the HTTP server 20 can transmit packet traffic that uses up to 1.0 Mbps maximum capacity for non-realtime traffic directed toward the gateway 28.

0026[0034] Figures 3 and 4 deal with a network simulation for a network using no bandwidth control for management bandwidth requirements of non- realtime streams. First, some foundational information about the simulation technique is described below.

0027[0035] A network simulator is used to perform simulations for comparing performance with and without bandwidth management. Any conventional network simulator capable of performing simulation as described next may be used. For example, the 'ns UCB/LBNL/VINT' network simulator can be used. The VoD Stream is modeled by a CBR source sending data using the user datagram protocol (UDP) with a packet size of 576 bytes. A TCP connection for non-realtime data is modeled using a TCP/Reno source at the HTTP server 20 and a TCP sink at the gateway 28. The maximum segment size is set to 576 bytes, and the size of an initial flow control window 46 is set to 32 packets. The TCP flow control window 46 sizes are 16 KB or 32 KB for most operating systems. Hence, the HTTP server 20 always sends TCP packets of size 576 bytes, and does not have more than 64 unacknowledged TCP segments in transit. In the present context the TCP sender in the description below would mean the HTTP server 20, which transmits the HTTP download 52 to the gateway 28. Following the foundational information for network simulation, the specific simulations are described below in context of the appropriate figures.

0028[0036] Figure 3 is a graph showing the average bandwidth for the realtime and non-realtime streams in the absence of any bandwidth management. Time measured in seconds is plotted on the X-axis of the graph, and average bandwidth measured in Mbps is plotted on the Y-axis. The average bandwidth is calculated at the gateway 28 over a period of 0.1 seconds. The graph clearly shows that the VoD stream 50 is not able to receive a consistent bandwidth of 1 Mbps, which is bandwidth required for the realtime VoD stream 50 to satisfy the QoS parameters like delay and jitter.

0029[0037] Further, the HTTP download 52 also shows chaotic behavior due to packet drops at the edge router 24 (see figure 2). Whenever the HTTP server 20 (see figure 2) starts pumping the HTTP download 52 requiring more than 1 Mbps bandwidth, the edge router 24 starts dropping packets from both the realtime and non-realtime streams. This problem occurs at 1.40 seconds, at 3.5 seconds and then repeats itself periodically.

0030[0038] Just as the HTTP download 52 starts losing packets at 1.40 seconds, the TCP congestion window 48 (see figure 2) gets smaller to adjust for the congestion. This causes the HTTP server 20 to reduce its rate of packet transmission. Such a rate reduction for the HTTP download 52 is a positive factor for the VoD stream 52, but the access segment 26 bandwidth remains under-utilized since the reduced HTTP download 52 leaves some bandwidth unused. The under-utilization of bandwidth due to reduced HTTP download 52 continues till the TCP sender recovers its lost packets and increases its transmission rate. Once the TCP sender fully recovers and starts transmitting above 1 Mbps limit at around 3.5 seconds the edge router 24 again drops packets from both streams causing the same behavior that occurred at occurred at 1.4 seconds as described above and this cycle continues till the end of simulation. [0039] Figure 4 shows the average inter-packet time for the VoD stream 50. Time measured in seconds is plotted on the X-axis of the graph, and average inter-packet time measured in Mbps is plotted on the Y-axis. [0040] Jitter is an undesirable characteristic in a realtime transmission. The average inter-packet time is a good indicator of jitter. Variable inter-packet time leads to more jitter. As soon as the HTTP server 20 starts pumping HTTP download 52 (see figure 3) above the 1 Mbps level, the VoD stream 52 (see figure 3) packets are delayed in the FIFO queue 40 (see figure 2), and thus causing the inter-packet time to increase. Later when the HTTP server 20 detects the packet drops and reduces its rate of packet transmission, the packets that have been queued in the FIFO queue 40 are transmitted in quick succession leading to decrease in the inter-packet time. Both of these cases of increase or decrease in the inter-packet time are undesirable and either cause underflow or overflow at the other end on the gateway 28. Ideally, the inter-packet time should remain constant at the level shown by the no-jitter line 54. The sections where jitter occurs during the transmission and causes problems is shown by jitter-regions 56. In the second step as referred to above, the full network as shown in figure 2 is now discussed below including bandwidth management for a single TCP sender network using the principle of the invention.

0031[0041] A network configuration that uses realtime and non-realtime transmission over a single transmission channel faces bandwidth allocation problems as described above. The description below is in the context of a single transmission channel, but those skilled in the art will appreciate that the invention can operate over multiple transmission channels also.

0032[0042] Bandwidth management is required to adhere to the QoS requirements of realtime streams. Bandwidth management also improves the overall channel utilization of the access segment 26 and the throughput of the non-realtime network traffic. Bandwidth management ensures the QoS criteria for realtime streams. Bandwidth management requires a choice to be made of a location in the network for implementing the bandwidth control methods. Gateway 28 is the present invention's preferred location in the network for implementing bandwidth control.

0033[0043] The bandwidth management technique of the present invention for a single TCP sender will be described next while referring back to the figure 2. In a typical network setting, a TCP sender like the HTTP sever 20 would not know in advance the available bandwidth in the path of its transmission to a TCP receiver. The TCP receiver like the gateway 28 of the present embodiment would have that knowledge of available path bandwidth. Here, the gateway 28 knows in advance that the TCP traffic should not exceed 1 Mbps, because the realtime traffic needs an assured bandwidth of 1 Mbps from the overall access segment 26's downward capacity of 2.0 Mbps.

0034[0044] The gateway 28 uses its knowledge of bandwidth requirements of the realtime and non-realtime streams to control the non- realtime, i.e., TCP traffic, coming from the HTTP server 20 so that the TCP traffic does not exceed the bandwidth available for non-realtime streams. Hence, the realtime streams are able to satisfy the required QoS criteria.

0035[0045] The bandwidth control 60 makes it possible to ensure the QoS requirements for the realtime streams are satisfied by controlling the data flow from the gateway 28 end. The bandwidth control 60 can be implemented in hardware, as a software module or as a combination of hardware and software.

0036Controlling the flow of non-realtime traffic from the gateway 28 end eliminates the possible scalability problems associated with the solutions that control traffic from the edge router 24 at the Internet service provider side. [0046] If a bandwidth management solution is employed at the edge router 24 end then a separate protocol is required to coordinate the bandwidth negotiation process between the gateway 28 and the edge router 24 for each realtime and non-realtime traffic stream. Implementing the bandwidth control

003760 not the gateway eliminates this coordination problem. The details of how the bandwidth is managed from the gateway 28 are described next.

0038[0047] The description next refers to a single TCP connection, and then later-on multiple TCP connections are considered. A TCP sender, i.e. here the HTTP server 20, sends 'wnd' number of packets to the TCP receiver, i.e., here the gateway 28, within each round trip time ("/#") segment. The 'wnd' number of packets to be sent in each rtt segment is calculated as wnd - min {cwnd, fwnd}, which is the active window size. The TCP sender always maintains two variables or parameters called "cwnd" and "fwnd". The cwnd parameter represents a congestion control window and is computed by the TCP sender based upon the received acknowledgement and packet drops. The cwnd parameter is strictly controlled by the TCP sender. The fwnd parameter represents the flow control window and is set by the TCP receiver. [0048] The data rate ("b") for a TCP connection within a rtt segment

0039is given by b = . Considering the slow start phase in a given TCP rtt connection, if the connection starts at time f as measured by the sender's clock, the sender will transmit packets, at any time t > t° assuming no packet drops and given by: f(t) [Equation no. 1] <img file="EP1535130A2_D0001.tif" />

0040If packet drops are taken into consideration then more complex throughput formulas can be derived by known methods.

0041[0049] A "steady state" connection is one for which the number of packets transmitted is completely determined by the fwnd parameter. For a given connection to be in the steady state, value of the cwnd must be greater than the value of the fwnd parameter. In the steady state the TCP sender's output can be completely controlled by the TCP receiver and is shown by the above equation no. 1.

0042[0050] Gateway 28 controls the non-realtime traffic by manipulating the size of the flow control window fwnd,, which is located within the TCP sender at the other end. In the present illustration the non-realtime traffic, i.e., TCP traffic, should not exceed the 1 Mbps limit. If the maximum TCP segment size is 576 bytes, and the round trip time between the gateway 28 and the HTTP server 20 is 47 ms, which is obtained through simulation, then the gateway 28 sets the flow control window size, i.e., the value of the fwnd; to

0043- = 10 packets . Setting the value of fwnd; to 10 packets ensures

0044576*8b.t_? that regardless of the congestion window size, the maximum data rate of the TCP connection can never exceed 1 Mbps. [0051] Figure 5 shows a network configuration having multiple TCP connections and implementing bandwidth management. The configuration of the network shown is conceptually and structurally similar to that described in context of the figure 2 above. The network in figure 5 includes an additional TCP sender in the form of the FTP server 18 that transmits information requiring 1.5 Mbps bandwidth and has a delay of 20 ms. The bandwidth control 60 is used to manipulate the flow control from the gateway 28.

0045[0052] Figure 6 shows the average bandwidth of each stream along with the aggregate bandwidth of all streams, i.e., realtime and non-realtime combined. At time 0, the VoD server 12 starts pumping realtime CBR video at the rate of 1 Mbps. At time 1 second, a network user starts a FTP download from the FTP server 18. At around 3 seconds the network user starts a webpage download from the HTTP server 20. It is assumed that the webpage to be downloaded has multiple items like images and audio-clips to be downloaded as parts of the webpage. The web-browser (not shown) starts four simultaneous TCP connections, i.e., HTTP downloads 52_a, 52_b, 52_c, 52 , to download the webpage and the associated multiple items. The four HTTP downloads 52_a, 52_b, 52_c, 52 finish around 4.5 seconds, and the simulation is terminated at 5 seconds. [0053] VoD stream 50 clearly achieves a sustained 1 Mbps regardless of the number of active TCP connections. The bandwidth control 60 reduces the data rate for the FTP download 58 when the HTTP downloads 52 start around 2 seconds. Bandwidth control 60's reduction of the data rate ensures that the aggregate non-realtime traffic never exceeds the available 1 Mbps bandwidth for the non-real time traffic. Bandwidth control 60 adjusts the individual non-realtime data connections so that the realtime streams receive the guaranteed bandwidth sufficient to service its QoS requirements. Thus, the bandwidth control 60 adjusts the aggregate non-realtime bandwidth by manipulating the individual flow control windows on the several TCP senders. [0054] Bandwidth management technique using the principle of the present invention for multiple TCP connections is described next. To illustrate a set N of n non-realtime connections is considered. Each non-realtime connection is typically a HTTP or FTP connection. Let rtt,- be the estimate of the round-trip time of a given connection /^'. The rtt; is calculated as described next.

0046[0055] Gateway 28 makes an initial estimate of the time required to get an acknowledgement at the time of setting up the connection. Let R be the set of realtime streams and B,- be the bandwidth required by a given realtime stream / e R, where the streams in R require constant bit rate. The above described parameters n, i, rttj, B,- and the sets N and R are assumed to be functions of time and will be denoted as such, if necessary. [0056] The goal is to maximize the throughput b. = ^L for each rtt. connection, since the TCP sender / sends wnd,- = min {cwnd,, fwndj) . The throughput maximization is subject to the inequality given below: ^L ≤ B [Equation no. 2]

0047where,

0048<img file="EP1535130A2_D0002.tif" /> and where Be is the total capacity of the access segment 26.

0049[0057] If the connections are all identically important, then the steady state flow control window size for each /, subject to the equation no. 2 is given by the conservative bound as given by the equation below:

0050_. Bx rtt, βvndι = '- n

0051[0058] A static scheduling point is defined as a point in time at which either a new connection is established or an existing connection is terminated.

0052The static bandwidth allocation procedure or algorithm is as shown below: for each static scheduling point t do the following if the operation is a non-realtime connection-add then set n - n + 1 else if the operation is a non-realtime connection-drop then set n - n - 1 else // realtime add or drop re-calculate β as given by B = B_c - £ ,• teR endif for i = 1 to n

0053B Y. rtt, set fwnd ',- &lt;-

0054set the flow-control window to fwnd,- in the first acknowledgement sent to the sender of the connection / endfor endfor // END

0055[0059] Figure 7 is a graph showing performance characteristics of dynamic bandwidth management. The algorithm described in paragraph [0046] (hereafter called "the algorithm") can be further improved as described next. The algorithm works in a static manner and limits the aggregate non-realtime TCP traffic bandwidth for ensuring QoS guarantees for the realtime traffic. The algorithm is invariant with respect to the number of non-realtime connections. Further improvements to performance of the non-realtime connections and to the total channel utilization are possible by using dynamic rather than static bandwidth allocation. Dynamic bandwidth allocation techniques of the present invention are described next with an illustration.

0056[0060] To illustrate the improvement, the following table is used as an example:

0057<img file="EP1535130A2_D0003.tif" />

0058First we consider the algorithm operation. Initially there is only one TCP connection with a round-trip-time of 1 second. If the available capacity of the access segment 26 (see figure 5) is 16 packets/second then it is fully used by the first TCP connection since it is the only one. At the beginning of the second period another TCP connection arrives that has a round-trip-time of 1 second. According to the algorithm the available bandwidth is split among the first and second TCP connections with each connection getting 8 packets/second. However, the second TCP connection does not immediately start its share of 8 packets/second, because of the TCP slow start. The second TCP connection sends only 1 , 2 and 4 packets in periods 2, 3, and 4 respectively before reaching the steady state rate of 8 packets/second. The static bandwidth allocation does not compensate for the TCP slow start mechanism. Thus, with static bandwidth allocation implemented using the algorithm there remains the unused bandwidths of 7, 6 and 4 packets in the periods 2,3 and 4 respectively.

0059[0061] Considering the previous example, the first TCP connection will be allocated the unused bandwidth till the second TCP connection achieves a steady state. Therefore, the first TCP connection will send 15, 14 and 12 packets during the periods 2, 3 and 4 respectively. The second TCP connection reaches steady state in period 5, and then uses all of its allocated 8 packets and hence the first TCP connection also uses its allocated 8 packets.

0060[0062] Simulation of dynamic allocation of bandwidth using the bandwidth control 60 is shown. The network used to simulate the system is the same as shown in Figure 5. Only the bandwidths for the non-realtime streams HTTP download 52 and FTP download 58 are shown, because the realtime stream shows the same performance as in case of static bandwidth allocation. Both static and dynamic bandwidth control ensure that the QoS requirements of the realtime streams are met. Dynamic bandwidth allocation improves the throughput, and hence performs better than the static bandwidth allocation.

0061[0063] In the simulation shown there is only one opportunity around 3 seconds for the dynamic allocation to take effect. The FTP download with dynamic allocation 58_a is already in steady state when the four connections, i.e., HTTP downloads 52_a, 52_b, 52_c, 52_d, for the HTTP download 52 are started. In case of the static bandwidth allocation as shown by the algorithm, the bandwidth control will immediately distribute the available bandwidth among all the active connections. But in the case of dynamic allocation, the fact that the recently initiated four HTTP connections would be in a slow start mode is used to allocate the unused bandwidth available during the slow start of the HTTP download to the FTP download, which is already in a steady state. The FTP download performance is improved as seen by the shifting of the FTP download with dynamic allocation 58_a to the right around 3 seconds. The can be compared in the graph to the plot for FTP download without dynamic allocation 58b. Therefore the dynamic allocation improves the utilization of the aggregate available bandwidth. The data rate for the FTP connections is gradually reduced to the steady state rate as the HTTP download 52 reaches the steady state. Preceding is the description of the dynamic bandwidth management. Below is the further description of the above referred bandwidth control 60.

0062[0064] The bandwidth control 60 (see figure 5) can be designed to work with a dynamic bandwidth allocation algorithm instead of the algorithm described above. The dynamic bandwidth allocation method achieves improved performance by allocating the unused bandwidth to the TCP connection that is already in steady state.

0063[0065] A particular application of the present invention is described in the context of a home network user. All above figures are used to provide context the description of the invention in context of the home user. The home network user is typically connected to the Internet through a home gateway, which is a specific type of gateway 28. The user is connected to the other services like video-on-demand and IP telephony through the same home gateway. The home network 30 (see figure 1 ) that connects to the home or residential gateway can be connected to a wide variety of devices like computers, televisions, telephones, radios etc.

0064[0066] The above described problems bandwidth management are present in the home user scenario, because it would be difficult to implement bandwidth management techniques at the Internet service provider end. The home user would normally not have any control over the Internet service provider's mechanism of implementing TCP connections. Hence, it becomes necessary to implement bandwidth management at the residential or home gateway.

0065[0067] The principle of the present invention is used to incorporate a bandwidth control 60 into the home gateway. The operation of the bandwidth control is described above in detail. Above description applies equally to a home network user. In particular, the home user will be typically sharing the communication channel of access segment 60 for both realtime and non- realtime TCP traffic as the home user may find it expensive to use dedicated channels for realtime datastreams. Hence, the invention is beneficial to the home user using a shared channel for accessing realtime and non-realtime data.

0066[0068] The description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. Such variations are not to be regarded as a departure from the spirit and scope of the invention.