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

SHARED RTO TIMER MECHANISM FOR TCP

IP.com Disclosure Number: IPCOM000009763D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2002-Sep-17
Document File: 3 page(s) / 161K

Publishing Venue

Motorola

Related People

Rod Averbuch: AUTHOR [+2]

Abstract

TCP detects packet loss by using a dynamically adjustable retransmission timeout (RIO) timer. The RTO is an estimation of how long it will take to receive an acknowledgment for a transmitted segment given current network conditions. For peak TCP performance, an accurate determination of the correct RTO is important. An RTO that is too short will be effected by small changes in delay. It will timeout prematurely and cause unnecessary segment retransmissions. An RTO that is too large will cause a TCP implementation to wait more than necessary before detecting segment loss. This will lead to reduced throughput.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 37% of the total text.

MOTOROLA

Technical Developments

SHARED RTO TIMER MECHANISM FOR TCP

by Rod Averbuch and Guy Romano

Patent Disclosure #39l4H: Shared RTO Timer Mechanism for TCP

TCP detects packet loss by using a dynamically adjustable retransmission timeout (RIO) timer. The RTO is an estimation of how long it will take to receive an acknowledgment for a transmitted segment given current network conditions. For peak TCP performance, an accurate determination of the correct RTO is important. An RTO that is too short will be effected by small changes in delay. It will timeout prematurely and cause unnecessary segment retransmissions. An RTO that is too large will cause a TCP implementation to wait more than necessary before detecting segment loss. This will lead to reduced throughput.

The RIO timer is started when a ICP has an unacknowledged segment. If an acknowledgment is not received before the RTO timer expires then the segment is retransmitted and congestion avoidance measures are taken. If the acknowledgment is received before the RTO timer expires then the round-trip-time (RTT) is measured. The measured RTI is the amount of time between a non-retried segment transmission and the reception of a packet that acknowledges the segment. The measured R1T is then used to update the estimated value for RTO.

The new RTO estimation will be used the next time the RTO timer is started.

A correct RTO estimation is even more important in reliable wireless environments like iDEN packet data and CDPD. These environments frequently have high levels of delay and delay variance. Delay and delay variance in a wireless environment can be caused by more than just network congestion, as is the case in a wired environment.

The sources for delay and delay variance are:

. Voice Load: Bandwidth for the packet data service can be reduced, or in some cases exhausted, by

Motorola, Inc. 2000

voice traffic. Since the amount of bandwidth being consumed by the voice services is dynamic, the amount of bandwidth available for the packet data service will be variable.

. Bit Errors: Reliable link layers, like iDEN packet data, deliver error-free, in-order frames from one connection endpoint to another. Any frames, or blocks of frames, that contain errors are eventually re-tried at the link layer. The amount of delay caused by error recovery is variable. It is based on signal conditions, signaling rate, and fading conditions.

. Hand-off: A certain amount of time is required to hand-off from one site to another. Packet data traffic will be suspended during a handoff.

. Data Load: Packet data users will contend with other packet data users for bandwidth on the packet data system. This is similar to the type of congestion seen in a LAN environment.

To make matters worse the above mentioned delays can occur in parallel, further increasing delay and delay variance.

An accurate estimated RTO is also necessary when resuming traffic on an idle TCP connection. A ICP connection is considered idle if it ha...