Patent Application
20140281018
The present invention relates generally to communications, and in specific embodiments, to dynamic optimization of communication protocol parameters.
The Transmission Control Protocol (TCP) is a core protocol corresponding to the transport layer of Internet Protocol (IP) suite, which serves as an intermediate layer between the application layer (e.g., the program) and the internet protocol (IP) layer. TCP provides reliable and ordered delivery of data from one program on one computer to another program on another computer, and is used by major Internet applications, e.g., browsing, email, file transfer, etc.
Modern day TCP algorithms are typically designed to address specific issues (e.g., congestion control, throughput, latency, fairness, quality of service (QoS), wireless compatibility, etc.), and consequently may perform better under some network conditions than others. For instance, a faster error recovery (FACK) TCP algorithm designed to effectively control congestion in wire-line networks may not perform well in wireless networks due to being unable to distinguish between congestion related packet loss (e.g., packets dropped from a buffer, etc.) and non-congestion related packet loss (e.g., packet not received correctly due to interference, packet corruption, etc.). Similarly, a detection of out-of-order (DOOR) TCP algorithm designed for efficiently handling re-ordered packets may be unable to efficiently maintain network objectives related to traffic priority, fairness, and/or Quality of Service.
Conventional networks implement a single/static TCP algorithm on a given piece of network equipment (e.g., a router, switch, server, etc.) such that all TCP connections constructed or operated by that piece of network equipment comply with a common set TCP parameters (as defined by the TCP algorithm configured on the device). As a result, conventional TCP networks may be incapable of adapting to constantly changing usage demands which may cause, inter alia, packet flows to cross different networking environments at different times.
Technical advantages are generally achieved, by embodiments of this disclosure which describe dynamic optimization of protocols such as TCP over network connections.
In accordance with an embodiment, a method for communicating data is provided. In this example, the method includes receiving a traffic flow and selecting transport control protocol (TCP) parameters for transporting the traffic flow in accordance with a characteristic of the traffic flow or a characteristic of a network. The method further includes transporting the traffic flow over a TCP connection configured in accordance with the selected TCP parameters. An apparatus for performing this method is also provided.
In accordance with another embodiment, another method for communicating data is provided. In this example, the method includes receiving a traffic flow, and beginning to transmit the traffic flow over a persistent transport control protocol (TCP) connection in accordance with default TCP parameters. The method further includes determining if a congestion or triggering condition is detected prior to completing transmission of the traffic flow over the persistent TCP connection. When the congestion/triggering condition is detected, the method includes ceasing transmission of the traffic flow over the persistent TCP connection, selecting congestion control parameters, and resuming transmission of remaining portions of the traffic flow in accordance with the selected congestion control parameters. When the congestion/triggering condition is not detected, the method further includes completing transmission of the traffic flow over the persistent TCP connection. An apparatus for performing this method is also provided.
In accordance with yet another embodiment, yet another method for communicating data is provided. In this example, the method includes receiving a first portion of a traffic flow carrying a data object or a request for a data object over a first one of a plurality of wide area network (WAN) interfaces, and buffering the first portion of the traffic flow until the entire traffic flow is received. The method further includes transmitting the traffic flow over a local area network (LAN) via a persistent transport control protocol (TCP) connection upon confirming that the entire traffic flow has been received. An apparatus for performing this method is also provided.
In accordance with yet another embodiment, another method for communicating data is provided. In this example, the method includes communicating data over a group of transport control protocol (TCP) connections, collecting collective connection statistics for the group of TCP connections while communicating data over the group of TCP connections, and updating TCP parameters for the group of TCP connections in accordance with the collective connection statistics. An apparatus for performing this method is also provided.
For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.
The making and using of embodiments of this disclosure are discussed in detail below. It should be appreciated, however, that the concepts disclosed herein can be embodied in a wide variety of specific contexts, and that the specific embodiments discussed herein are merely illustrative and do not serve to limit the scope of the claims. Further, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of this disclosure as defined by the appended claims. Aspects of this disclosure may be applied to various communication protocols. Notably, while much of this disclosure is discussed in the context of transmission control protocol (TCP), embodiments discussed herein may be applied to any communication protocol. Indeed, aspects of this disclosure may be particularly useful for protocols in which control/manipulation of communication parameters influences network performance.
The fundamental nature of the IP (which TCP is typically enveloped) is connectionless, which allows for dynamic re-routing of packets. Accordingly, TCP connections carried by IP can be moved to different network paths dynamically, which affects TCP connection latency, throughput, and other performance characteristics of the TCP connections
Disclosed herein are various techniques for dynamically optimizing TCP connections to achieve improved network performance. One aspect of this disclosure dynamically configures TCP connection parameters (e.g., parameters associated with; slow start, congestion avoidance, fast-retransmit, fast recovery, etc.) before usage or at start-up, e.g., prior to transporting a traffic flow over the network. More specifically, TCP connection parameters may be selected based on a traffic characteristic, a network characteristic, a history of traffic activity, expected loads, desired throughput and latency or some other characteristic. Once selected, the TCP parameters may be used to configure a new or select and modify an existing TCP connection for transporting the traffic. For instance, a new TCP connection may be constructed using the selected TCP parameters. Alternatively, an existing/persistent TCP connection may be reconfigured using the selected TCP parameters. As yet a further alternative, the selected TCP parameters may be used to select and/or modify a pre-configured persistent TCP connection from a pool of TCP connections.
Another aspect of this disclosure dynamically configures TCP parameters after beginning to transport traffic flows over the network. In such an embodiment, transportation of the traffic over the network may begin immediately using default TCP parameters, and unique or different TCP parameters may be selected only upon the occurrence of a condition (e.g., occurrence of a congestion condition, detection of a specific traffic pattern in packet arrivals or acknowledgements (ACKs), condition coupled with knowledge of past history, etc.). Immediately transporting the traffic may allow for quicker and/or more efficient handling of short flow data objects, such as Hypertext Transfer Protocol (HTTP) objects.
Yet another aspect of this disclosure allows multiple clients to share a set of persistent time-shared TCP connections. In one embodiment, client traffic flows are individually transported over a single time-shared TCP connection one at a time. In such embodiments, individual TCP connections carry no more than one client traffic flow at any given instance in time. In other embodiments, client traffic flows may collectively be transported over a group of TCP connections such that individual TCP connections carry multiple client traffic flows at the same time.
Time-sharing TCP connections may be particularly beneficial when an intermediate switching device (e.g., a middlebox, etc.) is switching traffic from a low speed network (e.g., a WAN) to a high speed network (e.g., a LAN). More specifically, WAN connections tend to have much longer round trip times (RTTs) than LAN TCP connections. As a result, traffic is typically received over WAN connections at a much lower rate than it is transmitted over LAN TCP connections. As an example,
Some aspects of this disclosure may be performed by a middlebox, which may be any switching device configured to dynamically transport TCP traffic over a network. In one example, a middlebox is a stand-alone component positioned between a client device and a source device (e.g., a server). In another embodiment, the middlebox is a module or component located on the client or source device. For instance, the middlebox may be implemented on a network interface card (NIC) on a communications device (e.g., computer, router, server, etc.).
TCP algorithms may operate by increasing/decreasing their transmission rate (e.g., window size) to manage or avoid congestion.
Conventionally, TCP parameters are statically defined by a TCP algorithm configured on the server. Indeed, as much as sixty percent of server processing capacity may be consumed by managing (e.g., constructing, destructing, etc.) TCP connections. Aspects of this disclosure offload at least some of the responsibility for managing TCP connections to a middlebox, which may be configured to dynamically configure TCP connection parameters based on various real-time characteristics.
In some embodiments, a single middlebox may be implemented on the server side of the network.
In other embodiments, middleboxes may be implemented on the client side as well as the server side.
Aspects of this disclosure dynamically configure TCP parameters in accordance with traffic and/or network characteristics. In some embodiments, TCP parameters may be dynamically configured when constructing a new/non-persistent TCP connection.
In one embodiment, TCP parameters are selected in accordance with a characteristic of the traffic and/or data object. The characteristic of the data object may include a size of the data object, a traffic type (e.g., isochronous traffic such as voice/video vs. common files) associated with the data object, a special handling instruction for the object, or some other characteristic. For instance a special handling instruction for the object may result from the detection of embedded indicator bits or a recognizable pattern that triggers policy decisions (e.g., decisions determining priority, Quality of Service (QoS), fairness, etc.).
In some embodiments, TCP parameters may be selected based on a historical characteristic associated with the traffic and/or data object. For instance, the historical characteristic may include a frequency in which the data object is communicated, a source of the data object, a historical variation in size of the data object. As an example, traffic patterns from past flows or a recurring group of flows (e.g., as recorded in a history table) may influence TCP parameter selection. For instance, historical traffic patterns may indicate the presence of wireless environments associated with particular IP address ranges or particular traffic types. Wireless network environments may bring about the following traffic patterns: (i) wide variations in RTTs; (ii) long RTTs; (iii) sudden drastic increase in RTTs (e.g., delay spike) (iv) out-of-order packets; (v) low throughput (e.g., less than 20 Mbps); and (vi) high retransmission rates; (vii) long disruptions (e.g., in the order of seconds); (viii) unpredictable error rates; (ix) clustered Losses (e.g., multiple packets lost during a short period window); and (x) losses correlated with frame sizes (e.g., longer frames mean more air time and increased likelihood of transmission environment corruption and packet loss). History tables may record various information about traffic flows, and may be sorted by origin address, traffic type, size of packets, congestion detected numbers, reordering counts, etc.
In some embodiments, TCP parameters are selected in accordance with a characteristic of a network, such as congestion frequency, network throughput, network latency, variations in latency and/or throughput, error statistics, etc. In one example, TCP parameters are selected based on network traffic environments between communicating TCP legs. For instance, short flows may be communicated more quickly by increasing the initial window size parameter and/or manipulating other TCP parameters. In an embodiment, each piece of a split connection may be individually optimized such that delay and throughput limitations of short flows are minimized or substantially eliminated for flows traversing split TCP connections. In an embodiment, managing data flows communicated between different speed and/or capacity RTT environments may allow for more efficient use of resources. In an embodiment, managing data flows between different RTT environments may allow a more efficient use of connection flows to persistent LAN or WAN connections. In an embodiment, managing data flows between different RTT environments may allow split TCP connections that carry the same traffic to communicate between TCP legs to share buffer storage or history knowledge.
After the TCP parameters are selected, the method 600 proceeds to step 630, where the switching device constructs a TCP connection in accordance with the selected TCP parameters. Subsequently, the method 600 proceeds to step 640, where the switching device transports the traffic flow over the TCP connection.
In other embodiments, TCP parameters may be dynamically configured by re-configuring TCP parameters of an existing/persistent TCP connection.
In some implementations, it may be desirable for a pool of users to share re-configurable/persistent TCP connections in a time-shared manner.
In some applications, it may be desirable to delay selection of the TCP parameters for a period of time. For instance, immediately transporting a traffic flow over an existing default TCP connection may decrease latency.
If the switching device determines that the triggering condition has occurred during the step 1130, the method 1100 proceeds to step 1150, where the triggering device selects TCP parameters for transporting the traffic flow. Next, the method 1100 proceeds to step 1160, where the switching device reconfigures an existing/persistent TCP connection, or alternatively, configures a new/non-persistent TCP connection, with the selected TCP parameters. Subsequently, the method 1100 proceeds to step 1170, where the switching device begins to transport the remainder of the traffic flow over the re-configured/newly-configured TCP connection. Subsequently, the method 1100 proceeds to step 1140, where the switching device determines whether or not transmission of the traffic flow is complete. If so, the method 1100 ends. Otherwise, the method 1100 reverts back to step 1130.
Traditionally, a node (such as the middlebox) would immediately begin forwarding packets in the server 1260 upon beginning to receive the sequence of packets over the TCP connection 1211. This traditional approach may unduly tie up bandwidth resources in the LAN 1250, as RTTs for the WAN 1210 may be much longer than RTTs for the LAN 1250. To with, the middle box 1220 may be capable of transmitting the packets over any of the TCP connections 1251-1255 at a much faster rate than that in which the packets are received over the TCP connection 1211. For example, if the middlebox 1220 transmitted the “START” packet over the TCP connection 1255 immediately upon beginning to receive the sequence of packets, then the TCP connection 1255 may be reserved while remaining packets in the sequence of packets (e.g., “MID” and “END”) are received over the TCP connection 1211.
Aspects of this disclosure avoid unnecessarily tying up resources in the LAN 1250 by deferring transportation of the “START” packet over the LAN 1250 until the entire sequence of packets has been received over the TCP connection 1211. The packets are then sent to the server 1260 in a single burst. Accumulating the WAN packets before sending them in a burst over the LAN has the added advantage to make sure that an entire request arrives and the user (individual or program entity) really wants the object, for example, a user didn't click off the object request (change the web page causing a connection reset or end) before asking the server to do processing to retrieve the object from its data store. More specifically, and as shown in
In addition to conserving bandwidth in the LAN 1250, delaying transportation of packets over the LAN 1250 until the entire sequence has been received over the WAN 1210 may allow the middle box 1220 to more effectively select TCP parameters for transporting the sequence of packets over the LAN 1250. For instance, the middle box 1220 may select one of the TCP connections 1253 based on a characteristic that is not known until the entire sequence of packets has been received, such as the size of the traffic, any traffic carried indicator flags or special bit sequences, etc. Additionally, the pool of available TCP connections 1251-1255 may change. In this example, the TCP connection 1253 was unavailable when the “START” packet was initially received (as shown in
In some embodiments, the time-shared TCP connections may be re-configured with selected TCP parameters.
In other embodiments, the time-shared TCP connections may be preconfigured with different TCP parameters, and the switching device may select one of the pre-configured TCP connections based on the characteristics of the data object and/or the characteristics of the network.
In aspects of this disclosure, multiple TCP connections may be managed collectively. For instance, a group of TCP connections may share a common set of TCP parameters such that the entire group of TCP connections can be managed collectively. Additionally, TCP parameters may be re-used when creating and/or reconfiguring TCP connections, thereby reducing delays in establishing/re-configuring TCP connections as well as conserving processing resources. The following are just a few examples of situations in which it may be beneficial to group TCP connections: (i) when connections are experiencing similar connection activity from shared origins; (ii) when connections have a shared ISP environment; (iii) when connections have a shared network element usage; (iv) when connections have a statically configured shared element usage; (v) when connections share a common IP address range; (vi) when connections have a shared service provider (e.g., a wireless provider, China Mobile, with well-known addresses); and (vii) when connections are experiencing activity from shared origins and/or destinations.
Although the description has been described in detail, it should be understood that various changes, substitutions and alterations can be made without departing from the spirit and scope of this disclosure as defined by the appended claims. Moreover, the scope of the disclosure is not intended to be limited to the particular embodiments described herein, as one of ordinary skill in the art will readily appreciate from this disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, may perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
