Browse Prior Art Database

Dynamic Computation of TCP Maximum Window Size for Directly Connected Hosts

IP.com Disclosure Number: IPCOM000112035D
Original Publication Date: 1994-Apr-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 8 page(s) / 286K

Publishing Venue

IBM

Related People

Chang, K: AUTHOR [+2]

Abstract

Presented are the design, analysis and implementation of an algorithm which dynamically adjusts the maximum window size for a TCP connection. Such an algorithm was developed and tested on RISC System/6000*. The current TCP implementations offer fixed window size which cannot be the best for all types of connections. We try to get dynamically the best window on a per connection basis.

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

Dynamic Computation of TCP Maximum Window Size for Directly Connected
Hosts

      Presented are the design, analysis and implementation of an
algorithm which dynamically adjusts the maximum window size for a TCP
connection.  Such an algorithm was developed and tested on RISC
System/6000*.  The current TCP implementations offer fixed window
size which cannot be the best for all types of connections.  We try
to get dynamically the best window on a per connection basis.

INTRODUCTION

      TCP (or Transmission Control Protocol) is the transport
protocol of the Internet protocol suite.  TCP is used on top of a
datagram packet delivery protocol called IP.  Today TCP/IP networks
include many different LANs (i.e., token ring, Ethernet, IEEE 802.X
), as well as WANs (like FDDI, T1, and T3), connecting different
machines, with varied capacities.  Here, we suggest one
implementation which might aid in improving performance for direct
connections over these networks.

      TCP functions include sequencing packets, detecting and
recovering lost or corrupted packets, multiplexing and flow control.
This document is concerned with the flow control mechanism.

      TCP uses a sliding window mechanism to achieve an end-to-end
flow control.  Peer TCPs advertise their window on each packet that
is sent.  The sender TCP can send more than one packet of data (up
till window size), without receiving an ACK.  It has been seen that
the window size can have a significant effect on the throughput of a
connection (Fig.  4).  The window size is usually set to the size of
the application's receive buffer, which in turn is set by the
application (via socket).  The fundamental approach in determining
the window size is to keep the pipeline full.  And the product of
bandwidth (bits per second) and Round-Trip Time (RTT in seconds), is
the number of bits required to keep the pipeline full.

      With the current setup, the first problem is: the window size
is being determined by the application which does not have a very
good idea about the underlying network.  And consequently, it may not
be very appropriate.  Another problem is the use of fixed window size
over different networks.

      The product of bandwidth and RTT can vary a lot based on the
network.  For example, on a 9600 bits/sec serial line with a delay of
2 sec, it is only 19,200 bits.  For terrestrial fiber-optical paths,
a cross-country delay of 30 ms at DS3 bandwidth (45 Mbps) is more
than 1,000,000 bits.  Similarly, for a T1-speed satellite channel it
also exceeds 1,000,000 bits.

      Both problems are overcome by letting the TCP decide for itself
the maximum window size, based on the underlying network, and the
current RTT.  The following describes our approach in analyzing and
developing such an implementation.

ANALYSIS

      Here, we have tried to spend some time in deriving the formula
for window size, based on a queuing system model.

      A...