Protocol Action: Advice to link designers on link Automatic Repeat reQues (ARQ) to BCP
The IESG <iesg-secretary@ietf.org> Fri, 05 April 2002 21:47 UTC
Message-Id: <200204052147.QAA19841@ietf.org>
To: IETF-Announce: ;;, @grc.nasa.gov
Cc: RFC Editor <rfc-editor@ISI.EDU>, Internet Architecture Board <iab@ISI.EDU>,
pilc@grc.nasa.gov
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Advice to link designers on link Automatic
Repeat reQues (ARQ) to BCP
Date: Fri, 05 Apr 2002 16:47:51 -0500
Sender: owner-pilc@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3696
Lines: 78
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.