1. Field of the Invention
The invention relates to communication networks. In particular, the invention relates to an enhanced functionality of a transport layer protocol entity.
2. Description of the Related Art
The TCP (Transmission Control Protocol) is a set of rules (protocol) used along with the Internet Protocol (IP) to send data in the form of message units between computers over the Internet. While IP takes care of handling the actual delivery of the data, the TCP takes care of keeping track of the individual units of data (called segments, datagrams or packets) that a message is divided into for efficient routing through the Internet.
For example, when an HTML (Hyper Text Markup Language) file is sent to you from a Web server, the TCP program layer in that server divides the file into one or more packets, numbers the packets, and then forwards them individually to the IP program layer. Although each packet has the same destination IP address, it may get routed differently through the network. At the other end (the client program in your computer), the TCP reassembles the individual packets and waits until they have arrived to forward them to you as a single file.
The TCP is known as a connection-oriented protocol, which means that a connection is established (port is opened) and maintained until such time as the message or messages to be exchanged by the application programs at each end have been exchanged. The TCP is responsible for ensuring that a message is divided into the packets that IP manages and for reassembling the packets back into the complete message at the other end.
The TCP comprises four intertwined algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. The state variable (sstresh) determines whether the slow start or congestion avoidance algorithm is applied.
Slow start is an algorithm, which operates by observing that the rate at which new packets should be injected into the network is the rate at which the acknowledgments are returned by the other end.
Slow start takes an advantage of a window in the TCP, namely, the congestion window, called ‘cwnd’. When a new connection is established with a host on another network, the congestion window is initialized to one segment (i.e., the maximum segment size announced by the other end typically approximately 1500 bytes or the default, 536 or 512 bytes). Each time an acknowledgement message (ACK) is received, the congestion window is increased by one segment. The sender can transmit up to the minimum of the congestion window and the advertised window (the window size advertised by the receiver). The congestion window is flow control imposed by the sender, while the advertised window is flow control imposed by the receiver. The former is based on the sender's assessment of perceived network congestion; the latter is related to the amount of available buffer space at the receiver for this connection.
The sender starts by transmitting one segment and waiting for its ACK. When that ACK is received, the congestion window is incremented from one to two, and two segments can be sent. When each of those two segments is acknowledged, the congestion window is increased to four. This provides an exponential growth, although it is not exactly exponential because the receiver may delay its ACKs, typically sending one ACK for every two segments that it receives.
At some point the capacity of the Internet can be reached, and an intermediate router will start discarding packets. This tells the sender that its congestion window has gotten too large.
During congestion avoidance, cwnd is incremented by 1 full-sized segment per round-trip time (RTT). Congestion avoidance continues until congestion is detected. One formula commonly used to update cwnd during congestion avoidance is given by equation Cwnd+=SMSS*SMSS/cwnd. This adjustment is executed on every incoming non-duplicate ACK. The equation provides an acceptable approximation to the underlying principle of increasing cwnd by 1 full-sized segment per RTT.
Another acceptable way to increase cwnd during congestion avoidance is to count the number of bytes that have been acknowledged by ACKs for new data. A drawback of this implementation is that it requires maintaining an additional state variable. When the number of bytes acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS (Sender Maximum Segment Size) bytes. Note that during congestion avoidance, cwnd must not be increased by more than the larger of either 1 full-sized segment per RTT, or the value computed using the aforementioned equation.
When a TCP sender detects segment loss using the retransmission timer, the value of ssthresh (slow start threshold) must be set to no more than the value given in the following equation: ssthresh=max (FlightSize/2, 2*SMSS).
Furthermore, upon a timeout cwnd must be set to no more than the loss window, LW, which equals 1 full-sized segment (regardless of the value of IW (initial window)). Therefore, after retransmitting the dropped segment the TCP sender uses the slow start algorithm to increase the window from 1 full-sized segment to the new value of ssthresh, at which point congestion avoidance again takes over.
The TCP, however, includes a few unfavourable features. It is extremely scalable to different bit rates, but implicitly assumes “fat pipes” of large bandwidth*delay-products. The TCP implies high latency for the first segments and low link capacity (or flow capacity) in the early state of the traffic flow ramp-up. In the beginning of the communication flow, there are typically many small messages exchanged between client and server applications, such as registration, authentication and initiation messages which require delivery of segments before the data really is available. Trying to probe the network capacity by such determined messages is not truly data behavior and does not execute the slow start properly. Thus, when the data delivery starts, the slow start will begin. As the data amount may itself be small, it may happen that the slow start does not even have time to ramp up the link before the available data in the transmitter buffer is empty and after a pause for the next data burst, the slow start will begin again. This kind of path would unnecessarily be struggling always in the slow start.
Soon after the ramp-up, there is a possibility of radical fallback because of the congestion behavior or because of a packet loss in the wireless transmission. When the slow start is in the period of ramping up the link throughput, it may happen that a wireless link provides an erroneous packet (relying on the TCP to correct it) so that either the packet or the acknowledgement is missed. This causes the congestion avoidance to radically decrease the slow start threshold value and start with a slow start again.
A major disadvantage of the TCP is that it is completely unaware of the transmission bandwidth available on a path for a flow. TCP extensions improve performance over large bandwidth*delay product paths. TCP performance depends on the product of transfer rate and the round-trip delay. This bandwidth*delay product is the buffer space required at the sender and receiver to obtain maximum throughput. TCP performance problems arise when the bandwidth*delay product is large. This path is referred to as the “fat pipe”. Packet losses can have a catastrophic effect on the throughput, as it may cause the data pipe to drain with every packet loss and require a slow start.
When considering, for example, mobile radio links, the end-to-end path is typically a combination of a wireless radio bearer link (defined for moderate bit rate) with packet error probability and the path through routing network having a “fat pipe”. Thus probing the fat pipe is not possible, and probing the wireless part of the path is not efficient.
When mobile end-to-end applications are getting higher fraction of the traffic, paths of TCP flows are more determined by the radio link bandwidth configured for the radio bearer in the radio network and on the other hand by the terminal capabilities, than the routing network itself. Over the wireless radio interface probing of the TCP flow capacity is not necessarily favorable. For the end-to-end flow over several networks, anyway, it would be likely that it is the radio interface that determines the probing result of the TCP slow start and congestion algorithms.
Furthermore, the loss of packets due to congestion and due to packet errors in the wireless transmission are indistinguishable by the TCP. This is a drawback as the congestion and packet errors have very different origins and would require different actions.
FIG. 1 discloses one solution for determining a context in a mobile communications network. FIG. 1 discloses a plurality of different network elements between user equipment 10 and a server computer 18: a base station (BTS) 12, a radio network controller (RNC) 14, a serving GPRS support node (SGSN) 16, and a gateway GPRS support node (GGSN) 16. A set of different protocol stacks is used between the network elements. In order to send packets to external data networks, the user equipment 10 has to have a special address, that is, a Packet Data Protocol (PDP) address. Furthermore, a PDP context is created between the user equipment 10 and the gateway GPRS support node 16. The PDP context determines the type of the PDP, the PDP address, information on Quality of Service (QoS), and the address of the gateway GPRS support node 16. The PDP context is stored in the user equipment, serving GPRS support node, and gateway GPRS support node. The solution disclosed in Figure, however, does not provide an end-to-end solution between the user equipment 10 and an external data network entity.
Based on the above, there is an obvious need for a solution that would provide well-bounded and balanced operation during data transmission.