Browse Prior Art Database

Method for TCP/IP flow control in a network adapter

IP.com Disclosure Number: IPCOM000009382D
Publication Date: 2002-Aug-20
Document File: 3 page(s) / 83K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for transmission control protocol/Internet protocol (TCP/IP) flow control in a network adapter. Benefits include improved functionality and improved performance.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 47% of the total text.

Method for TCP/IP flow control in a network adapter

Disclosed is a method for transmission control protocol/Internet protocol (TCP/IP) flow control in a network adapter. Benefits include improved functionality and improved performance.

Background

        � � � � � Although network protocols such as TCP can function with some level of packet loss, performance tends to deteriorate severely when packet loss occurs. Typical TCP implementations interpret the loss of a packet as an indicator of network congestion. Such an implementation often responds by drastically reducing the rate at which it transmits subsequent data to prevent further packet loss and reduce congestion.

        � � � � � To combat this behavior, the TCP/IP standard defines a few different flow control mechanisms that may be used to initiate an orderly reduction in the traffic rate. An intermediate network node such as a router may send an ICMP source quench message to a host when the router is forced to drop packets from that host due to an overflow condition. A TCP implementation on a remote host may send an “explicit congestion notification” to the transmitting host when the remote TCP itself detects congestion on a local segment.

        � � � � � Regardless of how TCP learns of the congestion (either by packet loss or explicit notification), it responds by throttling the rate at which it sends traffic to that host. However, typical TCP implementations recover much more quickly (roughly twice as fast) when they receive explicit notification of network congestion. Thus, explicit network congestion notification is always preferable to allowing a remote TCP to passively detect it through packet loss. In addition, packet loss leads to network inefficiencies. TCP must retransmit the lost packets, consuming additional bandwidth and potentially interfering with other traffic.

        � � � � � These solutions provide an end-to-end flow control mechanism for routers and host TCP implementations, but do not account for the link layer device (such as an Ethernet adapter) on a host system. These adapters have only a finite quantity of resources for capturing incoming traffic. If these resources are insufficient to handle the incoming traffic load, the network adapter is forced to drop some of these incoming packets. A remote TCP implementation eventually notices this loss and reacts by throttling its flow of packets. Neither the network infrastructure nor the local TCP have any knowledge of this overrun condition. Neither of these explicit flow control mechanisms is triggered to reduce the traffic flow in an orderly manner when it occurs at the network adapter.

        � � � � � At best, the network adapter may use a link-layer flow control protocol to reduce the rate of incoming packets. However, the point of congestion is simply moved from the network adapter to its link partner. What is required is a mechanism by which a network adapter (or its device driver) may inform a remote TCP of the overflow condition and reque...