Paul E. McKenney
Ken F. Dove
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.
- Cro91 Jon Crowcroft. Re: Inefficient demultiplexing by 4.3 TCP/IP. Message-iD [email protected] to tcp-ip list, December 1991.Google Scholar
- Dov90 Ken F. Dove. A high capacity TCP/IP in parallel STREAMS. In UKUUG Conference Proceedings, London, June 1990.Google Scholar
- Fel90 David C. Feldmeier. Multiplexing issues in communication system design. In $IGCOMM '90 Symposium, pages 209-219, Philadelphia, PA, September 1990. Google ScholarDigital Library
- Gar90 Arun Garg. Parallel STREAMS. In USENIX Conference Proceedings, Berkeley CA, February 1990.Google Scholar
- Gra91 Jim Gray. The Benchmark Handbook for Database and Transaction Processing Systems. Morgan Kaufmann, 1991. Google ScholarDigital Library
- HJ91 John L. Hennessy and Norman P. Jouppi. Computer tochnology and architoctum: An evolving interaction. IEEE Computer, pages 18-28, September 1991. Google ScholarDigital Library
- HL86 Frederick S. Hillier and Gerald J. Lieberman. introduction to Operations Research. Holden- Day, 1986. Google ScholarDigital Library
- Jac88 Van Jacobson. Congestion avoidance and control. in SIGCOMM '88, pages 314-329, August 1988. Google ScholarDigital Library
- Jai89 Raj Jain. A comparison of hashing schemes for address lookup in computer networks. Technical Report DEC-TR-593, Digital Equipment Corporation, February 1989.Google Scholar
- JR86 Raj Jain and Shawn Routhier. Packet trainsmeasurements and a new model for computer network traffic. IEEE Journal on Selected Areas in Communicatzons, SAC-4(6):986-995, September 1986.Google Scholar
- McK91 Paul E. McKenney. Stochastic fairness queuing. Internetworking: Theory and Experience, 2:113-131, 1991.Google Scholar
- Mog91 Jeffrey C. Mogul. Network locality at the scale of processes. In Proceeding of $IGUOMM '91, Zurich, September 1991. Google ScholarDigital Library
- Pos81 J.B. Postel. qh'ansmission Control Protocol. Technical Report RFC793, Network Information Center, SRI International, September 1981.Google Scholar
- PP91 Craig Partridge and Stephen Pink. A faster UDP. Swedish Institute of Computer Science Tecnical Report, August 1991.Google Scholar
- SC91 Harold S. Stone and John Cocke. Computer architecture in tile 1990s. IEEE Computer, pages 30-38, September 1991. Google ScholarDigital Library
- Vis91 Lance Vissner. Re: Inefficient demultiplexing by 4.3 TCP/iP. Message-iD [email protected] to tcpip list, December 1991.Google Scholar
Index Terms
- Efficient demultiplexing of incoming TCP packets
Recommendations
Efficient demultiplexing of incoming TCP packets
SIGCOMM '92: Conference proceedings on Communications architectures & protocolsWhen 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, ...
TCP CERL: congestion control enhancement over wireless networks
In this paper, we propose and verify a modified version of TCP Reno that we call TCP Congestion Control Enhancement for Random Loss (CERL). We compare the performance of TCP CERL, using simulations conducted in ns-2, to the following other TCP variants: ...
Comments