Freeing transmit memory on a network interface device prior to receiving an acknowledgment that transmit data has been received by a remote device

Information

  • Patent Grant
  • 9055104
  • Patent Number
    9,055,104
  • Date Filed
    Friday, May 22, 2009
    15 years ago
  • Date Issued
    Tuesday, June 9, 2015
    9 years ago
Abstract
A transmit offload engine (TOE) such as an intelligent network interface device (INIC), video controller or host bus adapter (HBA) that can communicate data over transport protocols such as Transport Control Protocol (TCP) for a host. Such a device can send and receive data for the host to and from a remote host, over a TCP connection maintained by the device. For sending data, the device can indicate to the host that data has been transmitted from the device to a network, prior to receiving, by the device from the network, an acknowledgement (ACK) for all the data, accelerating data transmission. The greatest sequence number for which all previous bytes have been ACKed can be provided with a response to a subsequent command, with the host maintaining a table of ACK values to complete commands when appropriate.
Description
REFERENCE TO CD APPENDIX

The Compact Disc Appendix, which was filed with application Ser. No. 10/413,256, includes two copies of a recordable Compact Disc (CD-R) containing information that is part of the disclosure of the present patent document. A portion of the disclosure of this patent document contains material that is subject to copyright protection. All the material on the Compact Disc is hereby expressly incorporated by reference into the present application. The copyright owner of that material 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 files or records, but otherwise reserves all copyright rights.


BACKGROUND

The present invention relates to computer and other networking, particularly devices that can communicate over a network using Transport Control Protocol (TCP) over Internet Protocol (IP). Recent advances in this area include intelligent network interface hardware and software that has been developed by Alacritech, Inc. to work with a host computer. Detailed descriptions of such advances, as well as relevant claims, can be found in U.S. Pat. No. 6,226,680, U.S. Pat. No. 6,226,680, U.S. Pat. No. 6,247,060, U.S. Pat. No. 6,334,153, U.S. Pat. No. 6,389,479, U.S. Pat. No. 6,393,487, U.S. Pat. No. 6,427,171, U.S. Pat. No. 6,427,173, U.S. Pat. No. 6,434,620 and U.S. Pat. No. 6,470,415, which are incorporated by reference herein.


For example, in one embodiment multiple TCP connections can be passed from a host computer to an intelligent network interface card (INIC) that is coupled to the host computer, offloading the TCP processing from the host to the card for these connections. A host can be a computer that acts as a source of information or signals. The term can refer to almost any kind of computer, from a centralized mainframe that is a host to its terminals, to a server that is host to its clients, to a desktop PC that is host to its peripherals. In network architectures, a client station (user's machine) may be considered a host, and an adapter that terminates TCP may also be considered a host, because each is a source of information to the network in contrast to a device such as a router or switch that merely directs traffic at the IP level.


For an INIC to be cost-effective, its processing power and memory capacity may be less than that of the host computer, although the INIC may also be more efficient than the host at certain tasks. TCP protocol guarantees reliable delivery of data, however, requiring thousands of lines of instruction code to ensure that the data is accurately and completely transferred over the network from a source in one host to a destination in another host. For this reason, the host may establish the TCP connections and retain a fallback capability for error handling of messages that are otherwise processed by a fast-path provided by the INIC.


One way that TCP guarantees delivery of data is through the use of acknowledgments (ACKs) and the sequenced delivery of the data. That is, after data has been sent in sequential packets, ACKs are returned from the receiving host indicating that all bytes up to a certain sequence number have been received. As shown in the prior art diagram of FIG. 1, to transmit data corresponding to a TCP connection from a local host having an attached INIC to a remote host over a network, the local host first sends 20 to the INIC a command to transmit the data. The INIC then 22 acquires the data, divides it into segments and adds TCP and IP headers to each data segment to create a TCP/IP packet corresponding to each segment. Next, the INIC transmits 24 the resulting packets onto the network. After the remote host has received and validated the packets, the remote host sends ACKs back to the local host indicating how much of the data has been successfully received.


Upon receiving an ACK 26 for all the transmitted data, the INIC sends a command complete 28 to the local host indicating that the transmit command has been completed by the transport function of the INIC, and an upper layer such as a session layer of the host is informed that its request to transmit data has been completed. For the case in which an ACK is not received by the INIC within a predetermined time after the corresponding packets were sent, indicating an error condition, the TCP connection is flushed 40 from the INIC to the host. The host can then retransmit 44 some or all of the unacknowledged packets.


SUMMARY

It was discovered by the present inventors that waiting for ACKs to be received by an interface device for a host computer before signaling to the host that transmit commands have been completed can cause delays in transmitting data. In one embodiment of the present disclosure this problem is solved by sending, from the device to the host, a signal that the data has been sent from the device to the network, prior to receiving, by the device from the network, an ACK that all the data has been received. This brief summary does not purport to define the invention, which is instead defined in the claims below.





BRIEF DESCRIPTION OF THE FIGURES


FIG. 1 is a schematic diagram of a prior art method for transmitting data from a host with an interface device.



FIG. 2 is a schematic diagram of a system including a local host that is coupled to a remote host over a network.



FIG. 3 is a schematic diagram of system including a local host that is coupled to a remote host over a network via a network interface device.



FIG. 4 is a schematic diagram of a method that can reduce delays in transmitting data from a host with an interface device.



FIG. 5 is a schematic diagram of another method that can reduce delays in transmitting data from a host with an interface device.





DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT


FIG. 2 shows a schematic diagram of a system including a local host 50 that is coupled to a remote host 52 over a network 55. The local host 50 has a central processing unit (CPU) 56 that can access host storage 57 via host bus 58. A network interface device such as a communication processing device (CPD) 57 is integrated into the local host 50 to facilitate communication with the network. The local host 50 may be a client or server station that runs applications as well as communicating over the network 55. The local host 50 may instead be a peripheral unit such as an adapter for such a client or server station, with the peripheral unit terminating transport level protocols such as TCP.



FIG. 3 shows a schematic diagram of another system including a local host 70 that is coupled to a remote host 72 over a network 75. The local host 70 has a CPU 76 that can access host memory 77 via memory bus 78. A peripheral component interconnect (PCI) bus 79 couples host 70 to storage 82. A network interface device such as INIC 80 is coupled between the PCI bus 79 and the network 75. Although described as an INIC in this embodiment, one should realize that the network interface device can take the form of a storage interface such as a host bus adapter (HBA), for example an interface that processes Internet SCSI (iSCSI), or the network interface may be a video interface, an audio interface, or various other peripheral units.



FIG. 4 illustrates a method for transmitting data corresponding to a TCP connection from a local host to a remote host over a network. A network interface device is coupled between the local host and the network to facilitate network communication. According to one embodiment, the TCP connection has been established for an application running on the local host, with the TCP connection being controlled 120 by the interface device. The local host then sends 122 to the interface device a request or command to transmit data associated with the application. Responding to the command, the interface device acquires 124 the data, divides it into segments and adds TCP and IP headers to each data segment to create a TCP/IP packet corresponding to each segment. The interface device then transmits 126 the resulting packets onto the network.


After all the packets have been transmitted onto the network, the interface device sends a signal 130 to the host computer that the data or packets have been transmitted. The signal may be known as a command response, and may be triggered by the host sending to the interface device another command to transmit additional data corresponding to the TCP connection 128. The command response includes an indication of how much, if any, of the transmitted data has been acknowledged (ACKed) by the remote host. An indication that the interface device has received an ACK for a previous command may also be sent with or piggybacked on the command response.


For the specific example in which up to three transmit commands per connection (actually pointers to three commands) can be simultaneously stored on the interface device, when the host passes a third command to the card, the interface device will complete the first command back to the host as long as all the data for the first command has been sent. There may or may not be ACKed data in that command response, which is indicated in the SND_UNA (send unacknowledged) value. The SND_UNA value provides the sequence number beyond which the remote host has not acknowledged receipt of the data.


Upon receiving the signal that the data was sent, the host can send a yet another command to the interface device to transmit additional data. Relieving the interface device from the duty of maintaining the command until all the data for the command has been ACKed frees memory space on the interface device for storing another command, allowing the interface device to transmit more data. This is particularly useful for the situation in which the interface device has a limited amount of memory for storing commands, and that memory amount is exceeded by the outstanding commands for which an ACK has not yet been received.


The host then waits to receive from the interface device an indication that the ACK for the transmitted packets has been received 132. If the ACK indication is received, the host transport function marks the send command as having completed 134 and tells the layer that requested the command, typically a session or application layer, that its request to transmit the data corresponding to the command has been successfully completed. If the ACK is not received by the interface device within a predetermined time period, the interface device flushes the connection from the interface device to the host 136, and the host then retransmits the packets 138 for which an ACK was not received.


In one embodiment, the interface device caches thirty-two of the most active TCP connections in SRAM, while about four thousand TCP connections are maintained in DRAM. SRAM memory may be relatively expensive especially in terms of on-chip real estate, and therefore SRAM memory space may be relatively scarce. For each of the thirty-two active TCP connections in this embodiment, pointers to (also known as indications of) up to three transmit commands are stored: commands that have been sent, commands that are being sent, and commands that are to be sent. Once these three pointers or indications have been stored, that connection can not transmit any more data in this embodiment. Particularly for the situation in which a number of transmit commands are desired to be sent in a rapid sequence for a connection, waiting for an ACK to be returned corresponding to one of the commands can stall the transmission of data. This embodiment avoids that delay by freeing the SRAM that stores the command pointers or indications once the data has been sent and typically prior to receiving an ACK for all that data, while sending a signal to the host that the data has been sent.


The host can maintain in its short term memory a table of ACK values for each connection in host memory, the host memory typically being many times larger the SRAM on the interface device, so that delays in data transmission due to interface device waiting for commands to be ACKed are reduced. The host then is responsible for completing the command when the corresponding ACK indication has arrived at the host. The host can determine completion of the commands simply by calculating the sequence number for the last byte of data for a command, using the data length associated with the command and the starting sequence number of the command (or the ending sequence number of the prior command). This sequence number is compared with a SND_UNA field in each command response, thereby determining whether the command is completed. Completing the command includes providing by the transport layer, typically TCP, an indication to an upper layer such as a session layer or application layer, that the data associated with the command has been ACKed by the remote host.



FIG. 5 illustrates another method for transmitting data corresponding to a TCP connection from a local host to a remote host over a network. Much as before, a network interface device is coupled between the local host and the network to facilitate network communication. The TCP connection has been established for an application running on the local host, with the TCP connection being controlled by the interface device. The local host sends 220 to the interface device a first command to transmit data associated with the application. To accomplish this, the host writes a pointer for that command to a register on the interface device, with the command initially remaining on the host. The pointer may for example be 64 bits in length, whereas the command may be 512 bytes, most of those bytes serving as pointers (e.g., a scatter-gather list) to the data of the host that is to be transmitted. The command is then pulled into the interface device in pieces during execution of the command. Responding to the command, the interface device acquires the data, divides it into segments and adds TCP and IP headers to each data segment to create a TCP/IP packet corresponding to each segment and transmits the resulting packets onto the network 222.


The host then sends a second command 224 to the interface device to transmit additional data associated with the network connection. The interface device, upon receiving the second command from the host, determines whether the memory space for holding pointers to transmit commands for this connection is full. If not 228, the interface device continues to wait for ACKs associated with the first command to be returned to send a command complete response to the host 230. If, on the other hand, the interface device determines that the memory space for holding transmit command pointers is now full 232, the interface device sends a response to the first command indicating that the data associated with the first command has been sent. This command response includes an indication of how much, if any, of the transmitted data has been ACKed by the remote host 234. One should note that the interface device may make the determination of whether the memory space for holding pointers to transmit commands for the connection is full upon receiving a third command, fourth command or other subsequent command, instead of upon receiving the second command.


For the case in which the interface device waits for ACKs associated with the first command to be returned to send a command complete response to the host 230, upon receiving an ACK indicating that all the data has been received 238, the interface device then sends a command complete response to the host 240. Should the interface device not receive such an ACK within a predetermined time period 242, indicating an error condition, control of the connection is flushed from the interface device to the host 244. The host may then attempt to retransmit 246 the data corresponding to the first command.


For the case in which the interface device has sent a response to the first command indicating that the data associated with the first command has been transmitted, the interface device can send an indication to the host when a corresponding ACK has been received 248. Upon receiving an indication from the interface device that all the data corresponding to the first command has been received, the host then completes the first command 250 by indicating to a layer above the transport layer that the data associated with the first command has been received. Should the interface device not receive such an ACK within a predetermined time period 242, indicating an error condition, control of the connection is flushed from the interface device to the host 244. The host may then attempt to retransmit 246 the data corresponding to the first command.


Alternatively, the SND_UNA value can be provided with each command response, making unnecessary a separate indication that all the data corresponding to a command has been ACKed. The indication that all the data for a command has been ACKed may be piggybacked with a command response indicating that all the data for a subsequent command has been transmitted, or with a command response indicating that all the data for a subsequent command has been ACKed. Once the command count on the interface device is no longer full, the interface device reverts to completing commands to the host when an ACK for all the command data has been received.


For a connection that is flushed from the interface device to the host, the SND_UNA value in the latest command response, which can be provided as part of the flush mechanism, can be used by the host to determine the data of the command that the host needs to transmit.


In this embodiment commands to transmit data are completed by the interface device unless the interface memory for storing the transmit command pointers becomes full or nearly full, at which time the earliest outstanding command is sent to the host for completion. This mechanism has an advantage of maintaining a flow of command completions upon which to piggyback indications that ACKs have been received by the interface device. For an alternative embodiment that always sends a command response indicating data has been sent but not necessarily received, a situation may exist in which a command response may not be available for piggybacking an ACK indication, and that indication is sent in a separate communication from the host to the interface device.


Source code description of an embodiment of the present invention can be found in Provisional Patent Application No. 60/374,788, which is incorporated by reference herein. Also included with the present disclosure is a compact disc including host code and device microcode that describe in detail an embodiment of the present invention.


Although we have focused on teaching the preferred embodiments of an improved data communication system, other embodiments and modifications of this invention will be apparent to persons of ordinary skill in the art in view of these teachings. Therefore, this invention is limited only by the following claims, which include all such embodiments and modifications when viewed in conjunction with the above specification and accompanying drawings.

Claims
  • 1. A method for communication involving a computer, a network, and a network interface device of the computer, the network interface device being coupled to the network, the method comprising: receiving, by the network interface device from the computer, a command to transmit application data from the computer to the network;sending, by the network interface device to the network, data corresponding to the command, including prepending a transport layer header to at least some of the data;sending, by the network interface device to the computer, a response to the command indicating that the data has been sent from the network interface device to the network, prior to receiving, by the network interface device from the network, an acknowledgement (ACK) that all the data corresponding to the command has been received; andmaintaining, by the network interface device, a Transport Control Protocol (TCP) connection that the command, the data and the ACK correspond to.
  • 2. The method of claim 1, wherein sending the response to the command is prompted by receiving, by the network interface device from the computer, a subsequent command to transmit additional application data from the computer to the network.
  • 3. The method of claim 1, further comprising sending a sequence number for the ACK with the response to the command.
  • 4. The method of claim 1, further comprising: receiving, by the network interface device from the computer, a subsequent command to transmit additional application data from the computer to the network; andsending, by the network interface device to the computer, a command response after receiving, by the network interface device from the network, an ACK for all the additional data.
  • 5. The method of claim 1, further comprising: receiving, by the network interface device from the computer, a subsequent command to transmit additional application data from the computer to the network; andsending, by the network interface device to the computer, information indicating completion of the subsequent command after receiving, by the network interface device from the network, an ACK for all the additional data.
  • 6. The method of claim 1, further comprising: receiving, by the network interface device, the ACK;sending, by the network interface device to the computer, an indication that the ACK has been received, to prompt the computer to complete the command.
  • 7. The method of claim 1, further comprising maintaining a table of ACK values including a value that corresponds to the ACK.
  • 8. The method of claim 1, further comprising: storing a pointer to the command in a memory space of the network interface device; andfreeing the memory space upon sending, by the network interface device to the computer, the command response indicating that the data has been sent from the network interface device to the network.
  • 9. The method of claim 1, wherein receiving, by the network interface device from the computer, a command to transmit data includes receiving, by the network interface device from the computer, a pointer to the command.
  • 10. The method of claim 1, further comprising sending, with the response to the command, a SND_UNA value.
  • 11. The method of claim 1, further comprising sending, with the response to the command, an indication that all data has been received for a previous command.
  • 12. A method for communication involving a computer, a network, and a network interface device of the computer, the network interface device being coupled to the network, the method comprising: receiving, by the network interface device from the computer, a pointer to a command to transmit data from the computer to the network;sending, by the network interface device to the network, data corresponding to the command;sending, by the network interface device to the computer, a response to the command indicating that the data has been sent from the device to the network, prior to receiving, by the network interface device from the network, an acknowledgement (ACK) that all the data has been received; andmaintaining, by the network interface device, a Transport Control Protocol (TCP) connection that the command, the data and the ACK correspond to.
  • 13. The method of claim 12, wherein sending the response to the command is prompted by receiving, by the network interface device from the computer, a subsequent pointer to a subsequent command to transmit additional application data from the computer to the network.
  • 14. The method of claim 12, further comprising sending a sequence number for the ACK with the response to the command.
  • 15. The method of claim 12, further comprising: receiving, by the network interface device, the ACK;sending, by the network interface device to the computer, an indication that the ACK has been received to prompt the computer to complete the command.
  • 16. The method of claim 12, further comprising a table of ACK values including a value that corresponds to the ACK.
  • 17. The method of claim 12, further comprising: storing the pointer to the command in a memory space of the device; andfreeing the memory space upon sending, from the network interface device to the computer, the command response indicating that the data has been sent from the network interface device to the network.
  • 18. The method of claim 12, further comprising determining that a memory space of the network interface device in which the pointer is stored is full, prior to sending the response to the command.
  • 19. The method of claim 12, further comprising sending, with the response to the command, a SND_UNA value.
  • 20. The method of claim 12, further comprising sending, with the response to the command, an indication that all data has been received for a previous command.
  • 21. A method for communication involving a computer, a network, and a network interface device of the computer, the network interface device being coupled to the network, the method comprising: receiving, by the device from the computer, a series of commands to transmit application data from the computer to the network;sending, by the device to the network, data corresponding to the commands, including prepending a transport layer header to at least some of the data; andsending, by the device to the computer, a response to the commands, each response including a SND_UNA value;wherein data corresponding to one of the commands is sent by the device to the network prior to receiving an ACK for data corresponding to a prior one of the commands.
  • 22. A system for communication involving a computer, a network, and a network interface device of the computer, the network interface device being coupled to the network, the system comprising: means for receiving, by the network interface device from the computer, a command to transmit data from the computer to the network;means for sending, by the network interface device to the network, data corresponding to the command, including means for prepending a transport layer header to at least some of the data; andmeans for sending, by the network interface device to the computer, an indication that the data has been sent from the network interface device to the network, prior to receiving, by the network interface device from the network, an acknowledgement (ACK) that the data has been received.
  • 23. A non-transitory computer readable medium storing a data structure for use with a host that is connected to a network by a network interface device, the data structure comprising: instructions to receive, by the network interface device from the host, a command to transmit data from the host to the network;instructions to send, by the device to the network, data corresponding to the command, including instructions for prepending transport layer header to at least some of the data; andinstructions to send, by the network interface device to the host, an indication that the data has been sent from the network interface device to the network, prior to receiving, by the network interface device from the network, an acknowledgement (ACK) that the data has been received.
  • 24. The method of claim 12, further comprising: receiving, by the network interface device from the computer, a subsequent pointer to a subsequent command to transmit additional application data from the computer to the network; andsending, by the network interface device to the computer, information indicating completion of the subsequent command after receiving, by the network interface device from the network, an ACK for the additional data.
CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit under 35 U.S.C. §120 of (is a continuation of) U.S. patent application Ser. No. 10/413,256, filed Apr. 14, 2003 now U.S. Pat. No. 7,543,087, entitled “Freeing Transmit Memory on a Network Interface Device Prior to Receiving An Acknowledgement that Transmit Data Has Been Received by a Remote Device,” which is incorporated by reference herein. This application also claims the benefit under 35 U.S.C. §119(e) to Provisional Patent Application Ser. No. 60/374,788, filed Apr. 22, 2002, entitled “TCP/IP Offload Device,” which is incorporated by reference herein.

US Referenced Citations (302)
Number Name Date Kind
4366538 Johnson et al. Dec 1982 A
4485455 Boone et al. Nov 1984 A
4485460 Stambaugh Nov 1984 A
4589063 Shah et al. May 1986 A
4700185 Balph et al. Oct 1987 A
4991133 Davis et al. Feb 1991 A
5056058 Hirata et al. Oct 1991 A
5058110 Beach et al. Oct 1991 A
5097442 Ward et al. Mar 1992 A
5129093 Muramatsu et al. Jul 1992 A
5163131 Row et al. Nov 1992 A
5212778 Dally et al. May 1993 A
5274768 Traw et al. Dec 1993 A
5280477 Trapp Jan 1994 A
5281963 Ishikawa et al. Jan 1994 A
5289580 Latif et al. Feb 1994 A
5303344 Yokoyama et al. Apr 1994 A
5412782 Hausman et al. May 1995 A
5418912 Christenson May 1995 A
5448566 Richter et al. Sep 1995 A
5485455 Dobbins et al. Jan 1996 A
5485460 Schrier et al. Jan 1996 A
5485579 Hitz et al. Jan 1996 A
5506966 Ban Apr 1996 A
5511169 Suda Apr 1996 A
5517668 Szwerinski et al. May 1996 A
5524250 Chesson et al. Jun 1996 A
5535375 Eshel et al. Jul 1996 A
5548730 Young et al. Aug 1996 A
5553241 Shirakihar Sep 1996 A
5566170 Bakke et al. Oct 1996 A
5574919 Netravali et al. Nov 1996 A
5588121 Reddin et al. Dec 1996 A
5590328 Seno et al. Dec 1996 A
5592622 Isfeld et al. Jan 1997 A
5596574 Perlman et al. Jan 1997 A
5598410 Stone Jan 1997 A
5619650 Bach et al. Apr 1997 A
5629933 Delp et al. May 1997 A
5633780 Cronin May 1997 A
5634099 Andrews et al. May 1997 A
5634127 Cloud et al. May 1997 A
5642482 Pardillos Jun 1997 A
5664114 Krech, Jr. et al. Sep 1997 A
5671355 Collins Sep 1997 A
5678060 Yokoyama et al. Oct 1997 A
5682534 Kapoor et al. Oct 1997 A
5684954 Kaiserswerth et al. Nov 1997 A
5692130 Shobu et al. Nov 1997 A
5699317 Sartore et al. Dec 1997 A
5699350 Kraslavsky Dec 1997 A
5701434 Nakagawa Dec 1997 A
5701516 Cheng et al. Dec 1997 A
5706514 Bonola Jan 1998 A
5727142 Chen Mar 1998 A
5742765 Wong et al. Apr 1998 A
5749095 Hagersten May 1998 A
5751715 Chan et al. May 1998 A
5751723 Vanden Heuvel et al. May 1998 A
5752078 Delp et al. May 1998 A
5758084 Silverstein et al. May 1998 A
5758089 Gentry et al. May 1998 A
5758186 Hamilton et al. May 1998 A
5758194 Kuzma May 1998 A
5768618 Erickson et al. Jun 1998 A
5771349 Picazo, Jr. et al. Jun 1998 A
5774660 Brendel et al. Jun 1998 A
5778013 Jedwab Jul 1998 A
5778419 Hansen et al. Jul 1998 A
5790804 Osborne Aug 1998 A
5794061 Hansen et al. Aug 1998 A
5799150 Hamilton et al. Aug 1998 A
5802258 Chen Sep 1998 A
5802580 McAlpine Sep 1998 A
5809328 Nogales et al. Sep 1998 A
5809527 Cooper et al. Sep 1998 A
5812775 Van Seters et al. Sep 1998 A
5815646 Purcell et al. Sep 1998 A
5819111 Davies et al. Oct 1998 A
5828835 Isfeld et al. Oct 1998 A
5848293 Gentry et al. Dec 1998 A
5870394 Oprea Feb 1999 A
5872919 Wakeland et al. Feb 1999 A
5878225 Bilansky et al. Mar 1999 A
5878227 Wade et al. Mar 1999 A
5892903 Klaus Apr 1999 A
5898713 Melzer et al. Apr 1999 A
5913028 Wang et al. Jun 1999 A
5915094 Kouloheris et al. Jun 1999 A
5917828 Thompson Jun 1999 A
5920566 Hendel et al. Jul 1999 A
5926642 Favor Jul 1999 A
5930830 Mendelson et al. Jul 1999 A
5931918 Row et al. Aug 1999 A
5935205 Murayama et al. Aug 1999 A
5935249 Stern et al. Aug 1999 A
5937169 Connery et al. Aug 1999 A
5941969 Ram et al. Aug 1999 A
5941972 Hoese et al. Aug 1999 A
5950203 Stakuis et al. Sep 1999 A
5963876 Manssen et al. Oct 1999 A
5970804 Robbat, Jr. Oct 1999 A
5978844 Tsuchiya et al. Nov 1999 A
5987022 Geiger et al. Nov 1999 A
5991299 Radogna et al. Nov 1999 A
5996013 Delp et al. Nov 1999 A
5996024 Blumenau Nov 1999 A
6005849 Roach et al. Dec 1999 A
6009478 Panner et al. Dec 1999 A
6014380 Hendel et al. Jan 2000 A
6014557 Morton et al. Jan 2000 A
6016513 Lowe Jan 2000 A
6021446 Gentry et al. Feb 2000 A
6021507 Chen Feb 2000 A
6026452 Pitts Feb 2000 A
6034963 Minami et al. Mar 2000 A
6038562 Anjur et al. Mar 2000 A
6041058 Flanders et al. Mar 2000 A
6041381 Hoese Mar 2000 A
6044438 Olnowich Mar 2000 A
6047323 Krause Apr 2000 A
6047356 Anderson et al. Apr 2000 A
6049528 Hendel et al. Apr 2000 A
6057863 Olarig May 2000 A
6061368 Hitzelberger May 2000 A
6065096 Day et al. May 2000 A
6067569 Khaki et al. May 2000 A
6070200 Gates et al. May 2000 A
6078564 Lakshman et al. Jun 2000 A
6078733 Osborne Jun 2000 A
6097734 Gotesman et al. Aug 2000 A
6101555 Goshey et al. Aug 2000 A
6101590 Hansen Aug 2000 A
6111673 Chang et al. Aug 2000 A
6115615 Ota et al. Sep 2000 A
6122670 Bennett et al. Sep 2000 A
6141701 Whitney Oct 2000 A
6141705 Anand et al. Oct 2000 A
6145017 Ghaffari Nov 2000 A
6157944 Pedersen Dec 2000 A
6157955 Narad et al. Dec 2000 A
6172980 Flanders et al. Jan 2001 B1
6173333 Jolitz et al. Jan 2001 B1
6181705 Branstad et al. Jan 2001 B1
6202105 Gates et al. Mar 2001 B1
6219693 Napolitano et al. Apr 2001 B1
6223242 Sheafor et al. Apr 2001 B1
6226680 Boucher et al. May 2001 B1
6233242 Mayer et al. May 2001 B1
6243667 Kerr et al. Jun 2001 B1
6246683 Connery et al. Jun 2001 B1
6247060 Boucher et al. Jun 2001 B1
6279051 Gates et al. Aug 2001 B1
6289023 Dowling et al. Sep 2001 B1
6298403 Suri et al. Oct 2001 B1
6324649 Eyres et al. Nov 2001 B1
6334153 Boucher et al. Dec 2001 B2
6343345 Hilla et al. Jan 2002 B1
6343360 Feinleib Jan 2002 B1
6345301 Burns et al. Feb 2002 B1
6345302 Bennett et al. Feb 2002 B1
6356951 Gentry et al. Mar 2002 B1
6370599 Anand et al. Apr 2002 B1
6385647 Willis et al. May 2002 B1
6389468 Muller et al. May 2002 B1
6389479 Boucher May 2002 B1
6393487 Boucher et al. May 2002 B2
6418169 Datari Jul 2002 B1
6421742 Tillier Jul 2002 B1
6421753 Hoese et al. Jul 2002 B1
6427169 Elzur Jul 2002 B1
6427171 Craft et al. Jul 2002 B1
6427173 Boucher et al. Jul 2002 B1
6434620 Boucher et al. Aug 2002 B1
6434651 Gentry, Jr. Aug 2002 B1
6449656 Elzur et al. Sep 2002 B1
6452915 Jorgensen Sep 2002 B1
6453360 Muller et al. Sep 2002 B1
6453406 Sarnikowski et al. Sep 2002 B1
6470415 Starr et al. Oct 2002 B1
6473425 Bellaton et al. Oct 2002 B1
6480489 Muller et al. Nov 2002 B1
6483804 Muller et al. Nov 2002 B1
6487202 Klausmeier et al. Nov 2002 B1
6487654 Dowling Nov 2002 B2
6490631 Teich et al. Dec 2002 B1
6502144 Accarie Dec 2002 B1
6523119 Pavlin et al. Feb 2003 B2
6526446 Yang et al. Feb 2003 B1
6542504 Mahler et al. Apr 2003 B1
6570884 Connery et al. May 2003 B1
6591302 Boucher et al. Jul 2003 B2
6591310 Johnson Jul 2003 B1
6594261 Boura et al. Jul 2003 B1
6631484 Born Oct 2003 B1
6648611 Morse et al. Nov 2003 B2
6650640 Muller et al. Nov 2003 B1
6657757 Chang et al. Dec 2003 B1
6658480 Boucher et al. Dec 2003 B2
6678283 Teplitsky Jan 2004 B1
6681364 Calvignac et al. Jan 2004 B1
6683851 Willkie et al. Jan 2004 B1
6687758 Craft et al. Feb 2004 B2
6697366 Kim Feb 2004 B1
6697868 Craft et al. Feb 2004 B2
6751665 Philbrick et al. Jun 2004 B2
6757746 Boucher et al. Jun 2004 B2
6757767 Kelleher Jun 2004 B1
6765901 Johnson et al. Jul 2004 B1
6807581 Starr et al. Oct 2004 B1
6842896 Redding et al. Jan 2005 B1
6865264 Berstis Mar 2005 B2
6912522 Edgar Jun 2005 B2
6938092 Burns Aug 2005 B2
6941386 Craft et al. Sep 2005 B2
6965941 Boucher et al. Nov 2005 B2
6976148 Arimilli et al. Dec 2005 B2
6996070 Starr et al. Feb 2006 B2
7016361 Swonk et al. Mar 2006 B2
7042898 Blightman et al. May 2006 B2
7047320 Arimilli et al. May 2006 B2
7073196 Dowd et al. Jul 2006 B1
7076568 Philbrick et al. Jul 2006 B2
7089326 Boucher et al. Aug 2006 B2
7093099 Bodas et al. Aug 2006 B2
7124205 Craft et al. Oct 2006 B2
7133940 Blightman et al. Nov 2006 B2
7167926 Boucher et al. Jan 2007 B1
7167927 Philbrick et al. Jan 2007 B2
7174393 Boucher et al. Feb 2007 B2
7181531 Pinkerton et al. Feb 2007 B2
7185266 Blightman et al. Feb 2007 B2
7187679 Dally et al. Mar 2007 B2
7191241 Boucher et al. Mar 2007 B2
7191318 Tripathy et al. Mar 2007 B2
7237036 Boucher et al. Jun 2007 B2
7254696 Mittal et al. Aug 2007 B2
7260518 Kerr et al. Aug 2007 B2
7283522 Siddabathuni Oct 2007 B2
7284070 Boucher et al. Oct 2007 B2
7287092 Sharp Oct 2007 B2
7337241 Boucher et al. Feb 2008 B2
7461160 Boucher et al. Dec 2008 B2
7472156 Philbrick et al. Dec 2008 B2
7496689 Sharp et al. Feb 2009 B2
7502869 Boucher et al. Mar 2009 B2
7519699 Jain et al. Apr 2009 B2
7543087 Philbrick et al. Jun 2009 B2
7584260 Craft et al. Sep 2009 B2
7620726 Craft et al. Nov 2009 B2
7627001 Craft et al. Dec 2009 B2
7627684 Boucher et al. Dec 2009 B2
7640364 Craft et al. Dec 2009 B2
7664868 Boucher et al. Feb 2010 B2
7664883 Craft et al. Feb 2010 B2
7673072 Boucher et al. Mar 2010 B2
7694024 Philbrick et al. Apr 2010 B2
7738500 Jones et al. Jun 2010 B1
20010004354 Jolitz Jun 2001 A1
20010013059 Dawson et al. Aug 2001 A1
20010014892 Gaither et al. Aug 2001 A1
20010014954 Purcell et al. Aug 2001 A1
20010025315 Jolitz Sep 2001 A1
20010037406 Philbrick et al. Nov 2001 A1
20010048681 Bilic et al. Dec 2001 A1
20010053148 Bilic et al. Dec 2001 A1
20020016851 Border Feb 2002 A1
20020073223 Darnell et al. Jun 2002 A1
20020112175 Makofka et al. Aug 2002 A1
20020156927 Boucher et al. Oct 2002 A1
20030014544 Pettey Jan 2003 A1
20030046330 Hayes Mar 2003 A1
20030066011 Oren Apr 2003 A1
20030067903 Jorgensen Apr 2003 A1
20030110344 Szczepanek et al. Jun 2003 A1
20030149715 Ruutu et al. Aug 2003 A1
20030165160 Minami et al. Sep 2003 A1
20040010712 Hui et al. Jan 2004 A1
20040042458 Elzu Mar 2004 A1
20040042464 Elzur et al. Mar 2004 A1
20040049580 Boyd et al. Mar 2004 A1
20040049601 Boyd et al. Mar 2004 A1
20040054814 McDaniel Mar 2004 A1
20040059926 Angelo et al. Mar 2004 A1
20040088262 Boucher et al. May 2004 A1
20040153578 Elzur Aug 2004 A1
20040202166 Dillon Oct 2004 A1
20040210795 Anderson Oct 2004 A1
20040213290 Johnson et al. Oct 2004 A1
20040246974 Gyugyi et al. Dec 2004 A1
20040249957 Ekis et al. Dec 2004 A1
20050060538 Beverly Mar 2005 A1
20050144300 Craft et al. Jun 2005 A1
20060133386 McCormack et al. Jun 2006 A1
20060248208 Walbeck et al. Nov 2006 A1
20070083682 Bartley et al. Apr 2007 A1
20070140240 Dally et al. Jun 2007 A1
20080043732 Desai et al. Feb 2008 A1
20080170501 Patel et al. Jul 2008 A1
20080209084 Wang et al. Aug 2008 A1
20080240111 Gadelrab Oct 2008 A1
20090063696 Wang et al. Mar 2009 A1
Foreign Referenced Citations (13)
Number Date Country
WO 9819412 May 1998 WO
WO 9850852 Nov 1998 WO
WO 9904343 Jan 1999 WO
WO 9965219 Dec 1999 WO
WO 0013091 Mar 2000 WO
WO 0104770 Jan 2001 WO
WO 0105107 Jan 2001 WO
WO 0105116 Jan 2001 WO
WO 0105123 Jan 2001 WO
WO 0140960 Jun 2001 WO
WO 0159966 Aug 2001 WO
WO 0186430 Nov 2001 WO
WO 2007130476 Nov 2007 WO
Non-Patent Literature Citations (88)
Entry
Internet pages entitled “Hardware Assisted Protocol Processing”, (which Eugene Feinber is working on), 1 page, printed Nov. 25, 1998.
Zilog product Brief entitled “Z85C30 CMOS SCC Serial Communication Controller”, Zilog Inc., 3 pages, 1997.
Internet pages of Xpoint Technologies, Inc. entitled “Smart LAN Work Requests”, 5 pages, printed Dec. 19, 1997.
Internet pages entitled: Asante and 100BASE-T Fast Ethernet. 7 pages, printed May 27, 1997.
Internet pages entitled: A Guide to the Paragon XP/S-A7 Supercomputer at Indiana University. 13 pages, printed Dec. 21, 1998.
Richard Stevens, “TCP/IP Illustrated, vol. 1, The Protocols”, pp. 325-326 (1994).
Internet pages entitled: Northridge/Southbridge vs. Intel Hub Architecture, 4 pages, printed Feb. 19, 2001.
Gigabit Ethernet Technical Brief, Achieving End-to-End Performance. Alteon Networks, Inc, First Edition, Sep. 1996, 15 pages.
Internet pages directed to Technical Brief on Alteon Ethernet Gigabit NIC technology, www.alteon.com, 14 pages, printed Mar. 15, 1997.
VIA Technologies, Inc. article entitled “VT8501 Apollo MVP4”, pp. i-iv, 1-11, cover and copyright page, revision 1.3, Feb. 1, 2000.
iReady News Archives article entitled “iReady Rounding Out Management Team with Two Key Executives”, http://www.ireadyco.com/archives/keyexec.html, 2 pages, printed Nov. 28, 1998.
“Toshiba Delivers First Chips to Make Consumer Devices Internet-Ready Based on iReady's Design,” Press Release Oct. 1998, 3 pages, printed Nov. 28, 1998.
Internet pages from iReady Products, web sitehttp://www.ireadyco.com/products,html, 2 pages, downloaded Nov. 25, 1998.
iReady News Archives, Toshiba, iReady shipping Internet chip, 1 page, printed Nov. 25, 1998.
Interprophet article entitled “Technology”, http://www.interprophet.com/technology.html, 17 pages, printed Mar. 1, 2000.
iReady Corporation, article entitled “The I-1000 Internet Tuner”, 2 pages, date unknown.
iReady article entitled “About Us Introduction”, Internet pages fromhttp://www.iReadyco.com/about.html, 3 pages, printed Nov. 25, 1998.
iReady News Archive article entitled “Revolutionary Approach, to Consumer Electronics Internet Connectivity Funded”, San Jose, CA, Nov. 20, 1997. 2 pages, printed Nov. 2, 1998.
iReady News Archive article entitled “Seiko Instruments Inc. (SII) Introduces World's First Internet-Ready Intelligent LCD Modules Based on iReady Technology,” Santa Clara, CA and Chiba, Japan, Oct. 26, 1998. 2 pages, printed Nov. 2, 1998.
NEWSwatch article entitled “iReady internet Tuner to Web Enable Devices”, Tuesday, Nov. 5, 1996, printed Nov. 2, 1998, 2 pages.
EETimes article entitled “Tuner for Toshiba, Toshiba Taps iReady for Internet Tuner”, by David Lammers, 2 pages, printed Nov. 2, 1998.
“Comparison of Novell Netware and TCP/IP Protocol Architectures”, by J.S. Carbone, 19 pages, printed Apr. 10, 1998.
Adaptec article entitled “AEA-7110C-a DuraSAN product”, 11 pages, printed Oct. 1, 2001.
iSCSI HBA article entitled “iSCSI and 2Gigabit fibre Channel Host Bus Adapters from Emulex, QLogic, Adaptec, JNI”, 8 pages, printed Oct. 1, 2001.
iSCSI HBA article entitled “FCE-3210/6410 32 and 64-bit PCI-to-Fibre Channel HBA”, 6 pages, printed Oct. 1, 2001.
ISCSI.com article entitled “iSCSI Storage”, 2 pages, printed Oct. 1, 2001.
“Two-Way TCP Traffic Over Rate Controlled Channels: Effects and Analysis”, by Kalampoukas et al., IEEE Transactions on Networking, vol. 6, No. 6, Dec. 1998, 17 pages.
IReady News article entitled “Toshiba Delivers First Chips to Make Consumer Devices Internet-Ready Based on iReady Design”, Santa Clara, CA, and Tokyo, Japan, Oct. 14, 1998, printed Nov. 2, 1998, 3 pages.
Internet pages of InterProphet entitled “Frequently Asked Questions”, by Lynne Jolitz, printed Jun. 14, 1999, 4 pages.
“File System Design for an NFS File Server Appliance”, Article by D. Hitz, et al., 13 pages.
Adaptec Press Release article entitled “Adaptec Announces EtherStorage Technology”, 2 pages, May 4, 2000, printed Jun. 14, 2000.
Adaptec article entitled “EtherStorage Frequently Asked Questions”, 5 pages, printed Jul. 19, 2000.
Adaptec article entitled “EtherStorage White Paper”, 7 pages, printed Jul. 19, 2000.
CIBC World Markets article entitled “Computers; Storage”, by J. Berlino et al., 9 pages, dated Aug. 7, 2000.
Merrill Lynch article entitled “Storage Futures”, by S. Milunovich, 22 pages, dated May 10, 2000.
CBS Market Watch article entitled “Montreal Start-Up Battles Data Storage Botttleneck”, by S. Taylor, dated Mar. 5, 2000, 2 pages, printed Mar. 7, 2000.
Internet-draft article entitled “SCSI/TCP (SCSI over TCP)”, by J. Satran et al., 38 pages, dated Feb. 2000, printed May 19, 2000.
Internet pages entitled Technical White Paper—Xpoint's Disk to LAN Acceleration Solution for Windows NT Server, printed Jun. 5, 1997, 15 pages.
Jato Technologies article entitled Network Accelerator Chip Architecture, twelve-slide presentation, printed Aug. 19, 1998, 13 pages.
EETimes article entitled Enterprise System Uses Flexible Spec, dated Aug. 10, 1998, printed Nov. 25, 1998, 3 pages.
Internet pages entitled “Smart Ethernet Network Interface Cards”, which Berend Ozceri is developing, printed Nov. 25, 1998, 2 pages.
Internet pages of Xaqti corporation entitled “GigaPower Protocol Processor Product Review,” printed Nov. 25, 1999, 4 pages.
U.S. Appl. No. 60/283,896, Titled: CRC Calculations for Out of Order PUDs, Filed Apr. 12, 2003, Inventor: Amit Oren, Assignee: Siliquent Technologies Ltd.
Internet pages entitled “DART: Fast Application Level Networking via Data-Copy Avoidance,” by Robert J. Walsh, printed Jun. 3, 1999, 25 pages.
Andrew S. Tanenbaum, Computer Networks, Third Edition, 1996, ISBN 0-13-349945-6.
Article from Rice University entitled “LRP: A New Network Subsystem Architecture for Server Systems”, by Peter Druschel and Gaurav Banga, 14 pages.
Internet RFC/STD/FYI/BCP Archives article with heading “RFC2140” entitled “TCP Control Block Interdependence”, web address http://www.faqs.org/rfcs/rfc2140.html, 9 pages, printed Sep. 20, 2002.
Wind River article entitled “Tornado: For Intelligent Network Acceleration”, copyright Wind River Systems, 2001, 2 pages.
WindRiver White Paper entitled “Complete TCP/IP Offload for High-Speed Ethernet Networks”, Copyright Wind River Systems, 2002, 7 pages.
Intel article entitled “Solving Server Bottlenecks with Intel Server Adapters”, Copyright Intel Corporation, 1999, 8 pages.
Schwaderer et al., IEEE Computer Society Press publication entitled, “XTP in VLSI Protocol Decomposition for ASIC Implementation”, from 15th Conference on Local Computer Networks, 5 pages, Sep. 30-Oct. 3, 1990.
Beach, Bob, IEEE Computer Society Press publication entitled, “UltraNet: An Architecture for Gigabit Networking”, from 15th Conference on Local Computer Networks, 18 pages, Sep. 30-Oct. 3, 1990.
Chesson et al., IEEE Syposium Record entitled, “The Protocol Engine Chipset”, from Hot Chips III, 16 pages, Aug. 26-27, 1991.
Maclean et al., IEEE Global Telecommunications Conference, Globecom '91, presentation entitled, “An Outboard Processor for High Performance Implementation of Transport Layer Protocols”, 7 pages, Dec. 2-5, 1991.
Ross et al., IEEE article entitled “FX1000: A high performance single chip Gigabit Ethernet NIC”, from Compcon '97 Proceedings, 7 pages, Feb. 23-26, 1997.
Strayer et al., “Ch. 9: The Protocol Engine” from XTP: The Transfer Protocol, 12 pages, Jul. 1992.
Publication entitled “Protocol Engine Handbook”, 44 pages, Oct. 1990.
Koufopavlou et al., IEEE Global Telecommunications Conference, Globecom '92, presentation entitled, “Parallel TCP for High Performance Communication Subsystems”, 7 pages, Dec. 6-9, 1992.
Lilienkamp et al., Publication entitled “Proposed Host-Front End Protocol”, 56 pages, Dec. 1984.
Thia et al. Publication entitled “High-Speed OSI Protocol Bypass Algorithm with Window Flow Control,” Protocols for High Speed Networks, pp. 53-68, 1993.
U.S. Appl. No. 60/053,240, Titled: TCP/IP Network Accelerator and Method of Use, Filed Jul. 17, 1997, Inventor: William Jolizt et al.
Thia et al. Publication entitled “A Reduced Operational Protocol Engine (ROPE) for a multiple-layer bypass architecture,” Protocols for High Speed Networks, pp. 224-239, 1995.
Form 10-K for Exelan, Inc., for the fiscal year ending Dec. 31, 1987 (10 pages).
Form 10-K for Exelan, Inc., for the fiscal year ending Dec. 31, 1988 (10 pages).
Starr, David D. et al. “Intelligent Network Storage Interface Device.” U.S. Appl. No. 09/675,700, filed Sep. 29, 2000.
Boucher, Laurence B. et al. “Intelligent Network Interface System and Method for Accelerated Protocol Processing.” U.S. Appl. No. 09/692,561, filed Oct. 18, 2000.
Starr, Daryl D.. et al. “Intelligent Network Storage Interface System.” U.S. Appl. No. 10/261,051, filed Sep. 30, 2002.
Merritt, Rick. “Ethernet Interconnect Outpacing Infiniband at Intel.” EE Times article. Sep. 11, 2002. 9 pages.
Craft, Peter K. et al. “TCP Offload Device that Batches Session Layer Headers to Reduce Interrupts as Well as CPU Copies.” U.S. Appl. No. 12/581,342, filed Oct. 19, 2009.
Craft, Peter K. et al. “TCP Offload Send Optimization.” U.S. Appl. No. 12/504,021, filed Jul. 16, 2009.
Philbrick, Clive M. et al. “Freeing Transmit Memory on a Network Interface Device Prior to Receiving an Acknowledgment That Transmit Data Has Been Received by a Remote Device.” U.S. Appl. No. 12/470,980, filed May 22, 2009.
Starr, Daryl D. et al. “Accelerating Data Transfer in a Virtual Computer System with Tightly Coupled TCP Connections.” U.S. Appl. No. 12/410,366, filed Mar. 24, 2009.
Boucher, Laurence B. et al. “Obtaining a Destination Address So That a Network Interface Device Can Write Network Data Without Headers Directly Into Host Memory.” U.S. Appl. No. 12/325,941, filed Dec. 1, 2008.
Boucher, Laurence B. et al. “Enabling an Enhanced Function of an Electronic Device.” U.S. Appl. No. 11/985,948, filed Nov. 19, 2007.
Starr, Daryl D. et al. “Network Interface Device With 10 Gb/s Full-Duplex Transfer Rate.” U.S. Appl. No. 11/799,720, filed May 1, 2007.
Craft, Peter K. et al. “Peripheral Device That DMAS the Same Data to Different Locations in a Computer.” U.S. Appl. No. 11/788,719, filed Apr. 19, 2007.
Boucher, Laurence B. et al. “TCP/IP Offload Network Interface Device.” U.S. Appl. No. 11/701,705, filed Feb. 2, 2007.
Starr, Daryl D. et al. “TCP/IP Offload Device With Reduced Sequential Processing.” U.S. Appl. No. 11/348,810, filed Feb. 6, 2006.
Craft, Peter K. et al. “Transferring Control of TCP Connections Between Hierarchy of Processing Mechanisms.” U.S. Appl. No. 11/249,006, filed Oct. 11, 2005.
Boucher, Laurence B. et al. “Network Interface Device That Can Transfer Control of a TCP Connection to a Host CPU.” U.S. Appl. No. 11/029,863, filed Jan. 4, 2005.
Craft, Peter K. et al. “Protocol Stack That Offloads a TCP Connection From a Host Computer to a Network Interface Device.” U.S. Appl. No. 11/027,842, filed Dec. 30, 2004.
Craft, Peter K. et al. “Protocol Stack That Offloads a TCP Connection From a Host Computer to a Network Interface Device.” U.S. Appl. No. 11/016,642, filed Dec. 16, 2004.
Boucher, Laurence B. et al. “Method and Apparatus for Dynamic Packet Batching With a High Performance Network Interface.” U.S. Appl. No. 10/678,336, filed Oct. 3, 2003.
Philbrick Clive M. et al. “Method and Apparatus for Data Re-Assembly With a High Performance Network Interface.” U.S. Appl. No. 10/634,062, filed Aug. 4, 2003.
Boucher, Laurence B. et al. “High Network Interface Device and System for Accelerated Communication.” U.S. Appl. No. 10/601,237, filed Jun. 19, 2003.
Boucher, Laurence B. et al. “Method and Apparatus for Distributing Network Traffic Processing on a Multiprocessor Computer.” U.S. Appl. No. 10/438,719, filed May 14, 2003.
Boucher, Laurence B. et al. “Parsing a Packet Header.” U.S. Appl. No. 10/277,604, filed Oct. 18, 2002.
Chandranmenon, Girish P. “Trading Packet Headers for Packet Processing.” IEEE/ACM Transaction on Networking. vol. 4, No. 2. Apr. 1996. pp. 141-152.
Related Publications (1)
Number Date Country
20090234963 A1 Sep 2009 US
Provisional Applications (1)
Number Date Country
60374788 Apr 2002 US
Continuations (1)
Number Date Country
Parent 10413256 Apr 2003 US
Child 12470980 US