Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Exchanging Maximum Idle-Time Option on Establishing TCP Connections

IP.com Disclosure Number: IPCOM000030309D
Original Publication Date: 2004-Aug-05
Included in the Prior Art Database: 2004-Aug-05
Document File: 3 page(s) / 14K

Publishing Venue

IBM

Abstract

Described is a method for exchanging the Maximum Idle-Time (MIT) for a TCP connection. By implementing this mechanism, 1) The Client and the Server become free from transferring any garbage packet and RST packet; 2) The connection oriented devices (such as Firewalls and Load-Balancers) between the Client and the Server become able to handle the Idle-Time of the connection efficiently.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 3

Exchanging Maximum Idle-Time Option on Establishing TCP Connections

Today, almost all the IP applications are based upon the TCP, and many network devices, such as Firewalls and Load-Balancers, treats the packets in the TCP manner. Such network devices may be called "Connection-Oriented Devices". A Connection-Oriented Device has a connection table in itself. When the packet that indicates the beginning of a TCP connection
(i.e. SYN) arrives, it creates an entry in the connection table and forwards that packet. When the packet within a TCP connection arrives, it looks-up the corresponding entry in the connection table, and if the entry is found, it forwards that packet. If the entry is not found, it drops that packet. When the packet that indicates the end of a TCP connection (i.e. FIN or RST) arrives, it looks-up the corresponding entry in the connection table, forwards that packet, and deletes that entry from the connection table. If all the entries are alive forever, the resource (memory) of the Connection-Oriented Device gets short, the packet forwarding performance decreases and finally, it hangs up. In the normal situation, every TCP connection is closed by FIN or RST packet, however, if the network gets down, or if the Client or the Server hangs up, such packets do not reach the Connection-Oriented Devices, and the resource is consumed. Against such the faulty situations, every existing Connection-Oriented Device has defined "Idle-Timeout Value" for the connection entry. If any packet belonging to an existing connection does not arrive for the Idle-Timeout Value (for example, 300sec), it frees the corresponding entry in the connection table. But even if the faulty situation does not occur, some applications do not send packet for more than that Idle-Timeout Value. For such applications, packets are dropped at the Connection-Oriented Devices before completing the TCP connection, thus, useless packet re-transmit and application error would be caused. Because the Idle-Time varies widely (from a few sec to a few days) among various applications and Operation-Systems, it is difficult to define the Idle-Timeout Value for the network designers. The longer they define the Idle-Timeout Value, the larger the resource consumption becomes in the Connection-Oriented Devices. The shorter they define the Idle-Timeout Value, the oftener the application error occurs.

Described method solves this problem by extending current TCP implementation. The Client and the Server exchanges the Maximum Idle-Timeout (MIT) on establishing the TCP connection. In this circumstance, the option to specify the MIT should be provided in socket() API, and who defines the MIT are application programmers (or, programmers might provide an interface for the users to define the MIT). MIT-capable Clients, Servers and Connection-Oriented Devices must have the following functions.

[Clients] - Inserting MIT in SYN packet. - Using MIT in the Server's SYN/ACK packet to han...