US7558873B1 - Method for compressed large send - Google Patents
Method for Internet Protocol Payload Compression (IPComp) and Large Send is described. More particularly, a Large Send initiated by a computer is used to trigger an IPComp negotiation. After agreement on IPComp, data blocks for such a Large Send are compressed in accordance with an agreed upon compression algorithm prior to being divided up into smaller blocks, such as being divided by a maximum transmission unit, for sending. To further improve performance, a intelligent network interface with Large Send and IPComp capabilities is used for offloading Large Send and IPComp functions.
Method for compressed large send Download PDF

Info

Publication number

US7558873B1

US7558873B1 US10/141,039 US14103902A US7558873B1 US 7558873 B1 US7558873 B1 US 7558873B1 US 14103902 A US14103902 A US 14103902A US 7558873 B1 US7558873 B1 US 7558873B1

Authority

US

United States

Prior art keywords

data

computer

payload data

ipcomp

block

Prior art date

2002-05-08

Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)

Expired - Lifetime, expires 2023-10-16

Application number

US10/141,039

Inventor

Thomas Albert Maufer

Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)

Nvidia Corp

Original Assignee

Nvidia Corp

Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)

2002-05-08

Filing date

2002-05-08

Publication date

2009-07-07

2002-05-08 Application filed by Nvidia Corp filed Critical Nvidia Corp

2002-05-08 Priority to US10/141,039 priority Critical patent/US7558873B1/en

2002-08-14 Assigned to NVIDIA CORPORATION reassignment NVIDIA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MAUFER, THOMAS A.

2009-07-07 Application granted granted Critical

2009-07-07 Publication of US7558873B1 publication Critical patent/US7558873B1/en

2023-10-16 Adjusted expiration legal-status Critical

Status Expired - Lifetime legal-status Critical Current

Links

USPTO

USPTO PatentCenter

USPTO Assignment

Espacenet

Global Dossier

Discuss

Images

Classifications

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

H04L69/04—Protocols for data compression, e.g. ROHC

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L63/00—Network architectures or network communication protocols for network security

H04L63/16—Implementing security features at a particular protocol layer

H04L63/164—Implementing security features at a particular protocol layer at the network layer

H—ELECTRICITY

H04—ELECTRIC COMMUNICATION TECHNIQUE

H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION

H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass

H04L69/24—Negotiation of communication capabilities

Definitions

the present invention relates generally to compression with large block send, and more particularly to offloading Internet Protocol Payload Compression with Large Send to a network level.

IP Internet Protocol

IETF Internet Engineering Task Force

IPComp Internet Protocol Payload Compression

IPComp allows systems to negotiate a type of compression for exchanging information prior to encryption.

implementations of IPComp require IPSec-capable computers, because IPComp negotiation is performed using the same negotiation protocol as IPSec, namely, Internet Key Exchange (IKE).

IKE Internet Key Exchange

IPComp relies on IKE, there is no reason that IPComp cannot be used independently of IPSec, without encrypting and/or authenticating communications.

API Application Program Interface

the term API is used to indicate an entire set of programs, definitions, protocols, subroutines, etc. in an interface, as well as indicate any particular program, definition, protocol, subroutine, etc. within an interface.

IPSec Internet Protocol interface card

An intelligent NIC is used to do computationally intensive network stack operations rather than using the host's central processing unit (CPU). This frees up the CPU for other activities.

IPSec out-of-band data is created at an application level and passed down to a NIC for encryption on a packet-by-packet basisâthe IP packet, including IPsec headers in their correct locations in the packet, is given to the intelligent NIC, along with an index (pointer) into the local âSecurity Association Databaseâ, which contains connection-specific data, such as encryption keys and which encryption algorithm is in use for this connection.

an amount of data handed down is equivalent to the largest physical packet size (measured in bytes) that a network interface can transmit, also known as the Maximum Transmission Unit (MTU).

MTU Maximum Transmission Unit

the MTU for an Ethernet interface payload is 1,500 bytes, less overhead such as IP and TCP headers (typically 20 bytes each in the case of IPv4, or 40 bytes and 20 bytes for IPv6 and TCP, respectively), as well as any options in use.

IP and TCP headers typically 20 bytes each in the case of IPv4, or 40 bytes and 20 bytes for IPv6 and TCP, respectively

packets of data may be handed down in blocks of about 1,500 bytes each.

An additional 14 bytes and 4 bytes are appended to such a packet for an Ethernet header and trailer, respectively, and thus maximum packet size for an Ethernet packet is 1,518 bytes.

an Authentication Header (AH) and/or an Encapsulating Security Payload (ESP) header are optionally inserted in a packet, along with an ESP trailerâcontaining the Integrity Check Value (ICV)âif ESP-based Authentication has been negotiated for this connection.

IPComp if IPComp is in use, it will insert a Compression Header (CH) between the IPSec AH and/or ESP headers and the remainder of the packet. The addition of one or more of these headers results in adding more bytes to a packet.

CH Compression Header

An approach to address fragmentation is use of an API for âLarge Send Offloadâ (also known as TCP Segmentation Offload) for the Transmission Control Protocol (TCP).

TCP Transmission Control Protocol

Large Send API supports three component features (which can be used independently or together), namely, TCP Segmentation, TCP Checksum computation, and IP Checksum computation.

a Large Send API is used to refer to one or more APIs for initiating a Large Send.

a network driver is configured to inform a WinSock stack as to an MTU size. So for example, rather than 1,500 bytes for Ethernet, the network driver would indicate an MTU of 64 kilobytes (KB), or a large multiple of the actual packet payload capacity. In response to such configuration information, an application would thus send fewer, larger data blocks to the protocol stackâlarger than can fit into the link's MTU.

NDIS Network Driver Interface Specification

a Network Driver Interface Specification (NDIS) layer provides an exemplary IP and TCP header and a pointer to the large block of data to a NIC driver.

This driver divides up such data into path MTU-sized blocks, less any overhead, and sends out successive packets until the intelligent NIC has consumed the entire data block.

overhead comprises TCP and IP headers totaling 40 bytes, so a 64 KB block of data would be divided as 64,000/1,460, resulting in 43 full packets and one âremainder packetâ.

each packet would have ended up as two fragments, for over 80 total packets.

fewer packets are used, because more packets are fully loaded, such as for example approximately 1,460 bytes of data in each packet except perhaps the last packet, which includes however many bytes that remain after transmitting the rest of the data in the large block.

the initial large data block that is passed to the intelligent NIC includes a prototype TCP/IP header that will be used to build the header for each packet that is sent based on this data.

Each Large Send packet will have a slightly different TCP and IP header provided by the NIC, derived from the prototype header, because for instance, TCP sequence numbers must be incremented by such MTU-sized blocks, e.g., by 1,460 for each packet, and the TCP checksum will be different for each packet, since it depends on the contents of the packet data.

TCP Source and Destination ports will be the same in each derived packet.

the IP Identification field must be different for each unique packet that is sent, and the IP header checksum will be different for each packet as well, if only because the Identification field is different in each derived packet.

the calculation of the TCP checksum (which covers a 96-bit IP pseudo-header, the TCP header, and all TCP packet data) and the calculation of the IP header checksum (which covers the IP version 4 header but does not depend on packet data) are conventionally offloaded to the NIC driver.

each of the packets shares common information too, such as IP source address and IP destination address, among other common information as is known, for example the initial TTL.

APIs for Large Send do not provide support for IPComp.

there is no API that allows an application to request that compression be offloaded to a lower layer entity, such as an NIC or similar component, for Large Send i.e., there is no compression âon/off switchâ for an application (independent of IPSec).

IPComp in the context of Large Send offload capability, by enhancing the Large Send capability with the addition of a simultaneous attempt to negotiate compression, which if successful, would enable the Large Send data blocks to be transmitted using fewer packets.

An aspect of the present invention is a method for communicating application data for a communication session between two computers.

a first portion of the application data is sent in an uncompressed form, where the first portion of the application data is provided by dividing a first large block of data into first smaller blocks of data.

Protocol data is independently sent for determining whether a compression technology may be used, whereby an agreement for use of the compression technology may be established.

a second portion of the application data is sent in a compressed form in response to an agreement to compress.

the second portion of the application data is provided by compressing a subsequent large block of data to provide a compressed smaller block of data.

the compression may be applied to the whole large block, or to each individual smaller block.

Another aspect of the present invention is a method for compressed Large Send.

An intelligent network interface with Large Send and Internet Protocol Payload Compression capabilities is provided.

a Large Send Application Protocol Interface (API) is initiated.

Processing of uncompressed payload data by the network interface is initiated in response to the Large Send API, and an Internet Key Exchange API is initiated in response to the Large Send API (though the IKE negotiation is not specifically requested by the Large Send API).

An Internet Protocol Payload Compression negotiation is initiated through usage of the Internet Key Exchange protocol.

a portion of the uncompressed payload data is compressed to provide a compressed data portion.

the compressed data portion is sectioned to provide compressed data subsections.

FIG. 1 is a block diagram of an exemplary embodiment of a computer system in accordance with one or more aspects of the present invention.

FIG. 2 is a block diagram of an exemplary embodiment of a network in accordance with one or more aspects of the present invention.

FIG. 3 is a process flow diagram for an exemplary embodiment of a communication process between two or more computer systems in accordance with one or more aspects of the present invention.

Computer system 10 comprises CPU 11 , system memory 13 , input/output (I/O) interface 12 , and nVidia's Media and Communications Processor (MCP) 199 or another intelligent NIC.

MCP 199 may be coupled for I/O from/to a network 300 .

MCP 199 is an intelligent NIC, and thus supports Large Send capability 101 , as indicated.

MCP 199 supports IPComp capability 100 . Though IPComp capability 100 may be embodied in software to be executed by CPU 11 , this would reduce a performance advantage gained by offloading IPComp to MCP 199 .

Network 300 comprises computer systems 200 coupled to one another via WAN 301 and LANs 302 and 303 .

computer systems 200 -G serve as gateways for LANs 302 and 303 .

two computers may be in communication with one another without a LAN, such as two computers communicating with one another directly over the Internet.

a receiving computer it is not necessary that a receiving computer have an intelligent NIC.

FIG. 3 there is shown a process flow diagram for an exemplary embodiment of a communication process 310 between two or more computer systems, where the sending computer system comprises a MCP 199 shown in FIG. 1 in accordance with one or more aspects of the present invention.

a Large Send API is instantiated in an IP stack.

An API such as a Windows API for Large Send, may be used.

large data blocks of approximately 64 KB will be sent from an application layer to a network layer in a protocol stack.

a network driver for MCP 199 having Large Send capability, breaks such blocks up into MTU sized blocks, such as approximately 1.5 KB each, for transmission.

Initiation of a Large Send API is used to start sending data in a conventional manner at step 312 . Transmission of data at this point is still in an uncompressed format.

the Large Send API may be modified to use even lager data blocks.

IKE negotiation is also used to initiate at step 313 an IPSec packet for IKE negotiation using an IPSec API.

IKE packet may be sent interleaved or pipelined with data being sent for the Large Send.

IPSec negotiation must result in an agreement to do authentication and/or encryption, otherwise data may not be sent. Rather, IPSec negotiation is used to enable access to IPComp negotiation with a receiving computer.

IPComp negotiation takes place.

IPComp capability 100 may be part of MCP 199 or part of application software.

step 313 may be omitted, and a Large Send request to MCP 199 may be used to trigger IPComp capability 100 .

Step 312 can proceed in an interleaved manner (essentially, in parallel) with step 313 and/or step 314 , so these steps should not be regarded as sequentially related.

IPComp capability 100 may be embodied in hardware and/or firmware of MCP 199 .

MCP 199 has IPComp capability, IPComp may be transparently done with respect to an operating system of a sending computer other than initiation of a Large Send API.

IPComp negotiation is successful, namely, a compression algorithm is agreed upon between a sending computer and at least one receiving computer, then a data compression mode will be used.

multicasting may be used with a compressed Large Send as described herein. For multicasting, agreement between a sending computer and receiving computers for compression is needed, and thus transmission of data, whether uncompressed or compressed, is to such receiving computers.

a block of data currently being processed after IPComp negotiation is completed may be sent in an uncompressed manner.

a conventional Compression Parameter Index (CPI) is provided as part of the IPComp Compression Header, or CH. Nicely, a receiving computer in receipt of a packet without a CPI will simply process received data as uncompressed.

a next large block of data is obtained. Because larger blocks of data, such as 64 KB blocks, may be compressed, compression efficiency is improved over compressing smaller blocks of data, such as 1.5 KB blocks. If block-level compression is not negotiated, packet-by-packet compression may also be used, with slightly worse efficiency. Since better compression ratios conventionally are achieved when applying a compression algorithm to a larger block of data, use of Large Send in combination with block-level compression would be advantageous. Thus, continuing the above example, a 64K block may be compressed down to 48K to 54K for example prior to dividing into 1.5K blocks for transmission, where approximately each 1.5 KB reduction is one less packet to be transmitted. Notably, by using compression, fewer packets may be used to send data to enhance system performance and reduce transmission bandwidth consumption.

a block of data is not very compressible, so an optional threshold check at step 319 is used. If compression of a block of data is not reduced by at least a certain threshold percentage, then MCP 199 may avoid compression to avoid a performance penalty for decompression by a receiving computer. For example, a compression result of approximately 3% or less reduction in size, such as from 64K down to about 60K or more, may be insufficient to merit compression. If a compressibility threshold is not met, such a block is not sent in compressed form; rather, conventional Large Send processing takes place on such a block at step 320 .

MCP 199 inserts an IPComp Compression Header for transmitting IPComp-compressed packets, as well as modifying other packet related information.

MCP 199 receives an IP packet for transmission, and when IPComp is in effect for that transmission flow, the IP header must be modified.

IPComp is inserted, also IPv4 Length and IPv6 Payload Length fields may no longer be correct so they will have to be modified, and an IPv4 header checksum will need to be re-calculated (for the final packet, intermediate packets will retain their original length, by inserting the Compression Header and then taking fewer bytes of compressed data to compensate for the additional bytes consumed by the IPComp headerâresulting in a packet that is the same size as one that would be sent by Large Send without IPComp). IPComp is compatible with both IPv4 and IPv6, so modifications to such headers are similar.

a Total Length field is changed to reflect a change in length of an IP packet, including IP header, inserted IPComp header, and length of compressed payload.

IPv6 a Payload Length field is modified to reflect length of compressed data in addition to an inserted IPComp header.

An IPv4 Protocol field or an IPv6 Next Header field, as applicable, is changed from an old value to a value that indicates the presence of the Compression Header. The old value is remembered for use in an inserted IPComp header. When necessary, an IPv4 header checksum is calculated.

IPComp header A receiving computer must be able to remove such IPComp header.

a known number of bytes are held in reserve. For example, an IPComp header is 4 bytes, so payload compression must reserve 4 bytes per Large Send to ensure such an IPComp header is not fragmented from such a Large Send.

a CPI field is used along with an IP Destination Address field to identify a compression algorithm in use. As stated above, it is possible to use IKE to negotiate compression associations, namely, agreement on a compression algorithm, independent of IPSec.

IPComp does not mandate a default compression algorithm or transform.

MCP 199 is configured to do compression

CPU time is not consumed for compressing data at step 321 .

Large Send capability may be combined with multicasting capability of MCP 199 for doing a multicast Large Send with compressed data at step 321 .

Some embodiments of the present invention are program products that may reside in whole or in part in local memory 102 of MCP 199 and/or system memory 13 .

memory may be sufficient to hold at least a portion of communication process 310 in accordance with one or more embodiments of the present invention.

Memory may comprise volatile and/or non-volatile memory, including but not limited to magnetically readable memory (e.g., floppy disk, hard disk, and the like), optically readable memory (e.g., CD-ROM, -RW, DVD-ROM, -RAM, and the like), and electrically readable memory (e.g., DRAM, SRAM, EEPROM, registers, latches, and the like).

some embodiments of the invention are program products containing machine-readable programs.

the program(s) of the program product defines functions of the embodiments and can be contained on a variety of signal/bearing media, which include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications.

a communications medium such as through a computer or telephone network, including wireless communications.

the latter embodiment specifically includes information downloaded from the Internet and other networks.

Such signal-bearing media when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

data may be converted from being sent in an uncompressed form to being sent in a compressed form and vice versa within the middle of such a communication session.

IPComp negotiation is conducted in parallel with the transmission of data, latency of data transmission is reduced as compared with IPSec wherein agreement must be completed first prior to sending data in an encrypted form.

a NIC in a sending computer of communicating computers combines Large Send and compression without need for operating system intervention and without need for CPU usage. Offloading compression of large blocks to a NIC is a significant performance enhancement (due to further reduction in CPU utilization) in addition to having to send fewer packets.

Landscapes

Engineering & Computer Science (AREA)

Computer Security & Cryptography (AREA)

Computer Networks & Wireless Communication (AREA)

Signal Processing (AREA)

Computer Hardware Design (AREA)

Computing Systems (AREA)

General Engineering & Computer Science (AREA)

Data Exchanges In Wide-Area Networks (AREA)

Abstract

Method for Internet Protocol Payload Compression (IPComp) and Large Send is described. More particularly, a Large Send initiated by a computer is used to trigger an IPComp negotiation. After agreement on IPComp, data blocks for such a Large Send are compressed in accordance with an agreed upon compression algorithm prior to being divided up into smaller blocks, such as being divided by a maximum transmission unit, for sending. To further improve performance, a intelligent network interface with Large Send and IPComp capabilities is used for offloading Large Send and IPComp functions.

Description

FIELD OF THE INVENTION

The present invention relates generally to compression with large block send, and more particularly to offloading Internet Protocol Payload Compression with Large Send to a network level.

BACKGROUND OF THE INVENTION

The Internet remains a growing public network. Many companies rely on communication over the Internet using Internet Protocol (IP) to facilitate their business endeavors. However, public access also comes along with security risks. To address enhancement of security on the Internet, the Internet Engineering Task Force (IETF) proposed Internet Protocol Security (IPSec). IPSec is designed to provide authentication and encryption for communication over insecure networks, such as the Internet. However, once a packet is encrypted it cannot be compressed. Modems with built-in compression, such as V.42 for example, cannot compress an encrypted packet (due to the randomization of the data when it is encrypted), and thus throughput of such modems was slowed. Accordingly, the IETF proposed Internet Protocol Payload Compression (IPComp) to move compression up in the protocol stack, so that it can happen prior to encryption (instead of at the link level, below IP, as in modems).

IPComp allows systems to negotiate a type of compression for exchanging information prior to encryption. Unfortunately, implementations of IPComp require IPSec-capable computers, because IPComp negotiation is performed using the same negotiation protocol as IPSec, namely, Internet Key Exchange (IKE). Even though, IPComp relies on IKE, there is no reason that IPComp cannot be used independently of IPSec, without encrypting and/or authenticating communications. Unfortunately, in the Microsoft Windows Operating System, there is no Application Program Interface (API) for independently off-loading data for IPComp in operating systems (independently of IPSec, that is). Hereinafter, the term API is used to indicate an entire set of programs, definitions, protocols, subroutines, etc. in an interface, as well as indicate any particular program, definition, protocol, subroutine, etc. within an interface.

There is an API for offloading IPSec to an intelligent network interface (sometimes referred to as a ânetwork interface cardâ or âNICâ). An intelligent NIC is used to do computationally intensive network stack operations rather than using the host's central processing unit (CPU). This frees up the CPU for other activities. For offloading IPSec, IPSec out-of-band data is created at an application level and passed down to a NIC for encryption on a packet-by-packet basisâthe IP packet, including IPsec headers in their correct locations in the packet, is given to the intelligent NIC, along with an index (pointer) into the local âSecurity Association Databaseâ, which contains connection-specific data, such as encryption keys and which encryption algorithm is in use for this connection.

At the high side, an amount of data handed down is equivalent to the largest physical packet size (measured in bytes) that a network interface can transmit, also known as the Maximum Transmission Unit (MTU). For example, the MTU for an Ethernet interface payload is 1,500 bytes, less overhead such as IP and TCP headers (typically 20 bytes each in the case of IPv4, or 40 bytes and 20 bytes for IPv6 and TCP, respectively), as well as any options in use. If Ethernet is used, packets of data may be handed down in blocks of about 1,500 bytes each. An additional 14 bytes and 4 bytes are appended to such a packet for an Ethernet header and trailer, respectively, and thus maximum packet size for an Ethernet packet is 1,518 bytes.

In IPSec, an Authentication Header (AH) and/or an Encapsulating Security Payload (ESP) header are optionally inserted in a packet, along with an ESP trailerâcontaining the Integrity Check Value (ICV)âif ESP-based Authentication has been negotiated for this connection. Additionally, if IPComp is in use, it will insert a Compression Header (CH) between the IPSec AH and/or ESP headers and the remainder of the packet. The addition of one or more of these headers results in adding more bytes to a packet. Continuing the above example for Ethernet, if payload handed down from an application level to a network interface level is 1,460 bytes, such a packet payload may have to be broken up or fragmented for transmission after the extra headers needed by IPSec, or IPSec and IPComp. However, the hope is that with IPComp, the packet payload will be reduced sufficiently to accommodate the additional headers and all of the original payload. Fragmentation should be avoided, if possible, because performance suffers, since fragmented packets will not have maximum payload usage.

An approach to address fragmentation is use of an API for âLarge Send Offloadâ (also known as TCP Segmentation Offload) for the Transmission Control Protocol (TCP). There are Large Send API supports three component features (which can be used independently or together), namely, TCP Segmentation, TCP Checksum computation, and IP Checksum computation. For purposes of clarity, a Large Send API is used to refer to one or more APIs for initiating a Large Send. For Large Send offloads, a network driver is configured to inform a WinSock stack as to an MTU size. So for example, rather than 1,500 bytes for Ethernet, the network driver would indicate an MTU of 64 kilobytes (KB), or a large multiple of the actual packet payload capacity. In response to such configuration information, an application would thus send fewer, larger data blocks to the protocol stackâlarger than can fit into the link's MTU.

Continuing the above example, data would be sent down to a NIC in blocks of approximately 64 KB. For a NIC with Large Send capacity, namely an intelligent NIC, a Network Driver Interface Specification (NDIS) layer provides an exemplary IP and TCP header and a pointer to the large block of data to a NIC driver. This driver divides up such data into path MTU-sized blocks, less any overhead, and sends out successive packets until the intelligent NIC has consumed the entire data block. Continuing the above example, if no options are used, overhead comprises TCP and IP headers totaling 40 bytes, so a 64 KB block of data would be divided as 64,000/1,460, resulting in 43 full packets and one âremainder packetâ. If fragmentation had been necessary, each packet would have ended up as two fragments, for over 80 total packets. Thus, fewer packets are used, because more packets are fully loaded, such as for example approximately 1,460 bytes of data in each packet except perhaps the last packet, which includes however many bytes that remain after transmitting the rest of the data in the large block.

The initial large data block that is passed to the intelligent NIC includes a prototype TCP/IP header that will be used to build the header for each packet that is sent based on this data. Each Large Send packet will have a slightly different TCP and IP header provided by the NIC, derived from the prototype header, because for instance, TCP sequence numbers must be incremented by such MTU-sized blocks, e.g., by 1,460 for each packet, and the TCP checksum will be different for each packet, since it depends on the contents of the packet data. However the TCP Source and Destination ports will be the same in each derived packet. At the IP layer, the IP Identification field must be different for each unique packet that is sent, and the IP header checksum will be different for each packet as well, if only because the Identification field is different in each derived packet. Additionally, the calculation of the TCP checksum (which covers a 96-bit IP pseudo-header, the TCP header, and all TCP packet data) and the calculation of the IP header checksum (which covers the IP version 4 header but does not depend on packet data) are conventionally offloaded to the NIC driver. However, as noted above, each of the packets shares common information too, such as IP source address and IP destination address, among other common information as is known, for example the initial TTL.

However, APIs for Large Send do not provide support for IPComp. In fact, there is no API that allows an application to request that compression be offloaded to a lower layer entity, such as an NIC or similar component, for Large Send, i.e., there is no compression âon/off switchâ for an application (independent of IPSec). Accordingly, it would be desirable and useful to provide IPComp in the context of Large Send offload capability, by enhancing the Large Send capability with the addition of a simultaneous attempt to negotiate compression, which if successful, would enable the Large Send data blocks to be transmitted using fewer packets.

SUMMARY OF THE INVENTION

An aspect of the present invention is a method for communicating application data for a communication session between two computers. A first portion of the application data is sent in an uncompressed form, where the first portion of the application data is provided by dividing a first large block of data into first smaller blocks of data. Protocol data is independently sent for determining whether a compression technology may be used, whereby an agreement for use of the compression technology may be established. A second portion of the application data is sent in a compressed form in response to an agreement to compress. The second portion of the application data is provided by compressing a subsequent large block of data to provide a compressed smaller block of data. The compression may be applied to the whole large block, or to each individual smaller block.

Another aspect of the present invention is a method for compressed Large Send. An intelligent network interface with Large Send and Internet Protocol Payload Compression capabilities is provided. A Large Send Application Protocol Interface (API) is initiated. Processing of uncompressed payload data by the network interface is initiated in response to the Large Send API, and an Internet Key Exchange API is initiated in response to the Large Send API (though the IKE negotiation is not specifically requested by the Large Send API). An Internet Protocol Payload Compression negotiation is initiated through usage of the Internet Key Exchange protocol. In response to successful conclusion of the Internet Protocol Payload Compression negotiation, a portion of the uncompressed payload data is compressed to provide a compressed data portion. The compressed data portion is sectioned to provide compressed data subsections.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features, advantages and objects of the present invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.

FIG. 1 is a block diagram of an exemplary embodiment of a computer system in accordance with one or more aspects of the present invention.

FIG. 2 is a block diagram of an exemplary embodiment of a network in accordance with one or more aspects of the present invention.

FIG. 3 is a process flow diagram for an exemplary embodiment of a communication process between two or more computer systems in accordance with one or more aspects of the present invention.

It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the present invention may admit to other equally effective embodiments.

DETAILED DESCRIPTION OF THE DRAWINGS

In the following description, numerous specific details are set forth to provide a more thorough understanding of the present invention. However, it will be apparent to one of skill in the art that the present invention may be practiced without one or more of these specific details. In other instances, well-known features have not been described in order to avoid obscuring the present invention.

Referring to FIG. 1, there is shown a block diagram of an exemplary embodiment of a computer system 10 in accordance with one or more aspects of the present invention. Computer system 10 comprises CPU 11, system memory 13, input/output (I/O) interface 12, and nVidia's Media and Communications Processor (MCP) 199 or another intelligent NIC. MCP 199 may be coupled for I/O from/to a network 300. MCP 199 is an intelligent NIC, and thus supports Large Send capability 101, as indicated. Additionally, MCP 199 supports IPComp capability 100. Though IPComp capability 100 may be embodied in software to be executed by CPU 11, this would reduce a performance advantage gained by offloading IPComp to MCP 199.

Referring to FIG. 2, there is shown a block diagram of an exemplary embodiment of a network 300 in accordance with one or more aspects of the present invention. Network 300 comprises computer systems 200 coupled to one another via WAN 301 and LANs 302 and 303. Notably, computer systems 200-G serve as gateways for LANs 302 and 303. However, two computers may be in communication with one another without a LAN, such as two computers communicating with one another directly over the Internet. Notably, it is not necessary that a receiving computer have an intelligent NIC.

In FIG. 3, there is shown a process flow diagram for an exemplary embodiment of a communication process 310 between two or more computer systems, where the sending computer system comprises a MCP 199 shown in FIG. 1 in accordance with one or more aspects of the present invention. At step 311, a Large Send API is instantiated in an IP stack. An API, such as a Windows API for Large Send, may be used. Thus, continuing the above example, large data blocks of approximately 64 KB will be sent from an application layer to a network layer in a protocol stack. Accordingly, a network driver for MCP 199, having Large Send capability, breaks such blocks up into MTU sized blocks, such as approximately 1.5 KB each, for transmission. Initiation of a Large Send API is used to start sending data in a conventional manner at step 312. Transmission of data at this point is still in an uncompressed format. The Large Send API may be modified to use even lager data blocks.

Initiation of such a Large Send API is also used to initiate at step 313 an IPSec packet for IKE negotiation using an IPSec API. Such an IKE packet may be sent interleaved or pipelined with data being sent for the Large Send. Notably, IPSec negotiation must result in an agreement to do authentication and/or encryption, otherwise data may not be sent. Rather, IPSec negotiation is used to enable access to IPComp negotiation with a receiving computer.

At step 314, IPComp negotiation takes place. Again, IPComp capability 100 may be part of MCP 199 or part of application software. Notably, if IPComp negotiation can be accessed without first enabling IPSec negotiation, step 313 may be omitted, and a Large Send request to MCP 199 may be used to trigger IPComp capability 100. Step 312 can proceed in an interleaved manner (essentially, in parallel) with step 313 and/or step 314, so these steps should not be regarded as sequentially related. Notably, IPComp capability 100 may be embodied in hardware and/or firmware of MCP 199. Also, because MCP 199 has IPComp capability, IPComp may be transparently done with respect to an operating system of a sending computer other than initiation of a Large Send API.

At step 315, a check is made to determine if IPComp negotiation resulted in an agreement to compress using an agreed upon compression algorithm. If IPComp negotiation is unsuccessful, data continues to be sent in an uncompressed form, as indicated at step 316.

However, if IPComp negotiation is successful, namely, a compression algorithm is agreed upon between a sending computer and at least one receiving computer, then a data compression mode will be used. Notably, multicasting may be used with a compressed Large Send as described herein. For multicasting, agreement between a sending computer and receiving computers for compression is needed, and thus transmission of data, whether uncompressed or compressed, is to such receiving computers.

Optionally, at step 317, a block of data currently being processed after IPComp negotiation is completed may be sent in an uncompressed manner. A conventional Compression Parameter Index (CPI) is provided as part of the IPComp Compression Header, or CH. Nicely, a receiving computer in receipt of a packet without a CPI will simply process received data as uncompressed.

At step 318, a next large block of data is obtained. Because larger blocks of data, such as 64 KB blocks, may be compressed, compression efficiency is improved over compressing smaller blocks of data, such as 1.5 KB blocks. If block-level compression is not negotiated, packet-by-packet compression may also be used, with slightly worse efficiency. Since better compression ratios conventionally are achieved when applying a compression algorithm to a larger block of data, use of Large Send in combination with block-level compression would be advantageous. Thus, continuing the above example, a 64K block may be compressed down to 48K to 54K for example prior to dividing into 1.5K blocks for transmission, where approximately each 1.5 KB reduction is one less packet to be transmitted. Notably, by using compression, fewer packets may be used to send data to enhance system performance and reduce transmission bandwidth consumption.

However, it is possible that a block of data is not very compressible, so an optional threshold check at step 319 is used. If compression of a block of data is not reduced by at least a certain threshold percentage, then MCP 199 may avoid compression to avoid a performance penalty for decompression by a receiving computer. For example, a compression result of approximately 3% or less reduction in size, such as from 64K down to about 60K or more, may be insufficient to merit compression. If a compressibility threshold is not met, such a block is not sent in compressed form; rather, conventional Large Send processing takes place on such a block at step 320.

However, if a compressibility threshold is met at step 319, then at step 321 MCP 199 inserts an IPComp Compression Header for transmitting IPComp-compressed packets, as well as modifying other packet related information. When MCP 199 receives an IP packet for transmission, and when IPComp is in effect for that transmission flow, the IP header must be modified. As mentioned above, an IPComp header is inserted, also IPv4 Length and IPv6 Payload Length fields may no longer be correct so they will have to be modified, and an IPv4 header checksum will need to be re-calculated (for the final packet, intermediate packets will retain their original length, by inserting the Compression Header and then taking fewer bytes of compressed data to compensate for the additional bytes consumed by the IPComp headerâresulting in a packet that is the same size as one that would be sent by Large Send without IPComp). IPComp is compatible with both IPv4 and IPv6, so modifications to such headers are similar. For IPv4, a Total Length field is changed to reflect a change in length of an IP packet, including IP header, inserted IPComp header, and length of compressed payload. In IPv6, a Payload Length field is modified to reflect length of compressed data in addition to an inserted IPComp header. An IPv4 Protocol field or an IPv6 Next Header field, as applicable, is changed from an old value to a value that indicates the presence of the Compression Header. The old value is remembered for use in an inserted IPComp header. When necessary, an IPv4 header checksum is calculated.

A receiving computer must be able to remove such IPComp header. To avoid fragmentation, a known number of bytes are held in reserve. For example, an IPComp header is 4 bytes, so payload compression must reserve 4 bytes per Large Send to ensure such an IPComp header is not fragmented from such a Large Send. A CPI field is used along with an IP Destination Address field to identify a compression algorithm in use. As stated above, it is possible to use IKE to negotiate compression associations, namely, agreement on a compression algorithm, independent of IPSec. Alternatively, negotiation between two or more IP endpoints or network nodes of a CPI value, and thus an associated compression transform for such endpoints, may ride upon an existing IKE session being used for IPSec Security Association (SA) negotiations between such endpoints. As is known, CPI values of 0-63 are reserved for well-known compression algorithms, of which values 0-4 have been allocated as set forth in Table I. Notably, IPComp does not mandate a default compression algorithm or transform. Thus, if two IPComp-capable nodes do not have at least one common transform, they will not be able to exchange compressed data using IPComp.

TABLE I Transform Identification Value RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 IPCOMP_LZS 3 IPCOMP_LZJH (V.44) 4

Moreover, as MCP 199 is configured to do compression, CPU time is not consumed for compressing data at step 321. Furthermore, Large Send capability may be combined with multicasting capability of MCP 199 for doing a multicast Large Send with compressed data at step 321.

Some embodiments of the present invention are program products that may reside in whole or in part in local memory 102 of MCP 199 and/or system memory 13. By way of example and not limitation, memory may be sufficient to hold at least a portion of communication process 310 in accordance with one or more embodiments of the present invention. Memory may comprise volatile and/or non-volatile memory, including but not limited to magnetically readable memory (e.g., floppy disk, hard disk, and the like), optically readable memory (e.g., CD-ROM, -RW, DVD-ROM, -RAM, and the like), and electrically readable memory (e.g., DRAM, SRAM, EEPROM, registers, latches, and the like). Accordingly, some embodiments of the invention are program products containing machine-readable programs. The program(s) of the program product defines functions of the embodiments and can be contained on a variety of signal/bearing media, which include, but are not limited to: (i) information permanently stored on non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) alterable information stored on writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); or (iii) information conveyed to a computer by a communications medium, such as through a computer or telephone network, including wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

It should be appreciated that within a communication session data may be converted from being sent in an uncompressed form to being sent in a compressed form and vice versa within the middle of such a communication session. Because IPComp negotiation is conducted in parallel with the transmission of data, latency of data transmission is reduced as compared with IPSec wherein agreement must be completed first prior to sending data in an encrypted form. Moreover, it should be appreciated that a NIC in a sending computer of communicating computers combines Large Send and compression without need for operating system intervention and without need for CPU usage. Offloading compression of large blocks to a NIC is a significant performance enhancement (due to further reduction in CPU utilization) in addition to having to send fewer packets.

While foregoing is directed to the preferred embodiment of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow. All trademarks are the respective property of their owners. Claims listing steps do not imply any order of the steps.

Claims (16)

1. A method for communicating payload data utilizing Internet Protocol Security (IPSec) and Internet Protocol Compression (IPComp) within a communication session between a first computer and a second computer independent of operating system intervention, the method comprising:

sending a first portion of the payload data in an uncompressed form from the first computer to the second computer, the first portion of the payload data provided by:

obtaining a first block of the payload data, and

dividing the first block into blocks of uncompressed data, wherein each of the blocks of uncompressed data is transmitted during the communication session;

simultaneously with sending the first portion of the payload data, independently sending protocol data from the first computer to the second computer for determining whether IPComp negotiation between the first computer and the second computer resulted in an agreement to compress subsequent data using an agreed upon compression algorithm;

if IPComp negotiation is successful, then:

establishing an agreement between the first computer and the second computer to transmit data using a data compression mode, and

sending a second portion of the payload data in the compressed form from the first computer to the second computer, wherein the second portion of the payload data comprises a data size that is at least a multiple of an Internet Protocol (IP) packet capacity, and the second portion of the payload data being provided by:

obtaining a second block of the payload data,

compressing the second block of the payload data according to the IPComp to provide compressed data block, wherein the compressed second block is smaller in data size relative to the second block,

dividing the compressed second block into smaller blocks of compressed data, wherein each of the smaller blocks of compressed data comprises a data size within the IP packet capacity and is transmitted during the communication session,

applying the IPSec to each of the smaller blocks of compressed data, and

transmitting the smaller blocks of compressed data to the second computer without the operating system intervening; and

if IPComp negotiation is unsuccessful, then transmitting the payload data in an uncompressed form.

2. The method of claim 1, further comprising checking the compressibility of the second block of the payload data to determine whether the second block of the payload data meets a compressibility threshold to avoid compressing data where a performance penalty would be incurred.

3. The method of claim 1, wherein the first portion of the payload data is either interleaved or pipelined with the protocol data.

4. The method of claim 1, wherein the sending of the protocol data is done independently of any operating system associated with the first computer and the second computer.

5. The method of claim 1, wherein the first portion of the payload data and the second portion of the payload data are respective portions of a Large Send.

6. The method of claim 1, wherein the protocol data comprises negotiation protocol information.

7. The method of claim 1, wherein the payload data comprises application data.

8. The method of claim 5, wherein the steps of sending the first portion of the payload data and the second portion of the payload data comprise multicasting the first portion of the payload data and the second portion of the payload data.

9. The method of claim 6, wherein the negotiation protocol information comprises Internet Protocol Security packet for Internet Key Exchange negotiation.

10. Computer-readable storage medium storing instructions that, when executed by processor, cause a computer system to communicate payload data utilizing Internet Protocol Security (IPSec) and Internet Protocol Compression (IPComp) within a communication session between a first computer and a second computer independent of operating system intervention, by performing the steps of:

sending a first portion of the payload data in an uncompressed form from the first computer to the second computer, the first portion of the payload data provided by:

obtaining a first block of the payload data, and

dividing the first block into blocks of uncompressed data, wherein each of the blocks of uncompressed data is transmitted during the communication session;

simultaneously with sending the first portion of the payload data, independently sending protocol data from the first computer to the second computer for determining whether IPComp negotiation between the first computer and the second computer resulted in an agreement to compress subsequent data using an agreed upon compression algorithm;

if IPComp negotiation is successful, then:

establishing an agreement between the first computer and the second computer to transmit data using a data compression mode, and

sending a second portion of the payload data in the compressed form from the first computer to the second computer, wherein the second portion of the payload data comprises a data size that is at least a multiple of an Internet Protocol (IP) packet capacity, and the second portion of the payload data being provided by:

obtaining a second block of the payload data,

compressing the second block of the payload data according to the IPComp to provide compressed data block, wherein the compressed second block is smaller in data size relative to the second block,

dividing the compressed second block into smaller blocks of compressed data, wherein each of the smaller blocks of compressed data comprises a data size within the IP packet capacity and is transmitted during the communication session,

applying the IPSec to each of the smaller blocks of compressed data, and transmitting the smaller blocks of compressed data to the second computer without the operating system intervening; and

if IPComp negotiation is unsuccessful, then transmitting the payload data in an uncompressed form.

11. The computer-readable storage medium of claim 10, wherein the sending of the first portion of the payload data is interleaved with the sending of the protocol data.

12. The computer-readable storage medium of claim 10, wherein the sending of the protocol data is done independently of any operating system associated with the processor.

13. The computer-readable storage medium of claim 10, wherein the protocol data comprises negotiation protocol information.

14. The computer-readable storage medium of claim 10, wherein the payload data comprises application data.

15. The computer-readable storage medium of claim 10, wherein the sending of the first portion of the payload data is pipelined with the sending of the protocol data.

16. The computer-readable storage medium of claim 13, wherein the negotiation protocol information comprises Internet Protocol Security packet for Internet Key Exchange negotiation.

US10/141,039 2002-05-08 2002-05-08 Method for compressed large send Expired - Lifetime US7558873B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title US10/141,039 US7558873B1 (en) 2002-05-08 2002-05-08 Method for compressed large send

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title US10/141,039 US7558873B1 (en) 2002-05-08 2002-05-08 Method for compressed large send

Publications (1)

Publication Number Publication Date US7558873B1 true US7558873B1 (en) 2009-07-07

Family

ID=40811124

Family Applications (1)

Application Number Title Priority Date Filing Date US10/141,039 Expired - Lifetime US7558873B1 (en) 2002-05-08 2002-05-08 Method for compressed large send

Country Status (1)

Country Link US (1) US7558873B1 (en)

Cited By (7)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US20070071034A1 (en) * 2005-09-27 2007-03-29 Intel Corporation Mechanisms for data rate improvement in a wireless network US20090052452A1 (en) * 2007-08-23 2009-02-26 Keyur Patel Signaling compression information using routing protocols US20100115137A1 (en) * 2008-11-05 2010-05-06 Samsung Electronics Co., Ltd. Data compression method and data communication system utilizing the same US8472469B2 (en) 2010-09-10 2013-06-25 International Business Machines Corporation Configurable network socket aggregation to enable segmentation offload US20140258438A1 (en) * 2013-03-10 2014-09-11 Mellanox Technologies Ltd. Network interface controller with compression capabilities CN105723342A (en) * 2013-11-12 2016-06-29 ä¸æçµå­æ ªå¼ä¼ç¤¾ Apparatus and method for processing security packet in electronic device US9723091B1 (en) * 2012-11-09 2017-08-01 Noble Systems Corporation Variable length protocol using serialized payload with compression support

Citations (79)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US5742773A (en) 1996-04-18 1998-04-21 Microsoft Corporation Method and system for audio compression negotiation for multiple channels US5826027A (en) 1995-10-11 1998-10-20 Citrix Systems, Inc. Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system US5884025A (en) 1995-05-18 1999-03-16 Sun Microsystems, Inc. System for packet filtering of data packet at a computer network interface WO1999035799A2 (en) 1997-12-31 1999-07-15 Ssh Communications Security Oy A method for packet authentication in the presence of network address translations and protocol conversions US6032253A (en) 1998-06-15 2000-02-29 Cisco Technology, Inc. Data processor with multiple compare extension instruction US6047325A (en) 1997-10-24 2000-04-04 Jain; Lalit Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks US6055236A (en) 1998-03-05 2000-04-25 3Com Corporation Method and system for locating network services with distributed network address translation US6094485A (en) 1997-09-18 2000-07-25 Netscape Communications Corporation SSL step-up US6101170A (en) 1996-09-27 2000-08-08 Cabletron Systems, Inc. Secure fast packet switch having improved memory utilization WO2000056034A1 (en) 1999-03-17 2000-09-21 3Com Corporation Method and system for distributed network address translation with network security features US6141705A (en) * 1998-06-12 2000-10-31 Microsoft Corporation System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when needed US6189102B1 (en) 1998-05-27 2001-02-13 3Com Corporation Method for authentication of network devices in a data-over cable system US6215907B1 (en) * 1998-06-26 2001-04-10 Fisher-Rosemont Systems, Inc. Recursive on-line wavelet data compression technique for use in data storage and communications US6275588B1 (en) * 1998-11-12 2001-08-14 I-Data International A/S Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network EP1130846A2 (en) 2000-03-03 2001-09-05 Nexland, Inc. Network address translation gateway WO2001076191A1 (en) 2000-03-31 2001-10-11 Microsoft Corporation Proxy network address translation US6304573B1 (en) * 1997-04-03 2001-10-16 At&T Corp. Method and apparatus for transmitting and receiving electronic voice messages US20010032254A1 (en) * 1998-05-29 2001-10-18 Jeffrey C. Hawkins Method and apparatus for wireless internet access US20010038642A1 (en) * 1999-01-29 2001-11-08 Interactive Silicon, Inc. System and method for performing scalable embedded parallel data decompression US6327660B1 (en) 1998-09-18 2001-12-04 Intel Corporation Method for securing communications in a pre-boot environment US20010054131A1 (en) * 1999-01-29 2001-12-20 Alvarez Manuel J. System and method for perfoming scalable embedded parallel data compression US20020009083A1 (en) 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with multicast handling US20020009136A1 (en) * 2000-03-29 2002-01-24 Heath Robert G. System employing data compression transparent mode with compression parameter negotiation US20020046348A1 (en) 2000-07-13 2002-04-18 Brustoloni Jose?Apos; C. Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode US6389419B1 (en) 1999-10-06 2002-05-14 Cisco Technology, Inc. Storing and retrieving connection information using bidirectional hashing of connection identifiers US20020078242A1 (en) * 2000-12-15 2002-06-20 Nanjundiah Viswanath Method of selectively compressing data packets US20020083344A1 (en) 2000-12-21 2002-06-27 Vairavan Kannan P. Integrated intelligent inter/intra networking device US20020089979A1 (en) * 2000-12-29 2002-07-11 Barbir Abdulkader Communication security US6449647B1 (en) 1997-08-01 2002-09-10 Cisco Systems, Inc. Content-aware switching of network packets US20020133534A1 (en) 2001-01-08 2002-09-19 Jan Forslow Extranet workgroup formation across multiple mobile virtual private networks US20020133598A1 (en) * 2001-03-16 2002-09-19 Strahm Frederick William Network communication US20020138848A1 (en) * 2001-02-02 2002-09-26 Rachad Alao Service gateway for interactive television US20020136210A1 (en) 2001-03-21 2002-09-26 International Business Machines Corporation System and method for virtual private network network address translation propagation over nested connections with coincident local endpoints US20020162026A1 (en) 2001-02-06 2002-10-31 Michael Neuman Apparatus and method for providing secure network communication US20020169885A1 (en) * 2001-02-02 2002-11-14 Rachad Alao Digital television application protocol for interactive television US20020172164A1 (en) * 2001-05-18 2002-11-21 Ching-Tsun Chou Link level retry scheme US6496867B1 (en) 1999-08-27 2002-12-17 3Com Corporation System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks US20030007486A1 (en) 2001-06-14 2003-01-09 March Sean W. Network address and/or port translation US20030012190A1 (en) * 2001-04-20 2003-01-16 General Instrument Corporation IP data encapsulation and insertion in a transport multiplexer US20030028606A1 (en) * 2001-07-31 2003-02-06 Chris Koopmans Service-based compression of content within a network communication system US6542935B1 (en) 1999-07-28 2003-04-01 Sharp Laboratories Of America, Inc. Method for obtaining a second address free from association with multiple devices US6542992B1 (en) 1999-01-26 2003-04-01 3Com Corporation Control and coordination of encryption and compression between network entities US20030110296A1 (en) * 2001-12-07 2003-06-12 Kirsch Steven T. Method and system for reducing network latency in data communication US20030145226A1 (en) 2002-01-28 2003-07-31 International Business Machines Corporation Integrated intrusion detection services US20030142823A1 (en) 2002-01-25 2003-07-31 Brian Swander Method and apparatus for fragmenting and reassembling internet key exchange data packets US20030146907A1 (en) * 1995-10-16 2003-08-07 Nec Corporation Wireless file transmission US20030154399A1 (en) 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods US6615357B1 (en) 1999-01-29 2003-09-02 International Business Machines Corporation System and method for network address translation integration with IP security US20030179713A1 (en) * 2002-03-20 2003-09-25 Fleming Kristoffer D. Method and apparatus for network header compression US6629150B1 (en) * 1999-06-18 2003-09-30 Intel Corporation Platform and method for creating and using a digital container US20030197719A1 (en) * 1998-05-29 2003-10-23 Lincke Scott D. Method, system and apparatus using a sensory cue to indicate subsequent action characteristics for data communications US6646999B1 (en) 1999-02-19 2003-11-11 Fujitsu Limited Mobile packet communication system US6647428B1 (en) * 2000-05-05 2003-11-11 Luminous Networks, Inc. Architecture for transport of multiple services in connectionless packet-based communication networks US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method US20030233576A1 (en) 2002-06-13 2003-12-18 Nvidia Corp. Detection of support for security protocol and address translation integration US20030233568A1 (en) 2002-06-13 2003-12-18 Nvidia Corp. Method and apparatus for control of security protocol negotiation US20040030927A1 (en) 2002-02-08 2004-02-12 Nir Zuk Intelligent integrated network security device US6704794B1 (en) 2000-03-03 2004-03-09 Nokia Intelligent Edge Routers Inc. Cell reassembly for packet based networks US6714985B1 (en) 2000-04-28 2004-03-30 Cisco Technology, Inc. Method and apparatus for efficiently reassembling fragments received at an intermediate station in a computer network US6735647B2 (en) 2002-09-05 2004-05-11 International Business Machines Corporation Data reordering mechanism for high performance networks US20040114589A1 (en) 2002-12-13 2004-06-17 Alfieri Robert A. Method and apparatus for performing network processing functions US6757746B2 (en) 1997-10-14 2004-06-29 Alacritech, Inc. Obtaining a destination address so that a network interface device can write network data without headers directly into host memory US6781955B2 (en) 2000-12-29 2004-08-24 Ericsson Inc. Calling service of a VoIP device in a VLAN environment US6832261B1 (en) 2001-02-04 2004-12-14 Cisco Technology, Inc. Method and apparatus for distributed resequencing and reassembly of subdivided packets US6879266B1 (en) * 1997-08-08 2005-04-12 Quickshift, Inc. Memory module including scalable embedded parallel data compression and decompression engines US6889385B1 (en) * 2000-01-14 2005-05-03 Terayon Communication Systems, Inc Home network for receiving video-on-demand and other requested programs and services US6888835B2 (en) 2000-07-05 2005-05-03 Roke Manor Research Limited Buffer management US6904519B2 (en) * 1998-06-12 2005-06-07 Microsoft Corporation Method and computer program product for offloading processing tasks from software to hardware US6907042B1 (en) 1999-05-18 2005-06-14 Fujitsu Limited Packet processing device US6909714B2 (en) * 2001-07-03 2005-06-21 Qualcomm Incorporated Method and apparatus for determining configuration options negotiated for a communications link employing a network model US6912522B2 (en) 2000-09-11 2005-06-28 Ablesoft, Inc. System, method and computer program product for optimization and acceleration of data transport and processing US20050182854A1 (en) * 2002-04-30 2005-08-18 Microsoft Corporation Method to synchronize and upload an offloaded network stack connection with a network stack US6950862B1 (en) * 2001-05-07 2005-09-27 3Com Corporation System and method for offloading a computational service on a point-to-point communication link US6957346B1 (en) 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations US20050281288A1 (en) 2004-06-17 2005-12-22 International Business Machines Corporation Method and apparatus for discovering path maximum transmission unit (PMTU) US7010727B1 (en) 2001-06-15 2006-03-07 Nortel Networks Limited Method and system for negotiating compression techniques to be utilized in packet data communications US7027443B2 (en) 2001-08-23 2006-04-11 Pmc-Sierra Ltd. Reassembly engines for multilink applications US7116640B2 (en) 2000-12-22 2006-10-03 Mitchell Paul Tasman Architecture and mechanism for forwarding layer interfacing for networks US7136926B1 (en) 1998-12-31 2006-11-14 Pmc-Sierrra Us, Inc. Method and apparatus for high-speed network rule processing

2002

2002-05-08 US US10/141,039 patent/US7558873B1/en not_active Expired - Lifetime

Patent Citations (81)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title US5884025A (en) 1995-05-18 1999-03-16 Sun Microsystems, Inc. System for packet filtering of data packet at a computer network interface US5826027A (en) 1995-10-11 1998-10-20 Citrix Systems, Inc. Method for supporting an extensible and dynamically bindable protocol stack in a distrubited process system US20030146907A1 (en) * 1995-10-16 2003-08-07 Nec Corporation Wireless file transmission US5742773A (en) 1996-04-18 1998-04-21 Microsoft Corporation Method and system for audio compression negotiation for multiple channels US6101170A (en) 1996-09-27 2000-08-08 Cabletron Systems, Inc. Secure fast packet switch having improved memory utilization US6304573B1 (en) * 1997-04-03 2001-10-16 At&T Corp. Method and apparatus for transmitting and receiving electronic voice messages US6449647B1 (en) 1997-08-01 2002-09-10 Cisco Systems, Inc. Content-aware switching of network packets US6879266B1 (en) * 1997-08-08 2005-04-12 Quickshift, Inc. Memory module including scalable embedded parallel data compression and decompression engines US6094485A (en) 1997-09-18 2000-07-25 Netscape Communications Corporation SSL step-up US6757746B2 (en) 1997-10-14 2004-06-29 Alacritech, Inc. Obtaining a destination address so that a network interface device can write network data without headers directly into host memory US6047325A (en) 1997-10-24 2000-04-04 Jain; Lalit Network device for supporting construction of virtual local area networks on arbitrary local and wide area computer networks WO1999035799A2 (en) 1997-12-31 1999-07-15 Ssh Communications Security Oy A method for packet authentication in the presence of network address translations and protocol conversions US6055236A (en) 1998-03-05 2000-04-25 3Com Corporation Method and system for locating network services with distributed network address translation US6189102B1 (en) 1998-05-27 2001-02-13 3Com Corporation Method for authentication of network devices in a data-over cable system US20010032254A1 (en) * 1998-05-29 2001-10-18 Jeffrey C. Hawkins Method and apparatus for wireless internet access US20030197719A1 (en) * 1998-05-29 2003-10-23 Lincke Scott D. Method, system and apparatus using a sensory cue to indicate subsequent action characteristics for data communications US6141705A (en) * 1998-06-12 2000-10-31 Microsoft Corporation System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when needed US6904519B2 (en) * 1998-06-12 2005-06-07 Microsoft Corporation Method and computer program product for offloading processing tasks from software to hardware US6032253A (en) 1998-06-15 2000-02-29 Cisco Technology, Inc. Data processor with multiple compare extension instruction US6215907B1 (en) * 1998-06-26 2001-04-10 Fisher-Rosemont Systems, Inc. Recursive on-line wavelet data compression technique for use in data storage and communications US6327660B1 (en) 1998-09-18 2001-12-04 Intel Corporation Method for securing communications in a pre-boot environment US6275588B1 (en) * 1998-11-12 2001-08-14 I-Data International A/S Apparatus and method for performing and controlling encryption/decryption for data to be transmitted on local area network US7136926B1 (en) 1998-12-31 2006-11-14 Pmc-Sierrra Us, Inc. Method and apparatus for high-speed network rule processing US6542992B1 (en) 1999-01-26 2003-04-01 3Com Corporation Control and coordination of encryption and compression between network entities US6615357B1 (en) 1999-01-29 2003-09-02 International Business Machines Corporation System and method for network address translation integration with IP security US20010054131A1 (en) * 1999-01-29 2001-12-20 Alvarez Manuel J. System and method for perfoming scalable embedded parallel data compression US20010038642A1 (en) * 1999-01-29 2001-11-08 Interactive Silicon, Inc. System and method for performing scalable embedded parallel data decompression US6646999B1 (en) 1999-02-19 2003-11-11 Fujitsu Limited Mobile packet communication system WO2000056034A1 (en) 1999-03-17 2000-09-21 3Com Corporation Method and system for distributed network address translation with network security features US6907042B1 (en) 1999-05-18 2005-06-14 Fujitsu Limited Packet processing device US6658463B1 (en) * 1999-06-10 2003-12-02 Hughes Electronics Corporation Satellite multicast performance enhancing multicast HTTP proxy system and method US6957346B1 (en) 1999-06-15 2005-10-18 Ssh Communications Security Ltd. Method and arrangement for providing security through network address translations using tunneling and compensations US6629150B1 (en) * 1999-06-18 2003-09-30 Intel Corporation Platform and method for creating and using a digital container US6542935B1 (en) 1999-07-28 2003-04-01 Sharp Laboratories Of America, Inc. Method for obtaining a second address free from association with multiple devices US6496867B1 (en) 1999-08-27 2002-12-17 3Com Corporation System and method to negotiate private network addresses for initiating tunneling associations through private and/or public networks US6389419B1 (en) 1999-10-06 2002-05-14 Cisco Technology, Inc. Storing and retrieving connection information using bidirectional hashing of connection identifiers US6889385B1 (en) * 2000-01-14 2005-05-03 Terayon Communication Systems, Inc Home network for receiving video-on-demand and other requested programs and services WO2001067258A1 (en) 2000-03-03 2001-09-13 Nexland, Inc. Network address translation gateway for local area networks using local ip addresses and non-translatable port addresses US6704794B1 (en) 2000-03-03 2004-03-09 Nokia Intelligent Edge Routers Inc. Cell reassembly for packet based networks EP1130846A2 (en) 2000-03-03 2001-09-05 Nexland, Inc. Network address translation gateway US20020009136A1 (en) * 2000-03-29 2002-01-24 Heath Robert G. System employing data compression transparent mode with compression parameter negotiation WO2001076191A1 (en) 2000-03-31 2001-10-11 Microsoft Corporation Proxy network address translation US6714985B1 (en) 2000-04-28 2004-03-30 Cisco Technology, Inc. Method and apparatus for efficiently reassembling fragments received at an intermediate station in a computer network US6647428B1 (en) * 2000-05-05 2003-11-11 Luminous Networks, Inc. Architecture for transport of multiple services in connectionless packet-based communication networks US20020009083A1 (en) 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with multicast handling US6888835B2 (en) 2000-07-05 2005-05-03 Roke Manor Research Limited Buffer management US20020046348A1 (en) 2000-07-13 2002-04-18 Brustoloni Jose?Apos; C. Method and apparatus for robust NAT interoperation with IPSEC'S IKE and ESP tunnel mode US6912522B2 (en) 2000-09-11 2005-06-28 Ablesoft, Inc. System, method and computer program product for optimization and acceleration of data transport and processing US20020078242A1 (en) * 2000-12-15 2002-06-20 Nanjundiah Viswanath Method of selectively compressing data packets US20020083344A1 (en) 2000-12-21 2002-06-27 Vairavan Kannan P. Integrated intelligent inter/intra networking device US7116640B2 (en) 2000-12-22 2006-10-03 Mitchell Paul Tasman Architecture and mechanism for forwarding layer interfacing for networks US20020089979A1 (en) * 2000-12-29 2002-07-11 Barbir Abdulkader Communication security US6781955B2 (en) 2000-12-29 2004-08-24 Ericsson Inc. Calling service of a VoIP device in a VLAN environment US20020133534A1 (en) 2001-01-08 2002-09-19 Jan Forslow Extranet workgroup formation across multiple mobile virtual private networks US20020138848A1 (en) * 2001-02-02 2002-09-26 Rachad Alao Service gateway for interactive television US7017175B2 (en) 2001-02-02 2006-03-21 Opentv, Inc. Digital television application protocol for interactive television US20020169885A1 (en) * 2001-02-02 2002-11-14 Rachad Alao Digital television application protocol for interactive television US6832261B1 (en) 2001-02-04 2004-12-14 Cisco Technology, Inc. Method and apparatus for distributed resequencing and reassembly of subdivided packets US20020162026A1 (en) 2001-02-06 2002-10-31 Michael Neuman Apparatus and method for providing secure network communication US20020133598A1 (en) * 2001-03-16 2002-09-19 Strahm Frederick William Network communication US20020136210A1 (en) 2001-03-21 2002-09-26 International Business Machines Corporation System and method for virtual private network network address translation propagation over nested connections with coincident local endpoints US20030012190A1 (en) * 2001-04-20 2003-01-16 General Instrument Corporation IP data encapsulation and insertion in a transport multiplexer US6950862B1 (en) * 2001-05-07 2005-09-27 3Com Corporation System and method for offloading a computational service on a point-to-point communication link US20020172164A1 (en) * 2001-05-18 2002-11-21 Ching-Tsun Chou Link level retry scheme US20030007486A1 (en) 2001-06-14 2003-01-09 March Sean W. Network address and/or port translation US7010727B1 (en) 2001-06-15 2006-03-07 Nortel Networks Limited Method and system for negotiating compression techniques to be utilized in packet data communications US6909714B2 (en) * 2001-07-03 2005-06-21 Qualcomm Incorporated Method and apparatus for determining configuration options negotiated for a communications link employing a network model US20030028606A1 (en) * 2001-07-31 2003-02-06 Chris Koopmans Service-based compression of content within a network communication system US7027443B2 (en) 2001-08-23 2006-04-11 Pmc-Sierra Ltd. Reassembly engines for multilink applications US20030110296A1 (en) * 2001-12-07 2003-06-12 Kirsch Steven T. Method and system for reducing network latency in data communication US20030142823A1 (en) 2002-01-25 2003-07-31 Brian Swander Method and apparatus for fragmenting and reassembling internet key exchange data packets US20030145226A1 (en) 2002-01-28 2003-07-31 International Business Machines Corporation Integrated intrusion detection services US20030154399A1 (en) 2002-02-08 2003-08-14 Nir Zuk Multi-method gateway-based network security systems and methods US20040030927A1 (en) 2002-02-08 2004-02-12 Nir Zuk Intelligent integrated network security device US20030179713A1 (en) * 2002-03-20 2003-09-25 Fleming Kristoffer D. Method and apparatus for network header compression US20050182854A1 (en) * 2002-04-30 2005-08-18 Microsoft Corporation Method to synchronize and upload an offloaded network stack connection with a network stack US20030233576A1 (en) 2002-06-13 2003-12-18 Nvidia Corp. Detection of support for security protocol and address translation integration US20030233568A1 (en) 2002-06-13 2003-12-18 Nvidia Corp. Method and apparatus for control of security protocol negotiation US6735647B2 (en) 2002-09-05 2004-05-11 International Business Machines Corporation Data reordering mechanism for high performance networks US20040114589A1 (en) 2002-12-13 2004-06-17 Alfieri Robert A. Method and apparatus for performing network processing functions US20050281288A1 (en) 2004-06-17 2005-12-22 International Business Machines Corporation Method and apparatus for discovering path maximum transmission unit (PMTU)

Non-Patent Citations (8)

* Cited by examiner, â Cited by third party Title "Ciscopress.com IPSec Overview Part Four: Internet Key Exchange (IKE)", Andrew Mason, Feb. 22, 2002. * "Diffie-Hellman key exchange", Wikipedia, 2002. * "IPSec Overview Part Four: Internet Key Exchange (IKE)"; Andrew Mason; Cisco Press; Feb. 22, 2002. * "PKCS #3: Diffie-Hellman Kay Agreement Standard", RSA Laboratories Technical Note, Nov. 1, 1993. * "RE: IPCOMP and IPSEC", Robert Moskowitz, Jun. 4, 1998. * Internet Protocol, RFC 791, DARPA, Sep. 1981. Mogul et al. "Path MTU Discovery" RFC 1191, Nov. 1990. Orda et al. "Optimal Packet Fragementation in Computer Networks", Mar. 1994.

Cited By (11)

* Cited by examiner, â Cited by third party Publication number Priority date Publication date Assignee Title

Similar Documents

Publication Publication Date Title US8468337B2 (en) 2013-06-18 Secure data transfer over a network US7502925B2 (en) 2009-03-10 Method and apparatus for reducing TCP frame transmit latency US5815516A (en) 1998-09-29 Method and apparatus for producing transmission control protocol checksums using internet protocol fragmentation US7500102B2 (en) 2009-03-03 Method and apparatus for fragmenting and reassembling internet key exchange data packets US7818564B2 (en) 2010-10-19 Deciphering of fragmented enciphered data packets US7327762B2 (en) 2008-02-05 Packet data processing apparatus in packet data communication system US6076168A (en) 2000-06-13 Simplified method of configuring internet protocol security tunnels US8855301B2 (en) 2014-10-07 Coordinating compression information for unreliable encrypted streams through key establishment protocols Granjal et al. 2014 Networkâlayer security for the Internet of Things using TinyOS and BLIP US7430204B2 (en) 2008-09-30 Internet protocol tunnelling using templates US6700888B1 (en) 2004-03-02 Manipulating header fields for improved performance in packet communications US20060104308A1 (en) 2006-05-18 Method and apparatus for secure internet protocol (IPSEC) offloading with integrated host protocol stack management US7913294B1 (en) 2011-03-22 Network protocol processing for filtering packets US7974209B1 (en) 2011-07-05 Packet processing with re-insertion into network interface circuitry US20050198498A1 (en) 2005-09-08 System and method for performing cryptographic operations on network data WO2010022653A1 (en) 2010-03-04 Detecting method and terminal for transferring files CN112448918A (en) 2021-03-05 Message transmission method and device and computer storage medium US7558873B1 (en) 2009-07-07 Method for compressed large send US9467471B2 (en) 2016-10-11 Encrypted communication apparatus and control method therefor US7426636B1 (en) 2008-09-16 Compact secure data communication method US20090178104A1 (en) 2009-07-09 Method and system for a multi-level security association lookup scheme for internet protocol security US7564976B2 (en) 2009-07-21 System and method for performing security operations on network data US7886146B2 (en) 2011-02-08 Network cryptography system and method US11765237B1 (en) 2023-09-19 Session-based remote direct memory access US7437548B1 (en) 2008-10-14 Network level protocol negotiation and operation

Legal Events

Date Code Title Description