Notes by Alfred Landrum
Using the same idea as file caching in a file system, Renesse has developed a system called the Protocol Accelerator (PA). Its function is reducing the overhead of protocol layering within a network stack. It targets two forms of overhead: interfacing (crossing a layer) and header overhead.
Uses three techniques: 1) Header fields that never change are sent once. 2) Remaining header information is packed, allowing headers less than 40 bytes. [This is the typical overhead on TCP/IP.] 3) The sending and delivery of packets is split into two parts: one that checks the header but not the protocol state, and vice versa. The first part is done in order to circumvent the protocol layers whenever possible. The second is done when the application is blocked.
Reducing Header Overhead
The PA divides headers into 4 classes:
- Connection Identification, fields that never change during the period of the connection
- Protocol-Specific Information, fields that are important for the correct delivery of the particular message frame.
- Message-specific Information, other fields that need to accompany the message (e.g., message length, checksum, timestamp)
- Gossip, "fields that technically do not need to accompany the message but are included for message efficiency."
The PA collects all the fields and compiles them into four compact headers. It will observe the size of the headers, and offset if needed. It doesn't care about layering, so the initial protocol fields may be mixed arbitrarily, to trade padding for alignment. The PA will always send the Protocol Specific, Message Specific, and (currently) the Gossip fields. The Connection Identification field is sent on the first message, on retransmissions, and other unusual messages. Also, the PA sends a 62 Connection Cookie, which identifies an individual connection. Two other bit fields are used; one for noting the endianess of the message, and the other for noting whether an Connection ID has been included in the message.
Eliminating Layered Protocol Processing Overhead
- Minimizes the critical path by delaying all updating of the protocol state until after the actual message sending or delivery, but before the next send or delivery operation. This means that the PA will reduce latency only if the messages are spaced out far enough to allow for post-processing.
- Predicts the protocol-specific header of the next message
- Uses packet filters, in the send and delivery critical paths, to avoid passing through the layers.
The PA can also combine messages together, using a sixth "Packing" header in its message. This is potentially useful if messages are backlogged because of post-processing.
Application to Standard Protocols
The PA could be used by with standard protocols, like TCP/IP, to improve latency, but of course only if both peers implement PA. However, the pre-processing and post-processing techniques would still be applicable.
Questions
Since you still have to have IP packets to route through the Internet, then wouldn't this only be useful for reducing overhead in TCP? If that's true, then you're trying to reduce the overhead of the TCP layer (which makes sense to me), but you'd be spending time trying to reduce the 20-32 bytes typically used by a TCP header. Does this make sense? How large of a protocol, over and above TCP, would you have to have in order to get a header optimization from PA?