RFC 3155 (rfc3155) - Page 2 of 16

End-to-end Performance Implications of Links with Errors

RFC 3155                PILC - Links with Errors             August 2001


1.0 Introduction

   The rapidly-growing Internet is being accessed by an increasingly
   wide range of devices over an increasingly wide variety of links.  At
   least some of these links do not provide the degree of reliability
   that hosts expect, and this expansion into unreliable links causes
   some Internet protocols, especially TCP [RFC 793], to perform poorly.

   Specifically, TCP congestion control [RFC 2581], while appropriate for
   connections that lose traffic primarily because of congestion and
   buffer exhaustion, interacts badly with uncorrected errors when TCP
   connections traverse links with high uncorrected error rates.  The
   result is that sending TCPs may spend an excessive amount of time
   waiting for acknowledgement that do not arrive, and then, although
   these losses are not due to congestion-related buffer exhaustion, the
   sending TCP transmits at substantially reduced traffic levels as it
   probes the network to determine "safe" traffic levels.

   This document does not address issues with other transport protocols,
   for example, UDP.

   Congestion avoidance in the Internet is based on an assumption that
   most packet losses are due to congestion.  TCP's congestion avoidance
   strategy treats the absence of acknowledgement as a congestion
   signal.  This has worked well since it was introduced in 1988 [VJ-
   DCAC], because most links and subnets have relatively low error rates
   in normal operation, and congestion is the primary cause of loss in
   these environments.  However, links and subnets that do not enjoy low
   uncorrected error rates are becoming more prevalent in parts of the
   Internet.  In particular, these include terrestrial and satellite
   wireless links.  Users relying on traffic traversing these links may
   see poor performance because their TCP connections are spending
   excessive time in congestion avoidance and/or slow start procedures
   triggered by packet losses due to transmission errors.

   The recommendations in this document aim at improving utilization of
   available path capacity over such high error-rate links in ways that
   do not threaten the stability of the Internet.

   Applications use TCP in very different ways, and these have
   interactions with TCP's behavior [RFC 2861].  Nevertheless, it is
   possible to make some basic assumptions about TCP flows.
   Accordingly, the mechanisms discussed here are applicable to all uses
   of TCP, albeit in varying degrees according to different scenarios
   (as noted where appropriate).






Dawkins, et al.          Best Current Practice