Protocol Action: Advice to link designers on link Automatic Repeat reQues (ARQ) to BCP

[The IESG <[e-mail]>]

The IESG has approved the Internet-Draft 'Advice to link designers on
link Automatic Repeat reQues (ARQ)'
<draft-ietf-pilc-link-arq-issues-04.txt> as a BCP.  This document is
the product of the Performance Implications of Link Characteristics
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner


Technical Summary
 
   This BCP is intended to guide those who configure or tune
   link layer implementations, or design new ones, for constructive
   interaction of link ARQ protocols with the IP level traffic that will
   use the link.

   ARQ protocols exist on many link types, including the radio links in
   2.5 and 3G cellular technologies.  An ARQ protocol retransmits link
   frames that have been corrupted on the physical link.  Link ARQ
   may significantly improve the probability of successful transmission
   of IP packets over links prone to occasional loss.  The document
   categorizes varied ARQ retranmission strategies and persistence types.

   In general, a lowered rate of packet loss benefits transport protocols
   and endhost applications.  Applications using TCP generally benefit
   from Internet paths with little or no loss and low round trip path
   delay (and sufficient link error loss can result in very poor TCP
   performance).  Applications using other transport protocols such as
   UDP and SCTP also benefit from low loss and timely delivery.

   But a general side-effect of link ARQ is that delay is increased
   when frames are retransmitted.  At low error rates, many of the
   details of ARQ, such as degree of persistence or resulting out-of-
   order delivery, become unimportant.  Most frame losses will be
   resolved in one or two retransmission attempts, and this is
   generally unlikely to cause significant impact to e.g. TCP.

   However, on shared high-delay links, the impact of ARQ on multiple
   flows may lead to performance problems, and can be decreased by low
   persistence (that is, by not recovering from 100% of link errors).
   The specification discusses the possible use of link layer awareness
   of flows and classification-based ARQ use.

   During a link outage, interactions between ARQ and multiple flows
   are less significant; the ARQ protocol is likely to be equally
   unsuccessful in retransmitting frames for all flows.  High
   persistence may benefit TCP flows, by enabling prompt recovery once
   the channel is restored.

   Low ARQ persistence is particularly useful where it is difficult or
   impossible to classify traffic flows, and hence treat each flow
   independently, and where the link capacity can accommodate a large
   number of simultaneous flows.

   Link ARQ designers should consider the implications of their design
   in Internet context.  Effects such as increased transit delay,
   jitter, and re-ordering are cumulative when performed on multiple
   links along an Internet path.  Therefore the link impact allowed should
   be as conservative as possible.  In addition, the document recommends
   that further research be done on on non-ARQ error reduction techniques
   such as adaptive data rates, adaptive power, FEC and others, to
   further understand tradeoffs of ARQ choices for the link.


Working Group Summary

   The working group strongly supported advancing this document
   as a BCP.  There were discussions to increase the
   accuracy of its description of ARQ types.  Only one revision was
   needed to capture WG consensus on the recommendations.

Protocol Quality

   The document received extensive reviews on its specifics about ARQ
   techniques  on the PILC WG mailing list.

   The document was reviewed for the IESG by Allison Mankin.