Patent Application
20080186851
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates in general to packet flow control and, in particular, to a system and method for dynamically controlling aggregate and individual packet flow characteristics within a compressed logical data tunnel.
Distributed networking environments, such as enterprise computing environments, generally consist of individual interconnected subnetworks. These subnetworks include intranetworks physically defined within a geographically limited area, such as within an office building, and internetworks, including the Internet, physically defined over a geographically distributed area using private and leased terrestrial lines and via satellite communications links.
Commonly, both intranetworks and internetworks operate in accordance with the ISO/OSI open interconnect model, an international network protocol definition, which specifies seven hierarchically-related network layers for use in digital data exchange. The Transmission Control Protocol/Internet Protocol (TCP/IP) standard defines a complementary layered network protocol, which simplifies the ISO/OSI interconnection model. TCP/IP is described in W. R. Stevens, “TCP/IP Illustrated, Vol. 1, The Protocols,” Chs. 1-3, Addison Wesley (1994), the disclosure of which is incorporated by reference.
TCP/IP is a layered network protocol framework and specifies media access, link, network, transport, and application protocol layers. The link and network layers define point-to-point protocols and the transport and application layers define end-to-end protocols. Applications executing within the application layer exchange packets containing source and destination addresses to identify originating and receiving hosts. The remaining network protocol layers facilitate the physical and logical transport of each packet.
The flow of packets can be controlled during transit to accommodate available network bandwidth and rate capabilities. A traffic manager can be co-located at a network domain boundary to monitor and analyze transient packet traffic for use in traffic analysis and flow control. Traffic managers primarily optimize throughput through bandwidth and rate control applied to internetwork connections, which are more costly yet slower than intranetwork connections.
Throughput optimization is particularly important in a high-traffic environment, such as a corporation, university, or Internet service provider. Unmanaged network traffic, particularly at the application network layer, hampers efficient throughput utilization and can result in bandwidth lost to non-core network traffic. Traffic managers can address application network layer throughput by prioritizing traffic according to user-specified network policies to ensure network availability for core network traffic needs.
Certain network protocols make throughput optimization difficult. The Transmission Control Protocol (TCP), for instance, provides end-to-end connectivity between origin and destination hosts. TCP is used by application layer protocols, such as the Hypertext Transport Protocol (HTTP), to exchange information between application programs. TCP is greedy and consumes available bandwidth. A TCP connection will initially send one packet, followed by two packets, and so on, to incrementally increase the packet rate until no further gains are realized. Unmanaged TCP connections can dominate traffic flow and monopolize available bandwidth.
Data compression can increase total utilization of bandwidth, but does not stop the greedy nature of TCP/IP connections. Data compression can be combined with rate control to meter the pace at which packet traffic flows over a network. Rate control helps to alleviate bottlenecks and controls greedy flows by managing per-flow bandwidth while data compression allows smaller packets to be sent, thereby conserving available network bandwidth. This marriage of the two functions allows per-flow and aggregate management of bandwidth with visibility into the effects of the compressions.
In the prior art, data compression has been used as the principal means to increase bandwidth utilization. However, prior art data compression solutions fail to control flow rates entering into a compressed stream of data and fail to provide means for changing or removing data compression midflow. In addition, when used in conjunction with non-integrated bandwidth management solutions, prior art data compression solutions are unable to completely utilize the bandwidth available on a datalink over which traffic is classified.
Therefore, there is a need for an approach to providing an integrated solution that provides packet flow management controlling both aggregate and per-flow bandwidth in concert with data compression to optimize the throughput and utilization of a datalink.
There is a further need for an approach to shaping packet traffic exchanged between end-to-end hosts. Preferably, such an approach would allow the traffic streams to be controlled collectively and individually.
There is a further need for an approach to providing flexible and granular data compression on per-flow, per-service and multiple shared-service bases. Preferably, such an approach would allow the form of data compression to be changed or eliminated midflow.
The present invention provides a system and method for managing incoming and outgoing packet traffic exchanged between logically-configured tunnel partners. The packet traffic is managed in a large-grained fashion by bandwidth limiting an aggregate of one or more packet flows transiting a logical data tunnel. Bandwidth limits are assigned to groups of packet flows and operate on compressed packet sizes. The packet traffic is managed in a fine-grained fashion by rate limiting individual packet flows within the logical data tunnel. Rate limits are provided through management of packet transmission based on uncompressed data sizes. The data compression is selected based on the service classification of each packet and is applied on a per-flow, per-service, or multiple shared-service basis. Since data compression is performed on a per-packet basis, the form of data compression used can be changed in midflow.
An embodiment provides a system and method for dynamically controlling aggregate and individual packet flow characteristics within a compressed logical data tunnel. A logical data tunnel is formed and includes one or more packet flows. Each packet flow includes individual packets having a shared destination address. Bandwidth allocated to control an aggregated flow of packets routed through the logical data tunnel. A transfer rate is assigned to control each packet flow transiting within the logical data tunnel.
A further embodiment provides a system and method for managing packet flow through a logical data tunnel formed between partnered traffic managers. Outgoing packets are sent to a partnered traffic manager via a logical data tunnel. The logical data tunnel includes one or more packet flows transiting to the partnered traffic manager. A packet rate of each packet flow through data compression is controlled. Each packet flow includes a substantially continuous stream of packets flowing to the partnered traffic manager. Bandwidth allocated to the packet flows in the logical data tunnel is limited by analyzing aggregated packet flows. Incoming packets from the partnered traffic manager are received via the logical data tunnel. The packet rate of each packet flow is controlled through an input queue transiently storing each incoming packet.
Still other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is described embodiments of the invention by way of illustrating the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.
To facilitate packet flow, a pair of partnered traffic managers 13 is communicatively interposed between the internet 16, the intranetwork 15, and the remote server 12. The traffic managers 13 work cooperatively to control dynamically aggregate and individual packet flow characteristics within a logically formed data tunnel, as further described below beginning with reference to
Other network topologies and configurations, as well as various combinations thereof, are feasible, as would be recognized by one skilled in the art. The individual computer systems, including servers and clients, are general purpose, programmed digital computing devices consisting of a central processing unit (CPU), random access memory (RAM), non-volatile secondary storage, such as a hard drive or CD ROM drive, network interfaces, and peripheral devices, including user interfacing means, such as a keyboard and display. Program code, including software programs and data, are loaded into the RAM for execution and processing by the CPU and results are generated for display, output, transmittal, or storage.
Bandwidth limiting allows the prioritization of aggregate collections of logically grouped packet flows 31 and is performed on the compressed sizes of packets flowing through the logical data tunnel 32, as further described below with reference to
Rate limiting is performed on the uncompressed sizes of packets in each packet flow 31. Each packet flow 31 has an actual bandwidth requirement 34a-e for an uncompressed state. In the described example, the cumulative bandwidth requirements 34a-e of the uncompressed set of packet flows 31 equals 140 Kbaud. A bandwidth limit 35 of 50 Kbaud requires at least a 3:1 data compression ratio. As necessary, individual uncompressed packets 36 are compressed into compressed packets 37. To optimize the throughput, the individual data flows 31 are compressed based on respective service types, as further described below with reference to
The analyzer module 73 analyzes packets transiting the traffic manager 13. The analyzer 73 inspects the destination address of each transient packet as queued into an inside (receive) packet queue 76 managed by a receive module 86. The inside packet queue 76 stages packets being received from and forwarded to an internal network domain.
The classifier module 74 classifies each transient packet by service type. Once classified, the transient packet is compressed by the compression module 75 based on the service type. A library of compression functions (not shown) is available to allow different compression function assignments on a per-flow, per-service and multiple shared-service basis. The compressed transient packets are queued into an outside (transmit) packet queue 77 managed by a transmit module 87. The outside packet queue 77 stages packets being received from and forwarded to an external network domain via the logical data tunnel 32.
The classifier module 74 classifies transient packets using a service compression configuration table 79. In the described embodiment, the compression function can be specified internally by the traffic manager 13, or as part of a user-supplied policy for specific service types. Table 1 shows, by way of example, a service compression configuration table 79:
Table 1 maps a classification service type to data compression function configuration. S1 through S8 represent service types. C1 through C3 represent data compression functions. Each compression type can have one or more starting dictionary, represented by Cx/n, where Cx is the compression function and n is the starting dictionary reference.
Aggregate type classifications are used to determine the compression function to use when encoding and decoding packet flows. There are three types of aggregate type classifications: per-flow (PF), per-service (A0) and multiple shared-service basis (A1 and A2). Per-flow aggregate type classifications use a unique data set and starting dictionary. Per-service aggregate type classifications share a common data set and starting dictionary for a particular service type. Shared aggregate type classifications share a common data set and starting dictionary for several service types. However, any one aggregate type classification can only have one assigned compression function and starting dictionary.
For completeness, network policies P1-P6 are assigned to the various service types. However, the assignment of network policies to service types is orthogonal to the type of compression function employed.
Once the classifier 74 determines the service type, the compression module 75 selects the appropriate compression function and determines the compression data reference and initial dictionary reference using a flow reference assignment table 80. The initial dictionaries 78 are used by the compression functions. Table 2 shows, by way of example, a flow reference assignment table 80:
Table 2 maps packet flows to reference identifier assignments using entries in the service compression configuration table, Table 1. The initial dictionary reference identifier identifies the starting dictionary by packet flow when encoding and decoding packets in the logical data tunnel 32 (shown in
The traffic manager 13 also maintains an index table 81, host database 82, and transmission schedule 83, as further described below with reference to
An example of a traffic manager 13 suitable for use in the present invention is the Packet Shaper product operating in conjunction with Packet Wise software, version 5.0.0, sold and licensed by Packeteer, Inc., of Cupertino, Calif. The traffic manager 13 looks at end-to-end traffic at the transport layer. However, the implementation of the current approach to identifying internal hosts can also be implemented by analyzing point-to-point traffic in the network layer, as long as the source and destination addresses of the transient packets remain visible.
Each module in the traffic manager 13 is a computer program, procedure or module written as source code in a conventional programming language, such as the C++ programming language, and is presented for execution by the CPU as object or byte code, as is known in the art. The various implementations of the source code and object and byte codes can be held on a computer-readable storage medium or embodied on a transmission medium in a carrier wave. The traffic manager 13 operates in accordance with a sequence of process steps, as further described below beginning with reference to
The method proceeds in two independent concurrent phases. During the first phase (blocks 101-112), packets are processed. During the second phase (blocks 113-116), packets are transmitted.
Each packet is processed in by the traffic manager 13 (block 101). If the packet is addressed to the traffic manager 13, that is, is self-addressed (block 102), and is inbound from the logical data tunnel 32 in compressed form (block 103), the packet is decoded (block 105), as further described below with reference to
If the packet is not addressed to the traffic manager 13 (block 102), the packet is first classified (block 107). If the packet classification indicates that compression is required, a compression index is determined (block 108), as further described below with reference to
Processed packets are queued into the transmit queue 77 for transmission by the transmit module 87 of the traffic manager 13. Each packet is removed from the transmit queue 87 (block 113) and transmitted (block 114). The bandwidth usage is then calculated and the aggregate domain compression predictor 53 is adjusted, as necessary (block 115). The method performs a clean up (block 116) and exits to complete the transmitting phase of the method.
First, the traffic manager determines whether the packet is being sent via a logical data tunnel 32 and, if so, whether the tunnel is set up and available (block 121). If the packet is not being sent through the tunnel (block 122), no encoding is necessary and the routine exits. Otherwise, a new packet buffer 84 (shown in
If the encoding is not efficient, that is, the encoding does not result in an appreciable decrease in packet size (block 125), the compressed packet length is set to the original packet length and the index is set to zero (block 126). Otherwise, if the encoding is efficient, the original and compressed packet lengths are saved in the packet buffer 84 (block 127) to be used later in adjusting the flow compression predictor 67 (shown in
First, the tunnel partner for the packet flow to which the packet belongs is determined (block 131), as further described below with reference to
The packet destination address is obtained (block 141) and the host corresponding to the destination address is looked up in a host database 82 (shown in
The original destination address and protocol of the IP header are saved (block 151). The data length and protocol in the IP header are changed to reflect the compressed length, if necessary, and use of compression, and the IP header checksum is recalculated (block 152). The IPCOMP header 92 is populated with the original destination address and protocol and the index for the packet buffer from the index table 81 (shown in
Each tunnel packet is received (block 161) and verified. If the packet is not valid (block 162), a flag indicating that the packet is to be reinjected back into the packet stream is set to FALSE (block 163) and the routine exits. Otherwise, the original destination address and protocol are restored to the IP header 91 from the IPCOMP header 92 (both shown in
The host corresponding to the source address of the decompressed packet is looked up in a host database 82 (shown in
First, bandwidth allocation for a given packet flow is determined (block 181), as further described below with reference to
The uncompressed aggregate flow allocation is retrieved based on the classification of the packet flow (block 191). The bandwidth per flow is calculated for the flows having the current service type in the allocation domain (block 192). The bandwidth allocation is inflated by the current flow compression predictor 67 (block 193) and the routine exits.
While the invention has been particularly shown and described as referenced to the embodiments thereof, those skilled in the art will understand that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention.
The present application is a divisional of U.S. application Ser. No. 10/112,577, filed Mar. 29, 2002, which is incorporated by reference herein for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10112577 | Mar 2002 | US |
| Child | 12032571 | US |
