Efficient demultiplexing of incoming TCP packets

  • Authors:
  • Paul E. McKenney;Ken F. Dove

  • Affiliations:
  • -;-

  • Venue:
  • SIGCOMM '92 Conference proceedings on Communications architectures & protocols
  • Year:
  • 1992

Quantified Score

Hi-index 0.00

Visualization

Abstract

When a transport protocol segment arrives at a receiving system, the receiving system must determine which application is to receive the protocol segment. This decision is typically made by looking up a protocol control block (PCB) for the segment, based on information in the segment's header. PCB lookup (a form of demultiplexing) is typically one of the more expensive operations in handling inbound protocol segment [Fe190].Many recent protocol optimizations for the Transmission Control Protocol (TCP) [Jac88] assume that a large component of TCP traffic is bulk-data transfers, which result in packet trains [JR86]. If packet trains are prevalent, there is a high likelihood that the next TCP segment is en route to the same application (i.e. uses the same PCB) as the previous TCP segment. In these environments a very simple one-PCB cache like those used in BSD systems yields very high cache hit rates.However, there are classes of applications that do not form packet trains, and these applications do not perform well with a one-PCB cache. Examples of such applications are quite common in the area of heads-down data entry into on-line transaction-processing (OLTP) systems. OLTP systems make heavy use of computer communications networks and have large aggregate-packet-rates but are also characterized by large numbers of connections, low per-connection packet rates, and rather small packets. This combination of characteristics results in a very low incidence of packet trains.This paper uses a simple analytic approach to examine how different PCB lookup schemes perform with OLTP traffic. One scheme is shown to work an order of magnitude better for OLTP traffic than the one-PCB cache approach while still maintaining good performance for packet-train traffic.