Method for classifying persistent TCP flows

[0002] 1. Field of the Invention

[0003] This invention generally relates to the field of data communication systems. More particularly, the invention presents a novel method and apparatus for dynamically classifying and supporting network traffic, based on traffic characteristics. The scheme also provides support for accurate classification of persistent TCP traffic streams.

[0004] 2. Description of Related Art and General Background

[0005] The unprecedented growth of the Internet has not only increased the amount of traffic that communication networks must support, it has also transformed the nature of network traffic. The Internet was once relegated to handling Internet Protocol (IP)-based transmissions in the form of Telnet, e-mail, and File Transfer Protocol (FTP) traffic originating from wired LAN/WAN networks. Since then, the Internet has evolved into a global information infrastructure capable of accommodating a wide variety of applications and platforms.

[0006] Recent efforts have focused on the research and development of a Wireless Internet, capable of providing users with ubiquitous Internet access over wireless communication channels. Such efforts include, for example, developing standards for 3^rdgeneration wireless networks (3G) to facilitate Wireless Internet services. These services may accommodate IP-based applications over wireless media and would support applications as diverse as e-mail, web browsing, Voice-over-IP (VoIP), and audio/video-based applications.

[0007] FIG. 1A depicts a simplified block diagram of wireless communications network 100, capable of supporting Wireless Internet services. During reverse link transmissions, a mobile station (MS) 102 wirelessly communicates with a Wireless Access Network (WAN) 104 to transmit radio frames conveying IP-based traffic destined for application server 110. WAN 104 comprises, inter alia, a base station transceiver system (BTS) 104A, a base station (BS) 104B, and a network routing device 104C. BTS 104A receives the radio frames and routes them to BS 104B for processing, including converting the frames into IP packet data and applying radio resource management (RRM) functionality. BS 104B then forwards the IP packet data to network routing device 104C, which transmits the packets to application server 110 via a communications network 108, such as, for example, the Public Switched Telephone Network (PSTN) or the Internet.

[0008] The use of IP-based applications having real-time interactive requirements coupled with the relatively limited bandwidth capacity of wireless networks, precipitates the need to differentiate between the different traffic streams generated by these applications. For example, BS 104B and routing device 104C may need to apply delay and loss differentiation between the different packets transmitted from the wired network destined for MS 102. As such, BS 104B and routing device 104C may employ a classification mechanism 104D configured to classify certain types of traffic into a set of coarse traffic classes based on application requirements. The RRM functionality of BS 104B may then apply differentiated treatment to the different traffic classes.

[0009] One type of traffic generally found in IP-based networks is Transfer Control Protocol (TCP) traffic. As is well known, TCP is a connection-oriented protocol, which guarantees the delivery and sequential order of the transmitted data. Some classification schemes classify TCP traffic based on Layer-4 Port Numbers. Although relatively simple to implement, such classification may be easily deceived by users manipulating port numbers to achieve higher levels of priority for applications. Moreover, the use of port numbers in applications, although well-known, are not mandatory, thereby comprising the efficacy of the Layer-4 classification schemes. In addition, many networks employ Internet Protocol Security (IPSec) techniques, which provide for the secure exchange of packets, but do so at the expense of encrypting information above Layer-3 (Network Layer), thus rendering Layer-4 classification futile.

[0010] Other classification schemes classify TCP traffic based on Layer-7 (Application Layer) content. Such classification schemes exploit the payload information resident in the data packet to better identify the type of application associated with the traffic and overcomes the limitations of Layer-4 classification schemes noted above. However, Layer-7 classification schemes require a larger, more robust set of rules to operate effectively and is still subject to the classification barriers imposed by IPSec techniques.

[0011] Recent efforts, as described in Chapman et al., Automatic Quality of Service in IP Networks, PROC. CANADIAN CONF. ON BROADBAND RESEARCH, Ottawa, Canada (April 1997, pp. 184-189), have investigated the use dynamic stream classification schemes, which classifies streams based on traffic characteristics Dynamic stream classification schemes examine certain stream characteristics, such as, for example, transmitted packet counts and inter-arrival times, to determine the class associated with the traffic stream. The set of rules associated with dynamic stream classification schemes are, therefore, proportional to the number of classes in the classification scheme. As such, the rule set maintained by these schemes are smaller than the Layer-7 classification schemes. Moreover, because, dynamic stream classification schemes examine traffic stream behavior, such schemes may overcome the classification barriers imposed by IPSec techniques.

[0012] With this said, it is important to note that for some new applications, dynamic classification schemes may prove deficient. Consider, for example, HyperText Transfer Protocol (HTTP) 1.1, a newer protocol used by the World Wide Web to effect interactive transfers. HTTP 1.1 defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. One of the main features of HTTP 1.1 is the ability to support persistent TCP connections. Persistent TCP connections allow for the transfer of multiple transactions using a single TCP connection. Allowing multiple transactions over a single connection results in managing fewer connections, which enhances system performance. However, applying dynamic classification schemes to persistent TCP connections may result in classifying all transactions within the connections, irrespective of their characteristics, in the same manner, thereby compromising the efficacy and accuracy of the differentiated treatment of network traffic.

[0013] The present invention addresses the need identified above by providing a method and apparatus capable of dynamically and accurately classifying network traffic based on traffic characteristics.

[0014] Methods and apparatuses consistent with the principles of the present invention, as embodied and broadly described herein, include defining a first class to classify TCP data streams requiring interactive data transactions and a second class to classify TCP data streams requiring burst data transactions. The method establishes a rule set containing rules to define transitions between the defined classes and initializes an incoming TCP data stream as pertaining to one of the defined classes. Attributes of the TCP data stream are detected and, based on the detected attributes and the rules, the method dynamically classifies the TCP data stream into one of the defined classes. The method further includes forcing the classified TCP data stream to transition back to the initialized class in response to detecting that a data transaction has terminated or commenced.

[0015] By directing the classification of a TCP data stream (e.g., forcing the TCP classification back to the initialized class) based on detecting the termination or commencement of a data transaction, the present invention accurately classifies network traffic. Such classification is achieved regardless of whether the TCP data stream contains a single data transaction or a plurality of data transactions.

[0016] Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.

[0017] FIG. 1A depicts a simplified block diagram of wireless communications network.

[0018] FIG. 1B illustrates a simplified block diagram of a classification mechanism, in accordance with an embodiment of the present invention.

[0019] FIG. 2A depicts a functional state diagram for the accurate classification of TCP-based traffic, in accordance with an embodiment of the present invention.

[0020] FIG. 2B illustrates the operation of a heuristic rule, constructed and operative in accordance with an embodiment of the present invention.

[0021] FIG. 2C illustrates the operation of a heuristic rule, constructed and operative in accordance with another embodiment of the present invention.

[0022] FIG. 2D depicts the round trip time delay between a mobile station and a server.

[0023] FIG. 2E illustrates the operation of another heuristic rule, constructed and operative in accordance with another embodiment of the present invention.

[0024] FIG. 2F illustrates the HTTP data transfer operations between a mobile station and a server.

[0025] The following detailed description refers to the accompanying drawings that illustrate embodiments of the present invention. Other embodiments are possible and modifications may be made to the embodiments without departing from the spirit and scope of the invention. Therefore, the following detailed description is not meant to limit the invention. Rather the scope of the invention is defined by the appended claims.

[0026] The method and apparatus for dynamically classifying TCP-based traffic, as described herein, is capable of classifying network traffic based on application requirements as well as classifying individual transactions within persistent TCP connections. A plurality of classes are defined to classify TCP data streams having different application or transactional requirements. A rule set is established for transitioning between the defined classes. The TCP data streams are then classified dynamically based on the rule set and certain detected data stream attributes. In addition, the method forces the classified data stream back to an initial class, in response to detecting the termination or commencement of a transaction.

[0027] In one embodiment, the termination of a transaction is indicated by detecting a TCP data stream with packet inter-arrival time that is greater than a pre-specified time. In an alternative embodiment, the termination of a transaction is indicated by detecting a TCP data stream having a packet inter-arrival time that is greater than the round trip time of the stream. In another embodiment, the commencement of a transaction is indicated by monitoring the reverse TCP flow and detecting a TCP data stream message from a MS to a server that contains a payload size greater than zero.

[0028] FIG. 1B is a functional block diagram depicting classification mechanism 150, constructed and operative in accordance with an embodiment of the present invention. Mechanism 150 classifies network traffic based on certain classification schemes described below and comprises a stream manager mechanism 158, a packet classification rule engine 160, and rule set 162. Stream manager mechanism 158 may be configured to receive the incoming data packets as well as identify and track the traffic streams associated with the received packets.

[0029] Packet classification rule engine 160 performs actions to classify the received packets into their proper class in response to the information provided by stream manager mechanism 158 and rule set 162. Rule set 162 includes a plurality of rules designed to perform comparisons between observed traffic attributes and a pre-specified value, in accordance with the classification schemes presented below. As such, rule set 162 may include event indicia, indicating the triggering of a rule, condition indicia, representing a conditional or comparison statement, and action indicia, indicating the execution of an action based on the results of the comparison.

[0030] FIG. 2A depicts a TCP classification state diagram 200, constructed and operative in accordance with an embodiment of the present invention. Classification state diagram 200 provides an illustration of a dynamic classification scheme capable of classifying TCP traffic, including classifying individual transactions within persistent TCP connections. Such a scheme may be implemented by a classification mechanism 104D located in BS 104B and/or network routing device 104C, for example.

[0031] As indicated in FIG. 2A, classification state diagram 200 defines 3 classes of TCP traffic, Interactive Query Response (IQR) class 226, Burst class 228, and Bulk class 230. The traffic streams are initialized with a default class, such as, for example, IQR class 226. Upon detecting certain characteristics of the traffic streams (discussed below), classification state diagram 200 transitions into the appropriate class in order to classify the traffic streams. It is to be noted that other traffic classes are possible and in no way are the described embodiments limited to the classes identified above. As such, other traffic classes may be defined, for example, in accordance with the types of applications accommodated by a network and/or the differentiated treatment sought.

[0032] Interactive Query Response (IQR) class 226 represents traffic comprising a small number packets that need to be transmitted with high priority and little delay due to the interactive nature of the application (e.g., web-based e-commerce and Telnet traffic). Burst class 228 represents traffic comprising a medium number of packets that are transmitted in an infrequent and bursty manner (e.g., small HTTP and Post Office Protocol (POP3) traffic). Bulk class 230 represents traffic comprising a large number packets that are capable of tolerating delays due to large volume transfers (e.g., large Hypertext Markup Language (HTML) and File Transfer Protocol (FTP) traffic).

[0033] As indicated in FIG. 2A, the dynamic classification scheme defaults all new TCP traffic streams to IQR class 226, and then based on the observed traffic characteristics, the streams are classified into the appropriate classes. For example, in accordance with rule R₁, if at least X consecutive TCP packets having a size greater than or equal to LONG are detected, IQR class 226 transitions to Burst class 228. Such a rule may be implemented in order to adequately track and classify consecutive long packets having an occasional short packet for separation. Similarly, in accordance with rule R₂, if Y consecutive TCP packets having a size greater than or equal to LONG are detected, Burst class 228 transitions to Bulk class 230. The occurrence of consecutive long packets implies a train of packets with size larger than LONG. Such a traffic characteristic is reflective of either Burst class 228 or Bulk class 230 data transfer, where packet sizes are maximized as the applications tries to send all its data as fast as possible. The values for rule parameters X, Y, and LONG may be configurable. Possible values for these parameters may include: X=2-6 consecutive packets, Y=10-20 consecutive packets, LONG=512 bytes. It is to be noted, that the present invention is not limited to the specified values.

[0034] In order to accurately identify transactions occurring within persistent TCP connections, all three class states may be configured to transition back to IQR class 226 after each transaction is completed, or equivalently, at the commencement of a new transaction. Such transitions may be implemented by forcing transitions back to IQR class 226 in response to observing certain traffic characteristics stipulated by heuristic rules HR₁, HR₂, and HR₃. In addition, heuristic rules HR₁, HR₂, and HR₃may also be implemented to accommodate idle periods occurring in TCP connections.

[0035] It will be appreciated that, although each of heuristic rules HR₁, HR₂, and HR₃may be distinct, for the purposes of clarity, the embodiments disclosed heretofore will be described in terms of one heuristic rule. It will be understood that each of the embodiments may be used independently of each other or in different combinations in accordance with different traffic class configurations as applied to heuristic rules HR₁, HR₂, and HR₃.

[0036] FIG. 2B depicts the implementation of heuristic rule HR 250 based on maximum inter-arrival times, constructed and operative in accordance with an embodiment of the present invention. As indicated in FIG. 2B, HR 250 forces the transition of IQR class 226, Burst class 228, or Bulk class 230 back to IQR class 226, if the packet inter-arrival time for a corresponding traffic stream is greater than M. The value of inter-arrival parameter M is static and the arrival times of packets are easily detected. As such, the detection of prolonged inter-arrival times may indicate that a transaction within a persistent TCP connection has been completed or that the connection is idle. A typical value for inter-arrival M is 100 ms. It is to be noted, however, that the present invention is not limited to this specific value.

[0037] Because the value of inter-arrival parameter M is static, it may be susceptible to the dynamic fluctuations of network traffic. Thus, inter-arrival parameter M is selected in a manner that minimizes false transitions. For example, if the value of M is too small, it may incorrectly force traffic streams in the middle of transmitting a transaction back to IQR class 226. Conversely, if the value of M too large, it may not force traffic streams with smaller transmission delays back to IQR class 226 when transactions are completed.

[0038] In addition, HR 250 may not operate effectively in the case of persistent HTTP, where application server 110 is capable of supporting pipelined requests. For example, as will be described below, requests to initiate a transaction from a MS 102 to a server 110 i.e., GET requests) may appear back-to-back. The requests may be queued at server 110 and the responses to the requests may be issued in succession with little, if any, delay. These delays may be smaller than inter-arrival parameter M and, thus, the corresponding streams may not be forced back to IQR class 226 after the transactions corresponding to the responses are complete.

[0039] FIG. 2C depicts the implementation of heuristic rule HR 260 based on the maximum round trip time (RTT) for the traffic stream, constructed and operative in accordance with another embodiment of the present invention. As indicated in FIG. 2C, HR 260 forces the transition of IQR class 226, Burst class 228, or Bulk class 230 back to IQR class 226, if lapsed time N is greater than the RTT for a traffic stream. In particular, if no packets are detected from application server 110 for interval greater than the RTT, it is assumed that a new transaction has started.

[0040] Because the value of lapsed time parameter N depends on the RTT for a particular traffic stream, parameter N is dynamic. As such, HR 260 is not as susceptible to dynamic traffic fluctuations and is, therefore, more robust than HR 250, which implements a static value M.

[0041] The implication of HR 260 is that BS network routing device 104C has a way of estimating the RTT of a traffic stream. There are well-known techniques that estimate the RTT of a traffic stream based on correlating the forward and reverse-direction streams. As indicated in FIG. 2D, there are two possibilities for the RTT value for N. One possibility, is to consider the RTT between the BS network routing device 104C and application server 110 (RTT_A). The other possibility is to consider the RTT between server 110 and MS 102 (RTT_C).

[0042] Because the behavior of the traffic streams is governed by end-to-end flow control between server 110 and MS 102, HR 260 depends on the RTT between server 110 and MS 102 (i.e., RTT_C) and not between BS network routing device 104C and server 110 (i.e., RTT_A). At the BS 104B, the RTT_Cinformation is not available. Thus, BS 104B has to obtain an estimate for RTT_C, RTT′_Cvia the formula: RTT_C≈RTT_A+RTT_B, where RTT_Aand RTT_Bare obtained independently.

[0043] As noted above, using the RTT to dynamically adjust the value of N improves on the scheme based on the static value for M. However, recent studies have indicated the variability of RTT on the Internet. This variability is primarily due to fluctuations in router queue sizes. If the RTT variability is too high, HR 260 may be subject to false transitions.

[0044] Moreover, in the case of time-outs, BS network routing device 104C may observe delays larger than RTT and may transition back to IQR class 226. For example, if multiple consecutive packets are dropped, time-outs occur in order to retransmit the packets. Generally, the timeout interval is longer than RTT, thereby causing spurious state transitions. Such transitions may not be desired. In particular, if a particular traffic stream has been designated as pertaining to Bulk class 230, even though the traffic stream experiences a time-out, it may still be desirable to keep that flow in Bulk class 230.

[0045] Furthermore, much like HR 250, HR 260 may not operate effectively in the case of persistent HTTP, where application server 110 supports pipelined requests. In such a case, multiple GET requests may be queued at server 110 and responses may be issued sequentially without a sufficient RTT delay. Thus, the delays may be smaller than inter-arrival parameter N and the corresponding streams may not be forced back to IQR class 226 after the transactions corresponding to the responses are complete.

[0046] FIG. 2E depicts the implementation of heuristic rule HR 270 based on the Layer-4 payload size for the traffic stream, constructed and operative in accordance with another embodiment of the present invention. As indicated in FIG. 2E, HR 270 forces the transition of IQR class 226, Burst class 228, or Bulk class 230 back to IQR class 226, if it detects a MS 102 message request having a Layer-4 payload size greater than 0 for a particular traffic stream.

[0047] A sample data transfer for HTTP 1.1 is depicted in FIG. 2F. As indicated by reference character A, after a TCP connection is established (i.e., TCP handshaking process is complete), MS 102 transmits a GET request to server 110 to initiate a transaction. The GET request packet manifests a non-zero Layer-4 payload size. Server 110 responds to the GET request by transmitting a GET response along with data, as noted by reference character B. In turn, MS 102 acknowledges the transmitted data by responding with an ACK message, as indicated by reference character C. The ACK message packet has a 0 Layer-4 payload size. Server 110 transmits the rest of the data, as noted by D, to which MS 102 responds with another ACK message, noted by E. To initiate a subsequent transaction, MS 102 transmits another GET request to server 110, having a non-zero Layer-4 payload size, as indicated by reference character F.

[0048] HR 270 is based on the observation that, after the TCP handshaking process is complete, data transactions from server 110 to the MS 102 are initiated by non-zero Layer-4 payload size requests from MS 102, while non data-related messages from MS 102 have 0 Layer-4 payload size. As such, HR 270 exploits the fact that non-zero packets from MS 102 to server 110 mark the beginning of a new request and a new transaction, and thus the corresponding traffic stream should transition back to IQR class 226.

[0049] It will be appreciated that for simplicity, only data transfers from server 110 to MS 102 are illustrated in FIG. 2F. However, HR 270 may also be applied to data transfers from MS 102 to server 110, such as, for example, e-business transactions, where a client enters information on a form-based HTML page. In addition, HR 270 is capable of handling HTTP pipelining.

[0050] It is to be noted that, HR 270 assumes that there is no pipelining of GET requests. If GET requests pipelining is a requirement, HR 270 may be modified to track multiple GET requests and detect the corresponding ACK messages sequentially.

[0051] It will be apparent to one of ordinary skill in the art that the functionality described in connection with the embodiments as described herein may be implemented in many different embodiments of software, firmware, and hardware. The actual software code or specialized control hardware used to implement the present invention is not limiting of the present invention. Thus, the operation and behavior of the embodiments will be described without specific reference to the actual software code or specialized hardware components. The absence of such specific references is feasible because artisans of ordinary skill would be able to design software and control hardware to implement the embodiments of the present invention based on the description herein, without undue experimentation.

[0052] Moreover, the processes associated with the presented embodiments may be stored in any storage device, such as, for example, non-volatile memory, an optical disk, magnetic tape, or magnetic disk. Furthermore, the processes may be programmed when the system is manufactured or via a computer-readable medium at a later date. Such a medium may include any of the forms listed above with respect to storage devices and may further include, for example, a carrier wave modulated, or otherwise manipulated, to convey instructions that can be read, demodulated/decoded and executed by the system.

[0053] The foregoing description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments are possible, and the generic principles presented herein may be applied to other embodiments as well. For example, the invention may be implemented in part or in whole as a hard-wired circuit, as a circuit configuration fabricated into an application-specific integrated circuit, or as a firmware program loaded into non-volatile storage or a software program loaded from or into a data storage medium as machine-readable code, such code being instructions executable by an array of logic elements such as a microprocessor or other digital signal processing unit.

[0054] As such, the present invention is not intended to be limited to the embodiments shown above but rather is to be accorded the widest scope consistent with the principles and novel features disclosed in any fashion herein.