KR101231793B1 - Methods and apparatus for optimizing a tcp session for a wireless network - Google Patents

Abstract

The congestion window and the slow start threshold during a TCP session may be limited to the range defined by the minimum congestion window and the maximum congestion window based at least in part on the network type of the wireless network. The network type of the wireless network may be determined based at least in part on one or more round trip times of one or more data segments, wherein the one or more TCP sessions are set with corresponding storage session parameters associated with the network type.

Congestion Window, Slow Start Threshold, TCP Session, Wireless Network, Network Type

Description

TCP session optimization method and network node {METHODS AND APPARATUS FOR OPTIMIZING A TCP SESSION FOR A WIRELESS NETWORK}

This application claims the benefit of US Provisional Patent Application No. 60 / 630,895, filed November 24, 2004, the entire contents of which are incorporated herein by reference.

FIELD OF THE INVENTION The present invention generally relates to reliable end-to-end communications, and more particularly to optimizing a Transmission Control Protocol (TCP) session in a wireless network.

Packet-switched data networks are typically represented by a multi-layer protocol stack. Examples include a seven layer Open System Interface (OSI) model and a four layer transmission control protocol / Internet protocol (TCP / IP) model. The order from the top layer to the bottom layer in the OSI model is (1) application layer, (2) presentation layer, (3) session layer, (4) transport layer, (5) network layer, (6) data-link Layer, and (7) physical layer. The order from the top layer to the bottom layer in the TCP / IP model is (1) application layer, (2) transport layer (usually TCP), (3) Internet layer (usually IP), and (4) network access. Hierarchy. Although this is the most common model, not all TCP / IP implementations follow this model. Also, although the TCP / IP model does not follow the OSI model, the TCP / IP transport layer can be mapped to the OSI transport layer, and the TCP / IP Internet layer can be mapped to the OSI network layer.

The transport layer is responsible for dividing the data to be transmitted into segments of a size appropriate for transmission over the network. TCP is a transport layer protocol. The transport layer can provide reliability and congestion control processes that can be missed at the network layer. The network layer is responsible for routing data packets through the network. IP is a network layer protocol. The data-link layer manages the interface and device drivers needed to interface with the physical elements of the network. Examples of the data-link layer include the Ethernet protocol and the Radio Link Protocol (RLP). The physical layer consists of the physical parts of the network. Examples of physical layers include serial and parallel cables, Ethernet and token ring cabling, antennas, and connectors.

In a TCP / TP network, applications that need to send data to other computers deliver the data to the transport layer. In the transport layer, the data is divided into segments of appropriate size. These segments are then delivered to the network layer where they are packaged into datagrams containing the header information needed to transmit the segments throughout the network. At this point, the network layer invokes the lowest level protocols (eg, Ethernet or RLP) to manage the transfer of data across specific physical media. When datagrams are transferred from one network to another, these datagrams can be split again. In the receiving computer, the reverse process is performed. The lowest level protocols receive datagrams and forward them to the network layer. The network layer reassembles the datagrams into segments and delivers these segments to the transport layer. The transport layer reassembles these segments to deliver data to the application layer.

IP is limited only to providing sufficient functionality for delivering datagrams from source to destination, and does not provide reliable end-to-end connectivity or flow control. There is no guarantee that segments delivered to the network layer using IP will always arrive at their final destination. Segments may be received out of order at the receiving side, or packets may be missing due to network or receiving side congestion. This unreliability was intentionally built into IP to make the protocol simple but flexible.

TCP uses IP as its basic delivery service. TCP provides the reliability and flow control lost in IP. TCP / TP Specification 7 states that "there is very little hypothesis about the reliability of communication protocols below the TCP layer". TCP also provides a simple but potentially unreliable datagram service from a lower-level protocol such as IP. Obtainable ". To provide the reliability lost in IP, TCP uses the following tools. (1) sequence numbers that examine individual bytes of data and recombine them in order, (2) an ACK flag indicating whether some bytes have been lost in transit, and (3 A checksum that verifies the contents of the segment (Note: IP uses a checksum that verifies only the contents of the datagram header).

In addition, TCP provides flow control due to the fact that different computers and networks have different capabilities in terms of processor speed, memory, bandwidth, and the like. For example, a web enabled mobile phone will not be able to receive data at the same rate that a web server can provide. Therefore, TCP must ensure that the web server provides the data at a rate that the mobile phone can accept. The purpose of the flow control scheme in TCP is to prevent data from being lost due to too high transmission speeds, and to prevent insufficient use of network resources.

Most of the early TCP flow control mechanisms concentrated on the receiving side connection, which was supposed to be the cause of some congestion. One example of a receive-side flow control mechanism is Receive Window (RWND) sizing. The size of the RWND is known by the receiving side at the time of ACK that the receiving side transmits to the transmitting side. The size of the RWND is based on factors such as the size of the receiving buffer at the receiving side, and the frequency with which they are empty.

However, the flow control mechanism based on the receiving side does not solve the problem that may occur in the network. These problems can be network unavailability, traffic overload, and overflowing buffers for network routers. The receiving side may operate smoothly, but the network may drop packets because the sending side transmits data at a rate that is too high for the network to process. Thus, sender-based flow control methods have been developed. RFC 2581 details four flow control methods of TCP: (1) slow start, (2) congestion avoidance, (3) fast retransmission, and (4) fast recovery.

The four flow control methods are used to recover from and prevent congestion related problems. Which method is used depends on which congestion problems are encountered or which congestion problems are to be avoided. Slow start is used at the start of a connection to explore network capacity, or after the retransmission timer indicates that a segment has been lost. When a segment is sent or an ACK is received, the TCP sender estimates the round trip time of the next segment and calculates a retransmission timeout. When the next segment is sent, the retransmission timer for that segment starts with a new retransmission timeout value. If the time of the retransmission timer expires before the ACK for that segment is received, the segment is assumed to be lost. Congestion avoidance is used after a slow start has reached a predetermined threshold or after potential congestion has been detected by the reception of a duplicate ACK. Fast retransmission is used to retransmit a potentially lost packet before the retransmission timer indicates that the packet was lost. Fast recovery is used to prevent unnecessary data retransmission.

Despite the improvements provided by the flow control methods described above, it has been emphasized to increase the reliability of TCP connections at the expense of network performance. Accordingly, there is a need in the art to optimize TCP connectivity so that both reliability and performance are not compromised.

A method and apparatus for optimizing a Transmission Control Protocol (TCP) session in a wireless network is disclosed. In one embodiment, the method includes limiting a congestion window and a slow start threshold to a range defined by a minimum congestion window and a maximum congestion window, wherein the minimum congestion window and the maximum congestion window depend on the network type of the wireless network. At least in part.

Other aspects, features, and techniques of the present invention will become apparent to those skilled in the art upon reference to the following detailed description.

1 illustrates a simplified system diagram of a system that may implement one or more aspects of the present invention, in accordance with one or more embodiments of the present invention.

2 is a flow diagram illustrating a method in which a TCP module can limit a congestion window, in accordance with one or more embodiments of the present invention.

3 is a flow diagram illustrating how a TCP module may limit a slow start threshold, in accordance with one or more embodiments of the present invention.

4 is a flow diagram illustrating a method by which a TCP module can limit retransmission timeout, in accordance with one or more embodiments of the present invention.

5 is a flow diagram illustrating a method by which a TCP module can increase a congestion window during a TCP congestion avoidance phase, in accordance with one or more embodiments of the present invention.

6 is a flow diagram illustrating a modified TCP fast retransmission / fast recovery process, in accordance with one or more embodiments of the present invention.

7 is a flow diagram illustrating a modified TCP retransmission process upon timeout, in accordance with one or more embodiments of the present invention.

8 is a flow diagram illustrating a method in which a TCP module can determine a network type and set one or more TCP session parameters, in accordance with one or more embodiments of the present invention.

A method and apparatus are disclosed for optimizing a Transmission Control Protocol (TCP) session for a network node communicating over a wireless network. One aspect of the present invention is to modify the operation of a TCP session to match one or more TCP session parameters associated with a network type of a wireless network. Another aspect of the present invention is to provide a flexible method of determining a network type of a wireless network and setting one or more TCP session parameters to one or more corresponding stored session parameters associated with the network type.

In one embodiment, the congestion window and slow start threshold may be limited to a range defined by a minimum congestion window and a maximum congestion window based at least in part on the network type of the wireless network. In another embodiment, one or more TCP session parameters may be set to one or more corresponding stored session parameters based on the network type. The retransmission timeout may also be set to a value less than or equal to the maximum retransmission timeout based at least in part on the network type. In another embodiment, the congestion window may be increased by the congestion window increase rate during the TCP congestion avoidance phase based at least in part on the network type.

In accordance with the practice of a computer programming expert, the present invention is described below with reference to operations performed by a computer system or similar electronic system. These operations are sometimes referred to as being executed by a computer. Recognize that operations represented by symbols include manipulation by a processor, such as a central processing unit, for electrical signals representing data bits, as well as other processing of signals in addition to preservation of data bits in a memory region, such as in system memory. Will be. The memory region in which data bits are preserved is a physical region having specific electrical, magnetic, optical, or organic characteristics corresponding to the data bits. "Network node", "sending side", and "receiving side" described herein are understood to include any electronic device that includes a processor, such as a central processing unit.

Elements of the present invention, when implemented by software, are essentially code segments for performing a necessary task. The code segments may be stored in a processor readable medium or transmitted by a computer data signal carried on a carrier via a transmission medium or a communication link. "Processor readable medium" can include any medium that can store or transfer information. Examples of processor readable media include electronic circuitry, semiconductor memory devices, ROMs, flash memory or other nonvolatile memory, floppy diskettes, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, and the like. . The computer data signal may include any signal that can be propagated through a transmission medium such as an electronic network channel, an optical fiber, an air, an electromagnetic RF link, or the like. Code segments can be downloaded over a computer network, such as the Internet, an intranet, or the like.

1 illustrates an example system 100 that may implement one or more aspects of the present invention. System 100 is comprised of a transmitting side 110 in communication with a receiving side 140 via an optional data network 120 and a wireless network 130. Although the optional data network 120 is present in the embodiment shown in FIG. 1, it may be omitted in other embodiments.

The transmitting side 110 may be a network node adapted to create a TCP virtual circuit 160 for another device using a TCP module residing on the transmitting side 110. For example, sender 110 may be a desktop computer, laptop computer, cellular telephone, personal digital assistant (PDA), server, network adapter, or embedded computer. As the transmitting side 110, it should be recognized that the above listed are merely examples, as any device capable of creating a TCP virtual circuit 160 for another device may be considered. The TCP module may be part of a Transmission Control Protocol / Internet Protocol (TCP / IP) stack shared by two or more programs on the sender 110 or may exist as part of another program. In addition, it should be appreciated that the sending side 110, including the TCP module in accordance with the principles of the present invention, may further include other TCP modules not configured as such.

Receiving side 140 may be a network node adapted to generate a TCP virtual circuit 160 for another device using a TCP module residing on receiving side 140. For example, the receiving side 140 may be a desktop computer, laptop computer, cellular telephone, personal digital assistant (PDA), server, network adapter, or embedded computer. It should be appreciated that as the receiving side 140, those listed above are merely examples, as any device capable of creating a TCP virtual circuit 160 for another device may be considered. The TCP module may be part of a Transmission Control Protocol / Internet Protocol (TCP / IP) stack shared by two or more programs on the receiving side 140 or may exist as part of another software program. In addition, it should be appreciated that the receiving side 140, which includes a TCP module in accordance with the principles of the present invention, may further include other TCP modules not configured as such.

Although the units 110 and 140 shown in FIG. 1 are described as "sending side" and "receiving side," respectively, these terms are arbitrary and the transmitting side 110 may sometimes transmit data to the receiving side 140. FIG. On the other hand, it should be recognized that at some point the receiving side 140 may transmit data to the transmitting side 110.

In the embodiment of FIG. 1, TCP virtual circuit 160 exists between sender TCP endpoint 150 and receiver TCP endpoint 170. Details of the TCP virtual circuit are beyond the scope of the present invention, but in FIG. 1, although the underlying network protocol and networks are unreliable, a reliable TCP session and the accompanying flow control algorithm are transmitted to the sender 110 and the receiver ( As shown in FIG. It will be appreciated that two or more TCP virtual circuits 160 between the transmitting side 110 and the receiving side 140 may exist simultaneously.

The optional data network 120 may consist of a single network or multiple interconnected networks. Examples of networks that may constitute the optional data network 120 are the Internet, LAN, WAN, digital subscriber line (DSL) networks, cable networks, dial-up networks, cellular data networks, and satellite networks. These may be packet switched networks or circuit switched networks. The networks listed above that may constitute the optional data network 120 are merely exemplary and may use any network that can be connected to another network using one or more network layer protocols, such as the Internet Protocol (IP). It should be recognized.

Wireless network 130 may be comprised of at least one wireless physical layer, or a plurality of interconnected networks where at least one network comprises at least one wireless physical layer. The wireless network 130 includes a CDMA2000 1x (Code Division Multiple Access 2000 1x) network, a CDMA2000 1x EVDO (CDMA2000 1x Evolution Data Only) network, a General Packet Radio Services (GPRS) network, a Universal Mobile Telecommunications System (UMTS) network, a UTRAN (UTRAN) Cellular data networks such as Universal Terrestrial Radio Access Network (EDR) networks, and Enhanced Data for GSM Evolution (EDGE) networks. It should be appreciated that the networks listed above that may make up the wireless network 130 are merely exemplary and may use any network that may be connected to another network using one or more network layer protocols such as IP.

One or more TCP modules at the transmitting side 110 and / or receiving side 140 may be adapted to optimize the TCP session. In one embodiment, this adaptation introduces two new TCP session parameters, namely minimum CWND (min_CWND) and maximum CWND (max_CWND) to reduce the size of the congestion window CWND and slow start threshold (SSTHRESH). Includes limitations. Another adaptation may be to introduce another TCP session parameter, namely the maximum RTO (mx_RTO), to limit the size of the TCP retransmission timeout (RTO). Other adaptations may include other TCP session parameters such as CWND increase rate (speed_UP), CWND decrease rate (speed_DOWN) and RTO multiplier (RTO_MULT).

In certain embodiments, the TCP module may further include an adaptation based at least in part on the network type, including a modified TCP fast recovery process and a modified TCP retransmission process upon timeout.

One or more TCP session parameters and TCP processes may be based at least in part on the network type of wireless network 130. In one embodiment, one or more TCP session parameters may be programmed at the sending side 110 and / or receiving side 140 after being predetermined based at least in part on one or more characteristics relating to the network type. In certain embodiments, multiple sets of predetermined session parameters, each associated with a network type, may be pre-stored at the transmitting side 110 and / or receiving side 140. In these embodiments, the TCP module adapts to determine the network type of the wireless network 130 during the TCP session and to update one or more TCP session parameters with the corresponding session parameters included in the set of prestored session parameters associated with the network type. Can be.

In certain embodiments, the network type may be identified as "high bandwidth" and "low bandwidth." The terms "high bandwidth" and "low bandwidth" are relative and one network type may be considered to have "high bandwidth" compared to other network types, but as having "low bandwidth" compared to another network type. It should be understood that it may be considered. For example, in one embodiment, a CDMA2000 1x network may be considered to be a "low bandwidth" network type, while a CDMA2000 1x EVDO network may be considered to be a "high bandwidth" network type, which is a CDMA2000 1x EVDO network. This is because they typically have higher bandwidth, lower propagation delays, and lower queuing delays compared to CDMA2000 1x networks. Although CDMA2000 1x and CDMA2000 1x EVDO networks have been used to illustrate the concept of network types, it should be understood that other wireless networks may equally apply.

In other embodiments, there may be several network types, such as "highest bandwidth", "high bandwidth", "medium bandwidth", "low bandwidth", and "lowest bandwidth".

In one embodiment, the network type may refer to the current network characteristics of the wireless network 130. In these situations, the network type of wireless network 130 may change before, during, or after a TCP session, but the physical network remains the same. For example, the network type may change according to changes in bandwidth, propagation delay, packet loss, standby delay, and the like of the wireless network 130. This change may occur depending on conditions such as poor propagation quality, frequent handoff of the receiving side 140 from one base transceiver station (BTS) to another, or the distance between the receiving side 140 and the BTS. For example, if the receiving side 140 is close to the BTS, the network type of the wireless network 130 may be considered "high bandwidth." However, as the receiving side 140 moves further away from the BTS, the network type may change to "low bandwidth" because the latency between the receiving side 140 and the BTS may increase, resulting in increased latency and packet loss. Can be. In addition to environmental factors, changes in the traffic load on the wireless network 130 may also cause changes in the network type.

FIG. 2 may be used such that min_CWND and max_CWND limit CWND during a TCP session at a network node, which may be a sender (eg, sender 110) or a receiver (eg, receiver 140). Figure 1 illustrates an embodiment of a method. Process 200 begins upon update of CWND as shown in block 210. CWND can be updated using several methods during a TCP session. For example, during the slow start phase outlined in RFC 2583, CWND is increased by 1 each time a non-duplicate acknowledgment (NDACK) is received. During the congestion avoidance phase outlined in RFC 2583, CWND is increased by 1 for every CWND segment number acknowledged by one or more NDACKs. These examples do not limit the invention and are applicable to any update of CWND.

Process 200 proceeds to block 220 where CWND is compared to max_CWND. If CWND is greater than max_CWND, process 200 proceeds to block 230 where CWND is set to max_CWND. However, if CWND is less than max_CWND, process 200 proceeds to block 240.

At block 240, CWND is compared to min_CWND. If CWND is less than min_CWND, process 200 proceeds to block 250 where CWND is set to min_CWND. However, if CWND is greater than min_CWND, it remains unchanged.

An example of a CWND that may be restricted is an update of CWND that occurs after the TCP retransmission timer has timed out indicating that a packet was lost (ie, timeout). In some TCP implementations, CWND is reduced to a small value, typically between 1 and 4, after timeout. However, instead of decreasing the CWND to a value between 1 and 4, it may be reduced to the min_CWND value.

Another example where CWND can be restricted is the update of CWND during the congestion avoidance phase. In some TCP implementations, the CWND is updated by 1 for every CWND segment (or bytes if CWND is not represented as a segment) that is acknowledged (ACK). If CWND exceeds max_CWND during the congestion avoidance phase, it may be set to max_CWND.

The order of one or more acts shown in process 200 may be changed as long as it is consistent with the principles of the invention. For example, in some embodiments, CWND may be compared to min_CWND before comparing to max_CWND. Depending on the TCP process used to update CWND, it may only be necessary to compare CWND with max_CWND rather than min_CWND (for example, if CWND increases), and vice versa (for example, if CWND decreases) Case). In addition, the CWND may be limited by the size of the receiving window RWND on the receiving side.

3 illustrates one embodiment of how min_CWND and max_CWND can be used to limit SSTHRESH during a TCP session at a network node. Process 300 begins upon updating SSTHRESH as shown in block 310. SSTHRESH can be updated using several methods during a TCP session. For example, at startup some TCP implementations set SSTHRESH to the size of RWND. In another example, SSTHRESH may be reduced to a percentage of CWND during the TCP fast recovery phase. These examples do not limit the present invention and can be applied to any update of SSTHRESH.

Process 300 proceeds to block 320 where SSTHRESH is compared to max_CWND. If SSTHRESH is greater than max_CWND, process 300 proceeds to block 330 where SSTHRESH is set to max_CWND. However, if SSTHRESH is less than max_CWND, process 300 proceeds to block 340.

At block 340, SSTHRESH is compared to min_CWND. If SSTHRESH is less than min_CWND, process 300 proceeds to block 350 where SSTHRESH is set to min_CWND. However, if SSTHRESH is greater than min_CWND, it remains unchanged.

An example where SSTHRESH may be limited is an update of SSTHRESH that occurs after a timeout. In some TCP implementations, SSTHRESH is reduced to one half of the value of CWND after timeout. However, as a result of this decrease, when SSTHRESH becomes less than min_CWND, SSTHRESH may be set to min_CWND.

Another example where SSTHRESH can be restricted is when a TCP session is started. In some TCP implementations, SSTHRESH is set to any high value or RWND. However, if this any high value or RWND is higher than max_CWND, SSTHRESH may be set to max_CWND.

As in FIG. 2, the order of one or more actions shown in process 300 may be changed as long as it is consistent with the principles of the present invention. For example, in some embodiments, SSTHRESH may be compared to min_CWND before being compared to max_CWND. Depending on the TCP process used to update SSTHRESH, it may only be necessary to compare SSTHRESH with max_CWND rather than min_CWND (for example, when SSTHRESH increases), and vice versa (for example, where SSTHRESH decreases). Case). In addition, SSTHRESH may be limited by RWND.

4 illustrates one embodiment of how an RTO may be limited to a value less than or equal to max_RTO during a TCP session at a network node. Process 400 begins at block 410 where an RTO is determined for the next segment to be sent (or retransmitted). RTO can be determined in several ways during a TCP session. For example, the RTO may be determined by one method performed upon reception of the NDACK and another method performed when the retransmission timer expires.

Process 400 proceeds to block 420 where the RTO is compared to max_RTO. If RTO is greater than max_RTO, process 400 proceeds to block 430 where the RTO is set to max_RTO. However, if the RTO is less than max_RTO, it remains unchanged.

5 illustrates one embodiment of how SPEED_UP can be used to increase CWND during a congestion avoidance phase. This congestion avoidance phase is used during a TCP session after CWND reaches the value of SSTHRESH during the slow start phase, or after congestion is detected by receipt of a series of redundant ACKs (DACKs). In some TCP implementations, the CWND is increased by 1 during the congestion avoidance phase for all CWND segment numbers identified by the receiving side (in the form of NDACK). Note that some TCP implementations express CWND as the number of bytes rather than the number of segments. This process is similarly applicable to these implementations, but for simplicity the CWND is expressed here as the number of segments.

Process 500 begins at block 510 where a plurality of data segments are identified (ACK). Process 500 proceeds to block 520 where the CWND is increased by SPEED_UP. This is different from the conventional TCP implementation in that SPEED_UP is not limited to 1 and the plurality of data segments identified in block 510 is not limited to the number of CWND segments. In one embodiment, SPEED_UP may be adjustable, while in other embodiments it may be fixed. Note that CWND is still limited to max_CWND or less.

6 is a diagram illustrating one embodiment of a modified TCP fast retransmission / fast recovery process in accordance with the principles of the present invention. In standard TCP, upon receiving three consecutive DACKSs, TCP will enter a fast retransmission phase in which the segment associated with the DACK is retransmitted, assuming that the segment associated with the DACK is lost. "Fast retransmission" refers to retransmission of a segment before the timeout indicates a loss of the segment. After fast retransmission, TCP will enter a fast recovery phase where SSTHRESH and CWND are reduced to a percentage of CWND. In some TCP implementations the CWND is reduced to 1/2 + 3 of the CWND to reflect the three segments received at the client side causing the DACK.

After SSTHRESH and CWND are reduced, CWND may be temporarily increased to allow unacknowledged segments to be retransmitted until the lost segment is acknowledged (according to the RFC for TCP Reno). Linux TCP prevents this artificial increase by gradually reducing CWND after a fast retransmission. Linux TCP accomplishes this gradual reduction by decreasing the CWND by 1 for every two maximum segment sizes (MSS) of bytes identified as new NDACKs arriving after fast retransmission.

Process 600 begins at block 610, where a plurality of DACKs corresponding to data segments is received at the network node before the retransmission timer times out. In one embodiment, three DACKs may be required to enter the fast retransmission phase, and in another embodiment, any plurality of DACKs may be sufficient.

Process 600 proceeds to block 620 where the segment corresponding to the DACK is retransmitted. This is a standard TCP fast retransmission process. At block 630, process 600 deviates from standard TCP when SSTHRESH is reduced to a percentage of CWND. Unlike in other TCP implementations, the percentage used at block 630 may be based at least in part on the network type of the wireless network. In one embodiment, this percentage can be adjusted. For example, in one embodiment the percentage used at block 630 may be adjusted by the user of the network node. In other embodiments, it may be updated by the operator or software vendor of the wireless network. It should be understood that SSTHRESH is still limited by min_CWND and max_CWND.

After SSTHRESH is reduced, process 600 proceeds to block 640 where the TCP session resumes sending new segments. At block 650, process 600 waits for an event before proceeding to block 660 where CWND is decremented by one. In one embodiment, this event may be the passage of time expressed in clock periods, time units, or any other suitable timing parameter. In another embodiment, this event may be the reception of one or more NDACKs. For example, this event may be the reception of one or more NDACKs that ACK a new at least (100 / (100.X)) * MSS in bytes since this previous event, where X is at block 630. Is the size of the percentage used (eg, if SSTHRESH is reduced to 75% of CWND in block 630, X is 75 in block 660). It is to be understood that the foregoing examples are illustrative only and should not be considered as limiting the present invention. It should also be understood that the TCP module may still be sending new data segments in the background while waiting for an event to occur.

If the aforementioned event occurs, process 600 proceeds to block 660 where the CWND is reduced. In one embodiment, the reduction of CWND at block 660 may be 1, but in other embodiments this reduction may be another value. This value may be based at least in part on the network type of the wireless network.

Process 600 then proceeds to block 670 where the CWND is compared to SSTHRESH. If CWND is less than SSTHRESH, or in some embodiments equals SSTHRESH, process 600 proceeds to block 680 where TCP enters the congestion avoidance phase. If not, process 600 returns back to block 650 and waits for another event.

Figure 7 illustrates one embodiment of a modified TCP recovery process at timeout, in accordance with the principles of the present invention. In standard TCP, if a timeout occurs, TCP initiates a restore process upon timeout. In this process, the lost segment associated with the timed retransmission timer is retransmitted, SSTHRESH is reduced to a percentage of CWND (typically 50% of standard TCP), CWND is reduced to a value between 1 and 4, and TCP is slow start Resumes increasing CWND using the process. In addition, 2 is multiplied to the RTO for the lost segment according to an algorithm known as the Karn's algorithm.

The retransmission process 700 changed at timeout begins at block 710, indicating that a timeout occurs and the segment is lost. Process 700 proceeds to block 720 where a new segment is sent. This is a deviation from standard TCP, indicating that a lost segment is transmitted rather than a new segment. However, due to the fact that the network node is communicating over the wireless network, it is possible for the retransmission timer to time out without segment loss due to retransmission between the base station controller and the receiving side. Therefore, it may be appropriate to send a new segment. In one embodiment only new segments are transmitted, while in other embodiments new and lost segments may also be retransmitted. Determining whether to send a new segment may be based at least in part on the network type of the wireless network.

At block 730, the RTO is multiplied with RTO_MULT as opposed to specification 2 specified in the Khan algorithm. In one embodiment, RTO_MULT may be set to 1.5. In another embodiment, RTO_MULT may be set to another value. Note that the RTO is still limited by max_RTO.

At block 740, one or more unacknowledged segments are retransmitted, while standard TCP specifies that the entire remaining window of the unacknowledged segment should be retransmitted. In one embodiment, the remaining windows of the first two unacknowledged segments may be sent.

At block 750, SSTHRESH is reduced to a percentage of CWND instead of a standard TCP 50% reduction. This percentage can be adjusted by the user of the network node or by the wireless network operator or software vendor. Note that SSTHRESH is still limited by min_CWND.

8 illustrates one embodiment of a method in which a TCP module of a network node determines a network type of a wireless network during a TCP session and sets one or more session parameters to one or more corresponding stored session parameters associated with the network type. The TCP session parameter may include one or more of min_CWND, max_CWND, max_RTO, SPEED_UP, SPEED_DOWN, and RTO_MULT. In addition, one or more changes to the fast retransmission / fast recovery and retransmission process may be set at timeout.

Process 800 begins at block 810 where an NDACK is received by a TCP module at the transmitting side in response to a previously transmitted segment. The NDACK received at the transmitting side of block 1 may also be a delayed ACK, which term is known in the art.

Process 800 proceeds to block 820, where a round trip time (RTT) of at least one data segment associated with the received NDACK is determined. The RTT of the segment may be the time elapsed between transmission of the segment from the transmitting side and receipt of its corresponding NDACK, but any consistent method of determining the RTT of the segment may be used. This may be expressed in time units, clock periods, or any other suitable timing parameter.

After determining the RTT, process 800 proceeds to block 830 where the network type of the wireless network is determined. In one embodiment, this determination may be made by comparing the RTT determined at block 820 with one or more threshold RTTs. This comparison may be performed each time an RTT is determined, or may be done each time a predetermined number of RTTs are determined.

If the RTT falls within the area defined by one or more threshold RTTs, the network type may be determined to be the network type associated with that area. In one embodiment, there may be "high bandwidth" and "low bandwidth" corresponding to two available network types, ie, two areas defined by one or more threshold RTTs. If the RTT falls within the “low bandwidth” area, the network type may be considered to be low bandwidth. If the network type falls within the "high bandwidth," the network type may be considered to be high bandwidth. In other embodiments, it should be understood that more than one network type may exist.

In certain embodiments, in order to avoid having to determine the network type perceived by a fraudulently large or small RTT, a predetermined number of consecutive RTTs exceeding the RTT threshold may be used to determine the network type. have. For example, some number of RTTs may be required that exceed the RTT threshold since the last change of network type. In another embodiment, the average of the calculated RTTs may be used. This average may consist of the average of the RTTs determined after the start of the TCP session, the average of a certain number of RTTs, the average of the RTTs determined since the previous determination of the network type, or the average of the RTTs since the last change of the network type. Can be.

Referring again to FIG. 8, process 800 proceeds to block 840 where a determination is made as to whether the network type has changed (ie, if the network type determined at block 830, if present). A determination is made as to whether it differs from the last determined network type: If the network type has changed, process 800 proceeds to block 850, where one or more TCP session parameters may be set. In some embodiments, block 840 may be omitted, and process 800 may set one or more TCP session parameters each time after determining the network type.

At block 850, one or more TCP session parameters are set to one or more corresponding stored session parameters associated with the network type. In certain embodiments, there may be more than one storage session parameter set, where each set is associated with a different network type.

In one embodiment, one or more storage session parameters may be adjusted by a user of a network node comprising a TCP module consistent with the principles of the present invention. In other embodiments, one or more storage session parameters may be adjusted by another party. For example, one or more storage session parameters on the mobile phone may be adjusted over the cellular network by a cellular network operator or software vendor. One or more changes to the changed TCP fast retransmission / fast recovery and changed TCP recovery processes at timeout may likewise be adjusted.

In certain embodiments, it should be understood that the initial network type may be stored at the network node. At the start of a TCP session, this initial network type can be used to set one or more TCP session parameters before any segment is sent. For example, if the stored initial network type is "low bandwidth", one or more TCP session parameters may be set to one or more corresponding stored session parameters associated with the "low bandwidth" network type.

In one embodiment, if the network type changes during a TCP session, it may be necessary to increase or decrease CWND to fall within a new value between min_CWND and max_CWND. For example, if max_CWND is changed due to network type change and CWND is greater than max_CWND, CWND should be reduced to fall within the limits imposed by max_CWND. In one embodiment, the CWND may be reduced immediately after the network type is changed. In another embodiment, each time an event occurs after the network type is changed until the CWND becomes less than or equal to max_CWND, the CWND may be reduced by the number of SPEED_DOWN segments. This gradual decrease may be based on events such as passage of time or receipt of one or more NDACKs.

Similarly, if CWND is less than min_CWND due to network changes, CWND may increase immediately after a change in network type, or may increase gradually based on events such as the passage of time or the receipt of one or more NDACKs.

Although the processes of Figures 2-8 have been described in the foregoing embodiments, it should be appreciated that these are merely exemplary values and that other embodiments may be applied to the present invention. The order of one or more actions shown in the process of FIGS. 2-8 may be changed as long as it is consistent with the principles of the present invention. For the sake of clarity, it should be appreciated that the process of FIGS. 2-8 has been described in comprehensive steps and that other steps consistent with the principles of the invention may be included.

Although the present invention has been described with respect to the above embodiments, it will be appreciated that the present invention is capable of other variations. It is to be understood that this application is intended to cover all variations that conform to the principles of the invention, and that various modifications are possible without departing from the principles of the invention within the conventional practice known in the art.

Claims (34)

A method of optimizing a Transmission Control Protocol (TCP) session for network nodes that communicate over a wireless network. Limiting the congestion window and the slow start threshold to a range defined by a minimum congestion window and a maximum congestion window, The minimum congestion window and the maximum congestion window are based at least in part on a network type of the wireless network, When the retransmission timer expires, Sending a new data segment, the new data segment not previously transmitted; Multiplying the retransmission timeout; Reducing the slow start threshold to a percentage of the congestion window; And If receiving a non-duplicate acknowledgment, retransmitting one or more previously transmitted data segments, And wherein said at least one previously transmitted data segment is not associated with at least one previously received non-duplicate acknowledgment. The method of claim 1, Limiting the retransmission timeout to less than or equal to the maximum retransmission timeout; And wherein the maximum retransmission timeout is based at least in part on the network type of the wireless network. The method of claim 1, Receiving a plurality of non-duplicate acknowledgments during the TCP congestion avoidance phase, further including increasing the congestion window by a congestion window increase rate, The congestion window speed increase is based at least in part on the network type of the wireless network. delete The method of claim 1, Reducing the congestion window by a congestion window reduction rate once each time an event occurs until the congestion window is below the maximum congestion window, The event is one of receiving one or more non-duplicate acknowledgments or elapsed time. delete A method of optimizing TCP sessions for network nodes that communicate over a wireless network, Determining a network type of the wireless network based at least in part on at least one count trip time and at least one count trip time threshold, wherein the at least one trip trip time is associated with at least one data segment transmitted during the TCP session. The at least one round trip time threshold is associated with at least one network type; And Setting a plurality of TCP session parameters to a plurality of corresponding stored session parameters associated with the network type, The plurality of TCP session parameters include one or more of a minimum congestion window, a maximum congestion window, a maximum retransmission timeout, a congestion window increase rate, and a congestion window decrease rate; Limiting a slow start threshold to a range defined by the minimum congestion window and the maximum congestion window. delete delete delete The method of claim 7, wherein At least one of the plurality of corresponding stored session parameters is adjustable. delete The method of claim 7, wherein Limiting the congestion window to a range defined by the minimum congestion window and the maximum congestion window. delete The method of claim 7, wherein Increasing the congestion window by the congestion window increase rate upon receiving a plurality of non-duplicate acknowledgments during a TCP congestion avoidance phase. The method of claim 7, wherein Limiting a retransmission timeout for the TCP session to less than or equal to the maximum retransmission timeout. The method of claim 7, wherein Reducing the congestion window by a congestion window reduction rate once each time an event occurs until the congestion window is less than or equal to the maximum congestion window, the event further comprising receiving or time-lapsed receiving one or more non-duplicate acknowledgments. One of the methods of optimizing TCP sessions. As a network node, A network interface adapted to provide connectivity with a data network; A processor coupled to the network interface; And Memory coupled to the processor Wherein the memory causes the processor to: A processor executable instruction sequence that allows limiting the congestion window and the slow start threshold to a range defined by a minimum congestion window and a maximum congestion window, The minimum congestion window and the maximum congestion window are based at least in part on a network type of a wireless network, The memory causes the processor to expire when the retransmission timer expires; Send a new data segment, the new data segment not previously transmitted; Multiply the time of retransmission timeout by retransmission timeout multiplier, Reduce the slow start threshold to a percentage of the congestion window, Re-transmit one or more previously transmitted data segments upon receipt of a non-duplicate acknowledgment, wherein the one or more previously transmitted data segments are not associated with one or more previously received non-duplicate acknowledgments. A network node further comprising a sequence. 19. The method of claim 18, The memory further includes a processor executable instruction sequence that causes the processor to limit the retransmission timeout to less than or equal to the maximum retransmission timeout; And the maximum retransmission timeout is based at least in part on the network type of the wireless network. 19. The method of claim 18, The memory further includes a processor executable instruction sequence that causes the processor to increase the congestion window by a congestion window increase rate upon receipt of a plurality of non-duplicate acknowledgments during a TCP congestion avoidance phase; The congestion window increase rate is based at least in part on the network type of the wireless network. delete 19. The method of claim 18, The memory further includes a processor executable instruction sequence that causes the processor to reduce the congestion window by a congestion window reduction rate once each event occurs until the congestion window is below the maximum congestion window, The event is one of receiving or time-lapse of one or more non-duplicate acknowledgments. delete As a network node, A network interface adapted to provide connectivity with a data network; A processor coupled to the network interface; And Memory coupled to the processor Wherein the memory causes the processor to: Determine a network type of a wireless network based at least in part on at least one round trip time and at least one round trip time threshold, wherein the at least one round trip time is associated with a plurality of data segments transmitted during a TCP session; Round trip time threshold is associated with one or more network types ―, A processor executable instruction sequence for setting a plurality of TCP session parameters to a plurality of corresponding stored session parameters associated with the network type; The plurality of TCP session parameters include one or more of a minimum congestion window, a maximum congestion window, a maximum retransmission timeout, a congestion window increase rate, and a congestion window decrease rate; Wherein the memory further comprises a processor executable instruction sequence that causes the processor to limit a slow start threshold to a range defined by the minimum and maximum congestion windows. 25. The method of claim 24, The memory causes the processor to determine the network type if a value derived from the one or more round trip times, or the value derived from the one or more round trip times, is within at least some defined range by the one or more round trip time thresholds. Further comprising a processor executable instruction sequence for determining. 26. The method of claim 25, The network type is a low bandwidth network type when the one or more round trip times, or a value derived from the one or more round trip times, is greater than a low bandwidth round trip time threshold. 26. The method of claim 25, The network type is a high bandwidth network type when the one or more round trip times, or a value derived from the one or more round trip times, is less than a high bandwidth round trip time threshold. 25. The method of claim 24, At least one of said plurality of corresponding stored session parameters is adjustable. delete 25. The method of claim 24, And the memory further comprises a processor executable instruction sequence that causes the processor to confine a congestion window to a range defined by the minimum congestion window and the maximum congestion window. delete delete delete delete

Images