Browse Prior Art Database

Using Data Link Control-Level Feedback to Control Application Buffer Usage and Packet Loss

IP.com Disclosure Number: IPCOM000122826D
Original Publication Date: 1998-Jan-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 6 page(s) / 311K

Publishing Venue

IBM

Related People

Bader, L: AUTHOR [+6]

Abstract

When current applications run on a network using the Advance Peer to Peer Networking (APPN) protocol, adaptive pacing mechanisms of Logical Unit (LU) 6.2 are used to provide flow control. This is a window based pacing mechanism that is described in detail in the APPN literature. When the High Performance Routing (HPR) function is present, multiple LU 6.2 sessions between a pair of LUs are multiplexed over a Rapid Transport Protocol (RTP) connection, which in turn uses an Adaptive Rate Based (ARB) pacing mechanism.

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

Using Data Link Control-Level Feedback to Control Application Buffer
Usage and Packet Loss

      When current applications run on a network using the Advance
Peer to Peer Networking (APPN) protocol, adaptive pacing mechanisms
of Logical Unit (LU) 6.2 are used to provide flow control.  This is a
window based pacing mechanism that is described in detail in the APPN
literature.  When the High Performance Routing (HPR) function is
present, multiple LU 6.2 sessions between a pair of LUs are
multiplexed over a Rapid Transport Protocol (RTP) connection, which
in turn uses an Adaptive  Rate Based (ARB) pacing mechanism.

      The purpose of a pacing mechanism is to ensure that a fast
sender does not overrun a slow receiver.  Both window based and rate
based pacing mechanisms require the receiving end to provide feedback
to the sender about how much more data can be sent on a connection.
In window based mechanisms, the feedback is in the form of a window
count, which in adaptive pacing is the number of Record Units (RUs)
that the receiver is willing to receive from the sender.  In rate
based pacing mechanisms, the receiver lets the sender know the rate
(e.g., bytes/second) at which the sender can continue to transmit
data.

      In the case of adaptive pacing in LU 6.2, the window size sent
by the receiver to the sender typically depends on the amount of
buffer usage in the receiver node.  In ARB, the local buffer usage,
the difference between the transmission rate of the sender and the
rate at  which data is being received - which indicates network
congestion, as well congestion indicators set by intermediate nodes,
all play a part in determining the rate at which the sender can
continue to send data.

      The above description indicates that while the pacing
algorithms used in APPN/HPR protect buffer usage on the receiver's
node, no consideration is given to buffer usage on the sender's node.
This can  be a particularly severe problem with window based
protocols, but can also be a significant problem with ARB.  The
problem with adaptive pacing  is described first.

      Certain LU 6.2 implementations such as VTAM occasionally return
window sizes (Isolated Pacing Messages, or IPMs) as high as 32767,
the maximum allowed by SNA architecture, to effectively inform the
partner that no pacing will be performed.  Given the fact that a
negotiated RU  size can be as high as 1 Kbytes, this represents more
than 511 Mbytes of  data!  A file transfer application with a
multimegabyte file to transfer,  on a fast machine with a slow link,
can easily deplete the entire buffer  pool on a node.  This can
happen because the only time when an LU 6.2 application is "asked" to
stop sending data is when the pacing count is  0, or when the buffer
pool is depleted, and the former is not a factor in  this scenario.
Data sent by an application is copied to system buffers  for
transmission. Each buffer is queued in the Data Link Co...