Handling high throughput and low latency network data packets in a traffic management device

Information

  • Patent Grant
  • 9313047
  • Patent Number
    9,313,047
  • Date Filed
    Friday, November 6, 2009
    14 years ago
  • Date Issued
    Tuesday, April 12, 2016
    8 years ago
Abstract
Handling network data packets classified as being high throughput and low latency with a network traffic management device is disclosed. Packets are received from a network and classified as high throughput or low latency based on packet characteristics or other factors. Low latency classified packets are generally processed immediately, such as upon receipt, while the low latency packet processing is strategically interrupted to enable processing coalesced high throughput classified packets in an optimized manner. The determination to cease processing low latency packets in favor of high throughput packets may be based on a number of factors, including whether a threshold number of high throughput classified packets are received or based on periodically polling a high throughput packet memory storage location.
Description
TECHNICAL FIELD

The technology generally relates to network traffic management, and more particularly, to handling communications among network applications involving the transfer of data in protocols with different throughput and latency characteristics.


BACKGROUND

The large number of network applications engaged in communications over various private and public networks (e.g., Internet) have imposed different demands on the network interface cards (“NICs”) employed by the network devices involved in handling those communications. NICs generally handle data sent to or from a network device, generating processor interrupts as data is received or needs to be transmitted. Since interrupts are computationally expensive because the network device processors must switch context, it is generally desirable to interrupt the processors only as needed. Some data transfer protocols, such as FTP, however, are high throughput in nature because large numbers of packets are transferred at a time without requiring a relatively high number of processor interrupts for applications handling the packets. In this case, many packets may be coalesced before interrupting the processor.


Other types of data transfer protocols are low latency in nature because more frequent processor interrupts are needed by applications handling the packets. For example, the NFS protocol requires the receipt of confirmatory acknowledgement messages before subsequent file portions can be transmitted. In this case, the file transfer performance depends on the request to acknowledgement processing time or latency. Thus for such low latency type data, the best performance is achieved by interrupting processors immediately upon the arrival of packets embodying the file portions, which as noted above, is the exact opposite for high throughput type data.


SUMMARY

An application delivery controller device is configured to manage network communications among one or more network applications operating on devices in a network. The application delivery controller device has one or more processors coupled to a memory and a network interface controller configured to receive, transmit and process network communication data packets. The application delivery controller device receives the data packets from the network to be processed by one of the processors in accordance with one or more traffic management applications executing on the processors. The data packets are stored in either a low latency packet queue or a high throughput packet queue in the memory coupled to the one or more processors of the device. The application delivery controller device processes the low latency classified packets until determining one or more high throughput classified packets are ready to be processed. The determination may be based on whether a threshold number of high throughput packets have been coalesced in the memory or periodically polling the memory to ascertain whether one or more high throughput packets are present. After processing the high throughput classified packets, the application delivery controller device resumes processing low latency classified packets.


This summary is intended to provide a brief introduction to some of the concepts covered in this disclosure. Additional aspects will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments, which is made with reference to the drawings, a brief description of which is provided below.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a diagram showing a network environment that may employ an application delivery controller capable of handling high throughput and low latency network data packets;



FIGS. 2 and 3 are diagrams of an example application delivery controller shown in FIG. 1; and



FIG. 4 is a flow chart of a process for handling high throughput and low latency network data packets that may be performed by the application delivery controller in FIGS. 2 and 3.





These examples may be practiced in many different forms without departing from the spirit and scope of the teachings in this disclosure. Therefore, it should be understood that the present disclosure should be considered an exemplification and is not limited to the example illustrations.


DETAILED DESCRIPTION

Referring to FIG. 1, an example system 100 includes one or more servers 102, one or more clients 106, and an application delivery controller device 110, which are coupled together by LAN 104 and network 108. While not shown, the system 100 may include additional network components, such as routers, switches and other devices. Generally, servers 102 process requests received from requesting clients 106 over LAN 104 and network 108 according to the HTTP-based application RFC protocol or the CIFS or NFS protocol in this example, but the principles discussed herein are not limited to this example and can include other application protocols. The application delivery controller device 110 is coupled to the server 102 through a local area network (LAN) 104 in this example, although the servers and controller may be coupled together via other topologies. The application delivery controller device 110 is also coupled to the client computers 106 through the network 108, for example, which may comprise any wide area network (e.g., Internet) or any other type of network topology. The client computers 106, in this example, may run interface applications such as Web browsers that may provide an interface to make requests for and send data to different web server based applications via the network 108. A series of applications may run on the servers 102 that allow the transmission of data that is requested by the client computers 106. The servers 102 may provide data or receive data in response to requests directed toward the respective applications on the servers 102 from the client computers 106. As per TCP, packets may be sent to the server 102 from the requesting client computers 106 to send data. It is to be understood that the servers 102 may be hardware or software or may represent a system with multiple servers 102, which may include internal or external networks. In this example the server 102 may be any version of Microsoft® IIS servers or Apache® servers, although other types of servers may be used. Further, additional servers may be coupled to the local area network 104 and many different types of applications may be available on servers coupled to the LAN 104.


As will be described in further detail below in connection with FIGS. 2-3, the application delivery controller device 110 may include a network interface controller (“NIC”) 200 to transmit and receive data packets from network 108 and the LAN 104. Various network processing applications, such as CIFS applications, NFS applications, HTTP Web Server applications, FTP applications, may be operating on servers 102 and transmitting data (e.g., files, Web pages) through the application delivery controller device 110 to clients 106 responsive to requests from those clients. It is to be understood that the NIC 200 may take the form of a network peripheral card that is installed inside a bus interface within application delivery controller device 110 or may be an embedded component as part of a computer processor motherboard, a router or printer interface, or a USB device that may be internal or external to the server 102.


In this example, the application delivery controller device 110 runs one or more traffic management applications on one or more host system processors 210 to manage network traffic by optimizing, securing and accelerating the traffic between clients 106 and servers 102, for example, although the controller device 110 may perform other network related functions, such as establishing virtual private networks. Moreover, the network traffic managed by the application delivery controller device 110 may be received and transmitted by the device 110 from and to the LAN 104 and network 108 in the form of network data packets in the TCP/IP protocol, although the network data packets could be in other network protocols.


Referring now to FIGS. 2-3, an example application delivery controller device 110 configured to handle both high throughput data packets and low latency data packets transmitted between clients 106 and servers 102 over LAN 104 and network 108 will now be described. In this example, the application delivery controller device 110 includes the NIC 200, host system I/O interface(s) 202, host system processors 210, and host system memory 218, which are coupled together by bus 208. Although the application delivery controller device 110 is shown in FIG. 1 in this example as being a standalone device, such as a BIG-IP® application delivery controller offered by F5 Networks, Inc., of Seattle, Wash., it should be appreciated that the device 110 could also be one of several blades servers coupled to a chassis device, such as a VIPRION® application delivery controller, also offered by F5 Networks, Inc., of Seattle, Wash.


NIC 200 may comprise specialized hardware to achieve maximum execution speeds, such a field programmable gate arrays (“FPGAs”), although other hardware and/or software may be used, such as ASICs, field programmable logic devices (“FPLDs”), programmable logic units (“PLUs”), software executed by the host system processor 210, and combinations thereof. The use of the specialized hardware in this example, however, allows the NIC 200 to rapidly respond to received packets and to rapidly classify packets as being low latency or high throughput, as will be described in further detail below.


The bus 208 is a hyper-transport bus in this example, although other bus types may be used, such as PCI. Host system input/output interfaces 202 include one or more keyboard/mouse interfaces, display devices interfaces, and other physical and/or logical mechanisms for enabling the controller 110 to communicate with the outside environment, which includes network 108, LAN 104 and users (e.g., administrators) desiring to interact with the controller 110, such as to configure, program or operate it.


Host system processor(s) 210 executes the traffic management applications 212 that handle the network traffic between applications on the clients 106 and servers 102 being managed by the controller device 110, as mentioned earlier, as well as one or more computer-executable instructions stored in the host system memory 218, as well as other operations as mentioned herein. The host system processor(s) 210 may comprise one or more central processing units (“CPUs”) or general purpose processors with one or more processing cores, such as AMD® processor(s), although other types of processor(s) could be used (e.g., Intel®).


Host system memory 218 may comprise one or more tangible storage media such as, for example, RAM, ROM, flash memory, CD-ROM, floppy disk, hard disk drive(s), solid state memory, DVD, or any other memory storage type or devices, including combinations thereof, which are known to those of ordinary skill in the art. Host system memory 218 stores the data packets received by NIC 200 in a packet buffer area 224, which is a non-contiguous memory storage space area, although contiguous memory may be used. Data packets classified by the classification module 230 (and/or the processor 210) are stored as low latency packets 229 and high throughput packets 228 in the packet buffer area 224 within memory 218. Further, the memory 218 includes a packet ring buffer indices area 226, which is a dedicated contiguous memory space that includes high throughput packet buffer index 234 and low latency packet buffer index 236, although other memory storage constructs could be used. Generally, the indices 234, 236 store an index to the location of the next low latency packet(s) 229 or high throughput packet 228 within the packet buffer area 224 to be processed by the processor(s) 210 the next time an interrupt is generated for processing either type of data in the form of a ring buffer, although other types of buffers may be used. As shown in FIG. 3, data packets 228 for high throughput and data packets 229 for low latency may be written in the packet buffer area 224. Although the packets 228 and 229 are shown written consecutively for convenience and ease of description in FIG. 3, it is to be understood that the packets 228 and 229 may be written in any order in any part of the packet buffer area 224.


Further, host system memory 218 also stores one or more computer-readable instructions that may be executed by the one or more host system processor(s) 210 and/or the NIC 200. When these stored instructions are executed, they may implement a process that is illustrated, for exemplary purposes only, by the flow chart diagram shown in FIG. 4. It should be appreciated that the flow chart diagram shown in FIG. 4 is representative of example steps or actions that may be embodied or expressed as one or more computer or machine readable instructions that may be executed by the NIC 200 and/or the processor(s) 210 in the application delivery controller device 110 shown in FIGS. 1-3. In this example, the machine readable instructions may embody an algorithm or computer program for execution by at least one of: (a) one or more processors each having one or more processor cores, (b) hardware specifically configured to perform the instructions (e.g., ASICs, FPGAs) and (c) one or more other suitable processing device(s). The algorithm or computer program may be embodied in software stored on host system memory 218, for example.


Moreover, persons of ordinary skill in the art will readily appreciate that the entire algorithm or computer program, and/or parts thereof, could alternatively be executed by a device other than a processor and/or embodied in firmware or dedicated hardware in a well-known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), discrete logic, etc.). For example, any or all of the components of the NIC 200, the application delivery controller device 110, or even the clients 106/server 102, could be implemented by software, hardware, and/or firmware (and combinations thereof). Further, although the example algorithm is described with reference to the flowchart illustrated in FIG. 4, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.


Packet switch fabric 214 includes one or more physical network ports (not shown), such as Ethernet ports, a host system bus interface 216, a classification logic module 230 and a configuration register 232. The NIC 200 accesses the memory 218 of the application delivery controller device 110 via one or more DMA transfer channels established to transfer packets 246. The packets 228 and 229 stored in the packet buffer area 224 of the memory 218 are indexed via either a high throughput queue 234 or a low latency queue 236 stored in the ring buffer area 226 in the memory 218. Incoming packets 228 or 229 may be written to the buffer area 224 by the NIC 200 for handling by the appropriate processor 210 in the application delivery controller device 110 when an interrupt is sent. A low latency pointer 252 or a high throughput pointer 254 to the location of the packet in the buffer area 224 is assigned to either the high throughput queue 234 or the low latency queue 236 in the ring buffer area 226. The queues 234 and 236 also store DMA descriptors of the packets.


As will be further explained, the NIC 200 may use the high throughput queue 234 and the low latency queue 236 to interrupt the processors 210 of the application delivery controller device 110 and direct one of the processors 210 to the location of a packet or packets in the buffer area 224 for the purpose of processing the incoming data packets depending on the type of data by sending the packets 244 to the respective applications 212 run by the host system processor(s) 210. The NIC 200 in the controller device 110 in this example may establish one or more DMA channels 246 over which to perform one or more DMA memory transfers to write data packets received by NIC 200 in the appropriate locations of the memory 218 in the application delivery controller device 110. The frequency of sending interrupts 240 to handle each of the respective queues 234 and 236 and the corresponding indexed packets in the buffer area 224 may be determined by setting the configuration register 232. The classification logic 230 may determine the type of data in incoming packets and therefore may assign the packet to one of the queues 234 or 236, which are in turn set for interrupt frequencies for either high throughput or low latency.


If the incoming packet includes data in a particular protocol that requires high throughput, such as the packets 228, the pointer or pointers 254 to the location of the packets 228 stored in the buffer area 224 may be added to the high throughput packet buffer queue or index 234. The high throughput packet queue 234 may be used with interrupt coalescing and therefore the NIC 200 allows numerous packets 228 to be stored in the buffer area 224 of the memory 218 before interrupting one or more of the host system processor(s) 210 to use the high throughput queue 234 for accessing multiple packets 228 from the buffer area 224. The intermittent interrupts 240 ensure the ability to maintain a high throughput through the NIC 200 since interrupts 240 are kept at a minimum, allowing one or more of the processor(s) 210 maximum uninterrupted processing of high throughput classified data packets. Alternatively, the high throughput queue 234 in memory 218 may be polled periodically by an application executing on one or more of the processors 210 to determine if pointers have been written in the queue, although logic in the NIC 200 could be configured to poll the memory 218 as well. In either case, the processor 210 handles the accumulated packets associated with the pointers in the high throughput queue 234.


Conversely, if the classification logic 230 determines the incoming packets require low latency, a low latency pointer 252 to the location of low latency packets 229 stored in the buffer area 224 may be added to the low latency packet buffer index or queue 236. The NIC 200 may be configured via the configuration register 232 to interrupt the processor(s) 210 immediately upon determining that a pointer 252 has been added to cause generating numerous interrupts 240 to use the low latency queue 236 for accessing the indexed packets 229, if so desired. Such a configuration would decrease the latency time for files that require multiple requests and acknowledgments to be sent for receiving the entirety of data.


One example of the classification logic 230 may classify the packets as high throughput or low latency according to the information in the packet header, such as information the logic 230 may use to either infer or directly identify the protocols that the packet data is in, since certain protocols are known to be low latency or high throughput in nature as mentioned previously, although a variety of other packet characteristics and methods may be used to classify the packets, such as using mappings maintained by the controller 110 between high throughput and low latency classifications with packets from particular data flows, for example. Alternatively, the classification logic 230 may classify packets as high throughput or low latency according to the data in the packet payload according to predefined rules for identifying certain data patterns, characteristics, or particular content, although the control 110 may be flexibly configured by a user of the controller 110, such as a network administrator, for example, to classify the packets based on any type of desired criteria.


Alternatively, a dedicated processor of the processors 210 on the application delivery controller device 110 may assist in processing packets received by the NIC 200. The dedicated processor is external to the NIC 200 and may perform various functions as described below. In this example, the NIC 200 receives the packets via the Ethernet link 206 and stores the packet in the buffer area 224 of the memory 218. The NIC 200 may pass the packet pointer to a high speed polling application 212 run by the dedicated processor 210 on the application delivery controller device 110. The high speed polling application 212 may determine whether the packet pointer should be assigned to the high throughput queue 234 or the low latency queue 236 and then adds the pointer to the appropriate queue 234 or 236 instead of the classification logic 230 in FIG. 3. As explained above, the NIC 200 then bases the interrupts 240 depending on the configuration of the queues 234 and 236 in order to maximize throughput or low latency periods for the data for the appropriate application 212.


Each of the server 102, application delivery controller device 110, and client computers 106 may include a central processing unit (CPU), controller or processor, a memory, and an interface system that are coupled together by a bus or other link, although other numbers and types of each of the components and other configurations and locations for the components can be used. The processors in the server 102, application delivery controller device 110, and client computers 106 may execute a program of stored instructions for one or more aspects of the methods and systems as described herein, including for efficient handling of different types of data, although the processor could execute other types of programmed instructions. The memory may store these programmed instructions for one or more aspects of the methods and systems as described herein, including the method for efficient handling of different types of data, although some or all of the programmed instructions could be stored and/or executed elsewhere. A variety of different types of memory storage devices, such as a random access memory (RAM) or a read only memory (ROM) in the system or a floppy disk, hard disk, CD ROM, DVD ROM, or other computer readable medium that is read from and/or written to by a magnetic, optical, or other reading and/or writing system that is coupled to the processor, may be used for the memory. The user input device may comprise a computer keyboard and a computer mouse, although other types and numbers of user input devices may be used. The display may comprise a computer display screen, such as a CRT or LCD screen by way of example only, although other types and numbers of displays could be used.


Although an example of the server 102, application delivery controller device 110, and client computers 106 are described and illustrated herein in connection with FIGS. 1-3, each of the computers of the system 100 could be implemented on any suitable computer system or computing device. It is to be understood that the example devices and systems of the system 100 are for exemplary purposes, as many variations of the specific hardware and software used to implement the system 100 are possible, as will be appreciated by those skilled in the relevant art(s).


Furthermore, each of the devices of the system 100 may be conveniently implemented using one or more general purpose computer systems, microprocessors, digital signal processors, micro-controllers, application specific integrated circuits (ASIC), programmable logic devices (PLD), field programmable logic devices (FPLD), field programmable gate arrays (FPGA) and the like, programmed according to the teachings as described and illustrated herein, as will be appreciated by those skilled in the computer, software, and networking arts.


In addition, two or more computing systems or devices may be substituted for any one of the systems in the system 100. Accordingly, principles and advantages of distributed processing, such as redundancy, replication, and the like, also can be implemented, as desired, to increase the robustness and performance of the devices and systems of the system 100. The system 100 may also be implemented on a computer system or systems that extend(s) across any network environment using any suitable interface mechanisms and communications technologies including, for example telecommunications in any suitable form (e.g., voice, modem, and the like), Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.


The operation of the example process to handle both high throughput and low latency data shown in FIG. 4 will now be described with reference back to FIGS. 1-3. In this example, one of network traffic management application(s) 212 executing on one of the processors 210 may be communicating with a first application, such as an NFS application, which may be transmitting data packets 244 classified by the classification module 230 as being low latency type data. Moreover, the network traffic management application 212, or another one of the traffic management application(s) 212, executing on the same or a different processor 210, may be communicating with a second application, such as an FTP application, which may be transmitting data packets 244 classified by the classification module 230 as being high throughput type data.


Referring now to FIG. 4, the process begins by the NIC 200 in application delivery controller device 110 receiving one or more network data packets from one or more of the servers 102 in the LAN 104, although the packets may be received from one or more of the clients 106 in the network 108 (400). In this example, the received packets may be in a TCP/IP protocol with a header and a payload, although the packets could be in other protocols. The classification logic 230 of the NIC 200 classifies the network data packets into at least one of high throughput classified packets and low latency classified packets based on one or more packet characteristics, which determines whether the received packet should be accessed by a processor for high throughput or low latency (402). The determination may be made based on the type of data determined through the packet header or even the data payload itself as mentioned above earlier. The determination may also be determined based on the application to receive the data or the application that sent the data. If the packet is determined to be of a high throughput type, the packet is written to the buffer area 224 of the memory 218 (404). The classification logic 230 may then write the index or pointer to the packet to the high throughput queue 234 in FIG. 2 (406).


A coalesce count is incremented after the pointer is written to the high throughput queue (408). The high throughput queue 234 is accessed by the NIC 200 according to the configuration register 232 to coalesce interrupts 240 sent to a processor, such as the host system processor(s) 210 of the application delivery controller 110 shown in FIG. 2. In this example, the NIC 200 may determine whether there are sufficient packets indexed in the queue 234 by determining if the coalesce count exceeds a threshold number (410). If there are insufficient numbers of packets, the process loops around for a next check period of receiving packets. If there are sufficient packets, the NIC 200 clears the coalesce count (412).


The NIC 200 then sends an interrupt to the appropriate processor such as the processor 210 (414). The processor 210 may receive the interrupt and access the appropriate locations of the buffer area 224 shown in FIG. 2 to receive the packets 228 (416). Since interrupts are relatively infrequent, a high throughput of data may be maintained to the processor 210, which may manage data for a high throughput application of the applications 212 in FIG. 3.


If the packet is determined to require low latency (402), the packet is written to the buffer area 224 of the memory 218 (418). The classification logic 230 then updates the low latency queue 236 (420) with the pointer to the area where the packet is stored. In this example, the NIC 200 is configured via the configuration register 232 to send an interrupt based on a new pointer written in the low latency queue 236 (422).


Since low latency classified data packets involve more frequent data accesses to process the packets for achieving low latency, the determination of whether to send an interrupt may be based on simply the arrival of a new packet written in the low latency queue 236. In this example, the NIC 200 may determine whether there is a new packet indexed in the queue 236. The NIC 200 sends an interrupt for a particular one of the processor(s) 210 to process the packet, although any available one of the processor(s) 210 could be directed to process the packet (422). The processor 210 may receive the interrupt and access the appropriate locations of the buffer area 224 shown in FIG. 3 to receive the packets 229 (424). Since interrupts 240 are relatively frequent, a low latency for data may be maintained to the processor 210, which may manage data for a low latency application of the applications 212 in FIG. 3. It is to be understood that the interrupts 240 may be coalesced for the low latency queue 236 after a small number of pointers have been written to the low latency queue 236 instead of after each pointer as explained above. Thus, the interrupt timing with respect to processing data packets classified as low latency and data packets classified as high latency will be different to optimize the efficiency of the processors 210.


Having thus described the basic concepts, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. For example, different non-TCP networks may be selected by a system administrator. Also, rather than having one device or server with different processors, a virtualized server where one guest operating system is running a low latency application and another guest operating system is running a high throughput application may be serviced via the network interface controller. The processes described herein may be applied to egress or ingress packets. In such a case, the host processor 210 of the application controller 110, after the application running on the processor 210 finishes processing a packet from the LAN 104, would notify the NIC 200 to let it know that it has buffered a packet into host memory 218 that is ready to be transmitted out to the network by the NIC 200 (and DMA transferred by the NIC from the host memory when it is ready to do so). The order that the measures are implemented may also be altered. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and scope of the examples. Additionally, the recited order of processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the disclose technology is limited only by the following claims and equivalents thereto.

Claims
  • 1. A method for processing network data packets destined for applications with a plurality of throughput and latency requirements, the method comprising: receiving by an application delivery controller apparatus data packets from a network;classifying by the application delivery controller apparatus the data packets as high throughput classified and low latency classified based on one or more characteristics of each of the data packets, wherein the low latency classified packets are processed by a first processor and the high throughput classified packets are processed by a second processor;storing by the application delivery controller apparatus the data packets in a respective one of a low latency packet queue or a high throughput packet queue based on the classification;processing by the application delivery controller apparatus low latency classified packets from the low latency packet queue;determining by the application delivery controller apparatus when a predetermined number of the data packets are stored in the high throughput packet queue; andwhen it is determined that the predetermined number of the data packets are stored in the high throughput packet queue: interrupting by the application delivery controller apparatus the processing of the low latency classified packets and processing one or more high throughput classified packets from the high throughput packet queue; andresuming by the application delivery controller apparatus the processing of the low latency classified packets upon processing a number of the high throughput classified packets.
  • 2. The method of claim 1, wherein the determining further comprises at least one of: polling a memory to determine whether the predetermined number of the data packets are stored in the high throughput packet queue; ordetermining when any other condition exists such that high throughput classified packets should be processed instead of low latency classified packets.
  • 3. The method of claim 1, further comprising interrupting by the application delivery controller apparatus a processor upon at least one of the classifying the data packets or the storing the data packets in the low latency packet queue.
  • 4. The method of claim 3, wherein there are fewer data packets stored in the low latency packet queue than the high throughput packet queue when the interrupting of the processing of the low latency classified packets occurs.
  • 5. The method of claim 1, wherein the receiving, classifying, storing, processing, determining, interrupting, and resuming steps are performed by a blade coupled to a chassis apparatus of the application delivery controller apparatus.
  • 6. The method of claim 1, wherein the one or more characteristics are selected by a network traffic management application executed by a processor.
  • 7. A non-transitory computer-readable medium having instructions stored thereon, which when executed by a processor of an application delivery controller device, causes the application delivery controller device to perform steps to and that comprise: receive data packets from a network;classify the data packets as high throughput classified and low latency classified based on one or more characteristics of each of the data packets, wherein the low latency classified packets are processed by a first processor and the high throughput classified packets are processed by a second processor;store the data packets in a respective one of a low latency packet queue or a high throughput packet queue based on the classification;process low latency classified packets from the low latency packet queue;determine when a predetermined number of the data packets are stored in the high throughput packet queue;when it is determined that the predetermined number of the data packets are stored in the high throughput packet queue: interrupt the processing of the low latency classified packets and processing one or more high throughput classified packets from the high throughput packet queue; andresume the processing of the low latency classified packets upon processing a number of the high throughput classified packets.
  • 8. The computer-readable medium of claim 7, wherein the determining further comprises at least one of: poll a memory to determine whether the predetermined number of the data packets are stored in the high throughput packet queue; ordetermine when any other condition exists such that high throughput classified packets should be processed instead of low latency classified packets.
  • 9. The computer-readable medium of claim 7, further comprises interrupt a processor upon at least one of the classifying the data packets or the storing the data packets in the low latency packet queue.
  • 10. The computer-readable medium of claim 9, wherein there are fewer data packets stored in the low latency packet queue than the high throughput packet queue when the interrupting of the processing of the low latency classified packets occurs.
  • 11. The computer-readable medium of claim 7, wherein the receiving, classifying, storing, processing, determining, interrupting, and resuming steps are performed by a blade coupled to a chassis apparatus of an application delivery controller device.
  • 12. The computer-readable medium of claim 7, wherein the one or more characteristics are selected by a network traffic management application executed by a processor.
  • 13. An application delivery controller apparatus comprising: one or more processors configured to be capable of executing one or more traffic management applications;a memory;a network interface controller coupled to the one or more processors and the memory and configured to be capable of receiving data packets from a network that relate to the one or more network traffic management applications; andat least one of the one or more processors or the network interface controller configured to execute programmed instructions stored in the memory to and that comprise: classify the data packets as high throughput classified and low latency classified based on one or more characteristics of each of the data packets, wherein the low latency classified packets are processed by a first processor and the high throughput classified packets are processed by a second processor;store the data packets in a respective one of a low latency packet queue or a high throughput packet queue in the memory based on the classification;process low latency classified packets from the low latency packet queue;determine when a predetermined number of the data packets are stored in the high throughput packet queue; andwhen it is determined that the predetermined number of the data packets are stored in the high throughput packet queue: interrupt the processing of the low latency classified packets and processing one or more high throughput classified packets from the high throughput packet queue; andresume processing the low latency classified packets upon processing a number of the high throughput classified packets.
  • 14. The apparatus of claim 13, wherein the determining further comprises at least one of: poll the memory to determine whether the predetermined number of the data packets are stored in the high throughput packet queue; ordetermine when any other condition exists such that high throughput classified packets should be processed instead of low latency classified packets.
  • 15. The apparatus of claim 13, wherein at least one of the one or more processors or the network interface controller is further configured to execute programmed instructions stored in the memory further to and that further comprises interrupt at least one of the one or more processors upon at least one of the classifying the data packets or the storing the data packets in the low latency packet queue.
  • 16. The apparatus of claim 15, wherein there are fewer data packets stored in the low latency packet queue than the high throughput packet queue when the interrupting of the processing of the low latency classified packets occurs.
  • 17. The apparatus of claim 13, wherein the network interface controller comprises at least one of a programmable logic device (PLD), a field programmable logic device (FPLD), a field programmable gate array (FPGA), stored executable instructions, or any other configurable logic.
  • 18. The apparatus of claim 13, wherein classifying the data packets further comprises: write a first pointer to a memory location of the data packets stored in the low latency packet queue into a first buffer index area in the memory; andwrite a second pointer to another memory location of the data packets stored in the high throughput packet queue into a second buffer index area in the memory.
  • 19. The apparatus of claim 13, wherein the application delivery controller apparatus comprises at least one of a blade coupled to an application delivery controller chassis device or a standalone application delivery controller device.
  • 20. The apparatus of claim 13, wherein the low latency classified packets are processed by a first processor and the high throughput classified packets are processed by a second processor.
  • 21. The apparatus of claim 13, wherein the one or more characteristics are selected by the one or more network traffic management applications.
US Referenced Citations (283)
Number Name Date Kind
3950735 Patel Apr 1976 A
4644532 George et al. Feb 1987 A
4897781 Chang et al. Jan 1990 A
4914650 Sriram Apr 1990 A
4965772 Daniel et al. Oct 1990 A
5023826 Patel Jun 1991 A
5053953 Patel Oct 1991 A
5299312 Rocco, Jr. Mar 1994 A
5327529 Fults et al. Jul 1994 A
5367635 Bauer et al. Nov 1994 A
5371852 Attanasio et al. Dec 1994 A
5388237 Sodos et al. Feb 1995 A
5406502 Haramaty et al. Apr 1995 A
5475857 Dally Dec 1995 A
5477541 White et al. Dec 1995 A
5517617 Sathaye et al. May 1996 A
5519694 Brewer et al. May 1996 A
5519778 Leighton et al. May 1996 A
5521591 Arora et al. May 1996 A
5528701 Aref Jun 1996 A
5581764 Fitzgerald et al. Dec 1996 A
5596742 Agarwal et al. Jan 1997 A
5606665 Yang et al. Feb 1997 A
5611049 Pitts Mar 1997 A
5663018 Cummings et al. Sep 1997 A
5699361 Ding et al. Dec 1997 A
5742765 Wong et al. Apr 1998 A
5752023 Choucri et al. May 1998 A
5761484 Agarwal et al. Jun 1998 A
5761534 Lundberg et al. Jun 1998 A
5768423 Aref et al. Jun 1998 A
5774660 Brendel et al. Jun 1998 A
5790554 Pitcher et al. Aug 1998 A
5797033 Ecclesine Aug 1998 A
5802052 Venkataraman Sep 1998 A
5812550 Sohn et al. Sep 1998 A
5825772 Dobbins et al. Oct 1998 A
5828835 Isfeld et al. Oct 1998 A
5875296 Shi et al. Feb 1999 A
5892914 Pitts Apr 1999 A
5892932 Kim Apr 1999 A
5919247 Van Hoff et al. Jul 1999 A
5936939 Des Jardins et al. Aug 1999 A
5941988 Bhagwat et al. Aug 1999 A
5946690 Pitts Aug 1999 A
5949885 Leighton Sep 1999 A
5951694 Choquier et al. Sep 1999 A
5959990 Frantz et al. Sep 1999 A
5974460 Maddalozzo, Jr. et al. Oct 1999 A
5983281 Ogle et al. Nov 1999 A
6006260 Barrick, Jr. et al. Dec 1999 A
6006264 Colby et al. Dec 1999 A
6026090 Benson et al. Feb 2000 A
6026443 Oskouy et al. Feb 2000 A
6026452 Pitts Feb 2000 A
6028857 Poor Feb 2000 A
6051169 Brown et al. Apr 2000 A
6070219 McAlpine et al. May 2000 A
6078956 Bryant et al. Jun 2000 A
6085234 Pitts et al. Jul 2000 A
6092196 Reiche Jul 2000 A
6108703 Leighton et al. Aug 2000 A
6111876 Frantz et al. Aug 2000 A
6115802 Tock et al. Sep 2000 A
6128279 O'Neil et al. Oct 2000 A
6128657 Okanoya et al. Oct 2000 A
6170022 Linville et al. Jan 2001 B1
6178423 Douceur et al. Jan 2001 B1
6182139 Brendel Jan 2001 B1
6192051 Lipman et al. Feb 2001 B1
6233612 Fruchtman et al. May 2001 B1
6246684 Chapman et al. Jun 2001 B1
6253226 Chidambaran et al. Jun 2001 B1
6253230 Couland et al. Jun 2001 B1
6263368 Martin Jul 2001 B1
6298380 Coile et al. Oct 2001 B1
6327622 Jindal et al. Dec 2001 B1
6343324 Hubis et al. Jan 2002 B1
6347337 Shah et al. Feb 2002 B1
6347339 Morris et al. Feb 2002 B1
6360270 Cherkasova et al. Mar 2002 B1
6374300 Masters Apr 2002 B2
6388989 Malhotra May 2002 B1
6396833 Zhang et al. May 2002 B1
6411986 Susai et al. Jun 2002 B1
6484261 Wiegel Nov 2002 B1
6490624 Sampson et al. Dec 2002 B1
6510135 Almulhem et al. Jan 2003 B1
6519643 Foulkes et al. Feb 2003 B1
6529508 Li et al. Mar 2003 B1
6574220 Petty Jun 2003 B1
6601084 Bhaskaran et al. Jul 2003 B1
6636503 Shiran et al. Oct 2003 B1
6636894 Short et al. Oct 2003 B1
6650640 Muller et al. Nov 2003 B1
6650641 Albert et al. Nov 2003 B1
6654701 Hatley Nov 2003 B2
6691165 Bruck et al. Feb 2004 B1
6700871 Harper et al. Mar 2004 B1
6708187 Shanumgam et al. Mar 2004 B1
6742045 Albert et al. May 2004 B1
6748457 Fallon et al. Jun 2004 B2
6751663 Farrell et al. Jun 2004 B1
6754228 Ludwig Jun 2004 B1
6760775 Anerousis et al. Jul 2004 B1
6772219 Shobatake Aug 2004 B1
6779039 Bommareddy et al. Aug 2004 B1
6781986 Sabaa et al. Aug 2004 B1
6781990 Puri et al. Aug 2004 B1
6785236 Lo et al. Aug 2004 B1
6798777 Ferguson et al. Sep 2004 B1
6816901 Sitaraman et al. Nov 2004 B1
6820133 Grove et al. Nov 2004 B1
6829238 Tokuyo et al. Dec 2004 B2
6868082 Allen, Jr. et al. Mar 2005 B1
6876629 Beshai et al. Apr 2005 B2
6876654 Hegde Apr 2005 B1
6888836 Cherkasova May 2005 B1
6904040 Salapura et al. Jun 2005 B2
6928082 Liu et al. Aug 2005 B2
6934776 Connor et al. Aug 2005 B2
6950434 Viswanath et al. Sep 2005 B1
6954780 Susai et al. Oct 2005 B2
6957272 Tallegas et al. Oct 2005 B2
6975592 Seddigh et al. Dec 2005 B1
6999457 Shinohara Feb 2006 B2
7007092 Peiffer Feb 2006 B2
7046628 Luhmann et al. May 2006 B2
7065630 Ledebohm et al. Jun 2006 B1
7107348 Shimada et al. Sep 2006 B2
7117308 Mitten et al. Oct 2006 B1
7124196 Hooper Oct 2006 B2
7139792 Mishra et al. Nov 2006 B1
7142540 Hendel et al. Nov 2006 B2
7164678 Connor Jan 2007 B2
7174393 Boucher et al. Feb 2007 B2
7236491 Tsao et al. Jun 2007 B2
7272150 Bly et al. Sep 2007 B2
7281030 Davis Oct 2007 B1
7321926 Zhang et al. Jan 2008 B1
7324525 Fuhs et al. Jan 2008 B2
7327674 Eberle et al. Feb 2008 B2
7343413 Gilde et al. Mar 2008 B2
7349391 Ben-Dor et al. Mar 2008 B2
7349405 Deforche Mar 2008 B2
7353326 Cho et al. Apr 2008 B2
7355977 Li Apr 2008 B1
7359321 Sindhu et al. Apr 2008 B1
7376772 Fallon May 2008 B2
7403542 Thompson Jul 2008 B1
7411957 Stacy et al. Aug 2008 B2
7415034 Muller et al. Aug 2008 B2
7420931 Nanda et al. Sep 2008 B2
7457313 Patrick Nov 2008 B2
7475122 Azpitarte Jan 2009 B2
7478186 Onufryk et al. Jan 2009 B1
7490162 Masters Feb 2009 B1
7493398 Bush Feb 2009 B2
7496689 Sharp et al. Feb 2009 B2
7496695 Go et al. Feb 2009 B2
7500028 Yamagishi Mar 2009 B2
7512078 Swain Mar 2009 B2
7512721 Olson Mar 2009 B1
7533197 Leonard et al. May 2009 B2
7552232 Helmer, Jr. et al. Jun 2009 B2
7558197 Sindhu et al. Jul 2009 B1
7558910 Alverson et al. Jul 2009 B2
7571299 Loeb Aug 2009 B2
7590753 Wolde et al. Sep 2009 B2
7620046 Ronciak et al. Nov 2009 B2
7620071 Makineni et al. Nov 2009 B2
7621162 Bartky Nov 2009 B2
7647416 Chiang et al. Jan 2010 B2
7657659 Lambeth et al. Feb 2010 B1
7660916 Moskalev et al. Feb 2010 B2
7668727 Mitchell et al. Feb 2010 B2
7668851 Triplett Feb 2010 B2
7680915 Still et al. Mar 2010 B2
7710989 Chew May 2010 B2
7729239 Aronov et al. Jun 2010 B1
7734809 Joshi et al. Jun 2010 B2
7735099 Micalizzi, Jr. Jun 2010 B1
7742412 Medina Jun 2010 B1
7784093 Deng et al. Aug 2010 B2
7813277 Okholm et al. Oct 2010 B2
7826487 Mukerji et al. Nov 2010 B1
7840841 Huang et al. Nov 2010 B2
7877524 Annem et al. Jan 2011 B1
7916728 Mimms Mar 2011 B1
7929433 Husak et al. Apr 2011 B2
7936772 Kashyap May 2011 B2
7991918 Jha et al. Aug 2011 B2
7996569 Aloni et al. Aug 2011 B2
8006016 Muller et al. Aug 2011 B2
8077620 Solomon et al. Dec 2011 B2
8099528 Millet et al. Jan 2012 B2
8103809 Michels et al. Jan 2012 B1
8112491 Michels et al. Feb 2012 B1
8112594 Giacomoni et al. Feb 2012 B2
8130650 Allen, Jr. et al. Mar 2012 B2
8233380 Subramanian et al. Jul 2012 B2
8279865 Giacomoni et al. Oct 2012 B2
8306036 Bollay et al. Nov 2012 B1
8346993 Michels et al. Jan 2013 B2
8447884 Baumann May 2013 B1
8448234 Mondaeev et al. May 2013 B2
8799403 Chan et al. Aug 2014 B2
8848715 Izenberg et al. Sep 2014 B2
8880632 Michels et al. Nov 2014 B1
8880696 Michels et al. Nov 2014 B1
8984178 Michels et al. Mar 2015 B2
9032113 Conroy et al. May 2015 B2
20010023442 Masters Sep 2001 A1
20010038629 Shinohara Nov 2001 A1
20010042200 Lamberton et al. Nov 2001 A1
20020143955 Shimada et al. Oct 2002 A1
20020156927 Boucher et al. Oct 2002 A1
20020161913 Gonzalez et al. Oct 2002 A1
20020198993 Cudd et al. Dec 2002 A1
20030046291 Fascenda Mar 2003 A1
20030067930 Salapura et al. Apr 2003 A1
20030086415 Bernhard et al. May 2003 A1
20030204636 Greenblat et al. Oct 2003 A1
20030225485 Fritz et al. Dec 2003 A1
20040032830 Bly et al. Feb 2004 A1
20040062245 Sharp et al. Apr 2004 A1
20040202161 Stachura et al. Oct 2004 A1
20040249881 Jha et al. Dec 2004 A1
20040249948 Sethi et al. Dec 2004 A1
20040267897 Hill et al. Dec 2004 A1
20050007991 Ton et al. Jan 2005 A1
20050050364 Feng Mar 2005 A1
20050083952 Swain Apr 2005 A1
20050091390 Helmer et al. Apr 2005 A1
20050114559 Miller May 2005 A1
20050122977 Lieberman Jun 2005 A1
20050141427 Bartky Jun 2005 A1
20050175014 Patrick Aug 2005 A1
20050187866 Lee Aug 2005 A1
20050213570 Stacy et al. Sep 2005 A1
20050226234 Sano et al. Oct 2005 A1
20060007928 Sangillo Jan 2006 A1
20060059267 Cugi et al. Mar 2006 A1
20060067349 Ronciak et al. Mar 2006 A1
20060104303 Makineni et al. May 2006 A1
20060174324 Zur et al. Aug 2006 A1
20060221832 Muller et al. Oct 2006 A1
20060221835 Sweeney Oct 2006 A1
20060224820 Cho et al. Oct 2006 A1
20060235996 Wolde et al. Oct 2006 A1
20060288128 Moskalev et al. Dec 2006 A1
20070083646 Miller et al. Apr 2007 A1
20070107048 Halls et al. May 2007 A1
20070118879 Yeun May 2007 A1
20070162619 Aloni et al. Jul 2007 A1
20070174491 Still et al. Jul 2007 A1
20080126509 Subramanian et al. May 2008 A1
20080133518 Kapoor et al. Jun 2008 A1
20080184248 Barua et al. Jul 2008 A1
20080201772 Mondaeev et al. Aug 2008 A1
20080219279 Chew Sep 2008 A1
20090003204 Okholm et al. Jan 2009 A1
20090007266 Wu et al. Jan 2009 A1
20090016217 Kashyap Jan 2009 A1
20090049230 Pandya Feb 2009 A1
20090089619 Huang et al. Apr 2009 A1
20090141891 Boyen et al. Jun 2009 A1
20090154459 Husak et al. Jun 2009 A1
20090222598 Hayden Sep 2009 A1
20090248911 Conroy et al. Oct 2009 A1
20090279559 Wong et al. Nov 2009 A1
20090287935 Aull et al. Nov 2009 A1
20100082849 Millet et al. Apr 2010 A1
20100085875 Solomon et al. Apr 2010 A1
20100094945 Chan et al. Apr 2010 A1
20100122091 Huang et al. May 2010 A1
20100325277 Muthiah et al. Dec 2010 A1
20110228781 Izenberg et al. Sep 2011 A1
20120191800 Michels et al. Jul 2012 A1
20130250777 Ziegler Sep 2013 A1
20140032695 Michels et al. Jan 2014 A1
20140185442 Newman et al. Jul 2014 A1
20140301207 Durand et al. Oct 2014 A1
Foreign Referenced Citations (16)
Number Date Country
0744850 Nov 1996 EP
1813084 Aug 2007 EP
WO 9114326 Sep 1991 WO
WO 9505712 Feb 1995 WO
WO 9709805 Mar 1997 WO
WO 9745800 Dec 1997 WO
WO 9905829 Feb 1999 WO
WO 9906913 Feb 1999 WO
WO 9910858 Mar 1999 WO
WO 9939373 Aug 1999 WO
WO 9964967 Dec 1999 WO
WO 0004422 Jan 2000 WO
WO 0004458 Jan 2000 WO
2004079930 Sep 2004 WO
WO 2006055494 May 2006 WO
2009158680 Dec 2009 WO
Non-Patent Literature Citations (35)
Entry
Anonymous, “Memory Mapping and DMA,” Chapter 15, pp. 412-463, Jan. 21, 2005.
Bell Laboratories, “Layer 4/7 Switching and Other Custom IP Traffic Processing using the NEPPI API,” Lucent Technologies, pp. 1-11, Murray Hill, NJ.
“DMA and Interrupt Handling,” EventHelix.com.
Harvey A.F. et al., “DMA Fundamentals on Various PC Platforms,” National Instruments Corporation: Application Note 011, Apr. 1991, pp. 1-18, 340023-01.
Mangino John, “Using DMA with High Performance Peripherals to Maximize System Performance,” WW TMS470 Catalog Applications, SPNA105, Jan. 2007, PowerPoint presentation, slides 1-23.
Mogul, Jeffrey, C., “The Case for Persistent-Connection HTTP,” SIGCOMM '95, 1995, pp. 299-313, Cambridge, MA.
Rabinovich, Michael et al., “DHTTP: An Efficient and Cache-Friendly Transfer Protocol for the Web,” IEEE/ACM Transactions on Networking, Dec. 2004, pp. 1007-1020, vol. 12, No. 6.
Stevens, W., “TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms,” Network Working Group; RFC: 2001; Standards Track, Jan. 1997, pp. 1-6, NOAO.
“TCP-Transmission Control Protocol (TCP Fast Retransmit and Recovery),” EventHelix.com/EventStudio1.0, Mar. 28, 2002, pp. 1-5.
Wadge, Wallace, “Achieving Gigabit Performance on Programmable Ethernet Network Interface Cards,” May 29, 2001, pp. 1-9.
Wikipedia, “Direct memory access,” <http://en.wikipedida.org/wiki/Direct—memory—access>, last modified Oct. 1, 2009.
Wikipedia, “Nagle's algorithm,” <http://en.wikipedia.org/wiki/Nagle%27s—algorithm>, last modified Oct. 9, 2009.
“Cavium Networks Product Selector Guide—Single & Multi-Core MIPS Processors, Security Processors and Accelerator Boards—Spring 2008,” (2008) pp. 1-44, Cavium Networks, Mountain View, CA, US.
“Comtech AHA Announces 3.0 Gbps GZIP Compression/Decompression Accelerator AHA362-PCIX offers high-speed GZIP compression and decompression,” www.aha.com, Apr. 20, 2005, pp. 1-2, Comtech AHA Corporation, Moscow, ID, USA.
“Comtech AHA Announces GZIP Compression and Decompression IC Offers the highest speed and compression ratio performance in hardware on the market,” www.aha.com, Jun. 26, 2007, pp. 1-2, Comtech AHA Corporation, Moscow, ID, USA.
“Gigabit Ethernet/PCI Network Interface Card; Host/NIC Software Interface Definition,” Jul. 1999, pp. 1-80, Revision 12.4.13, P/N 020001, Alteon WebSystems, Inc., San Jose, California.
“NITROX™ XL Security Acceleration Modules PCI 3V or 3V/5V-Universal Boards for SSL and IPSec,” at http://www.Caviumnetworks.com, (2002) pp. 1, Cavium Networks, Mountain View, CA USA.
“PCI, PCI-X,” at http://www.cavium.com/acceleration—boards—PCI—PCI-X.htm (Downloaded Oct. 2008), Cavium Networks—Products > Acceleration Boards > PCI, PCI-X.
“Plan 9 kernel history: overview / file list / diff list,” <http://switch.com/cgi-bin/plan9history.cgi?f=2001/0126/pc/etherga620.com>, accessed Oct. 22, 2007, pp. 1-16.
Welch, Von, “A User's Guide to TCP Windows,” http://www.vonwelch.com/report/tcp—windows, updated 1996, last accessed Jan. 29, 2010, pp. 1-5.
Salchow, Jr., KJ, “Clustered Multiprocessing: Changing the Rules of the Performance Game,” F5 White Paper, Jan. 2008, pp. 1-11, F5 Networks, Inc.
“A Process for Selective Routing of Servlet Content to Transcoding Modules,” Research Disclosure 422124, Jun. 1999, pp. 889-890, IBM Corporation.
F5 Networks, Inc., “BIG-IP Controller with Exclusive OneConnect Content Switching Feature Provides a Breakthrough System for Maximizing Server and Network Performance,” Press Release, May 8, 2001, 2 pages, Las Vegas, Nevada.
Crescendo Networks, “Application Layer Processing (ALP),” 2003-2009, pp. 168-186, Chapter 9, CN-5000E/5500E, Foxit Software Company.
Fielding et al., “Hypertext Transfer Protocol—HTTP/1.1,” Network Working Group, RFC: 2068, Jan. 1997, pp. 1-162.
Fielding et al., “Hypertext Transfer Protocol—HTTP/1.1,” Network Working Group, RFC: 2616, Jun. 1999, pp. 1-176, The Internet Society.
Floyd et al., “Random Early Detection Gateways for Congestion Avoidance,” Aug. 1993, pp. 1-22, IEEE/ACM Transactions on Networking, California.
Hochmuth, Phil, “F5, CacheFlow pump up content-delivery lines,” Network World Fusion, May 4, 2001, 1 page, Las Vegas, Nevada.
Schaefer, Ken, “IIS and Kerberos Part 5—Protocol Transition, Constrained Delegation, S4U2S and S4U2P,” Jul. 18, 2007, 21 pages, http://www.adopenstatic.com/cs/blogs/ken/archive/2007/07/19/8460.aspx.
“Servlet/Applet/HTML Authentication Process With Single Sign-On,” Research Disclosure 429128, Jan. 2000, pp. 163-164, IBM Corporation.
“Traffic Surges; Surge Queue; Netscaler Defense,” 2005, PowerPoint Presentation, slides 1-12, Citrix Systems, Inc.
Williams et al., “The Ultimate Windows Server 2003 System Administrator's Guide: Forwarding Authentication,” 2003, 2 pages, Figure 10.7, Addison-Wesley Professional, Boston, Massachusetts.
“Windows Server 2003 Kerberos Extensions,” Microsoft TechNet, 2003 (Updated Jul. 31, 2004), http://technet.microsoft.com/en-us/library/cc738207, Microsoft Corporation.
MacVittie, Lori, “Message-Based Load Balancing,” Technical Brief, Jan. 2010, pp. 1-9, F5 Networks, Inc.
International Search Report for Europe Patent Application No. 14191232.9 (Oct. 31, 2014).
Related Publications (1)
Number Date Country
20150049763 A1 Feb 2015 US