Advice to link designers on link Automatic Repeat reQuest (ARQ)
RFC 3366

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                       G. Fairhurst
Request for Comments: 3366                        University of Aberdeen
BCP: 62                                                          L. Wood
Category: Best Current Practice                        Cisco Systems Ltd
                                                             August 2002

    Advice to link designers on link Automatic Repeat reQuest (ARQ)

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document provides advice to the designers of digital
   communication equipment and link-layer protocols employing link-layer
   Automatic Repeat reQuest (ARQ) techniques.  This document presumes
   that the designers wish to support Internet protocols, but may be
   unfamiliar with the architecture of the Internet and with the
   implications of their design choices for the performance and
   efficiency of Internet traffic carried over their links.

   ARQ is described in a general way that includes its use over a wide
   range of underlying physical media, including cellular wireless,
   wireless LANs, RF links, and other types of channel.  This document
   also describes issues relevant to supporting IP traffic over
   physical-layer channels where performance varies, and where link ARQ
   is likely to be used.

Fairhurst & Wood         Best Current Practice                  [Page 1]
RFC 3366          Advice to Link Designers on Link ARQ       August 2002

Table of Contents

   1.    Introduction. . . . . . . . . . . . . . . . . . . . . . . . .2
   1.1   Link ARQ. . . . . . . . . . . . . . . . . . . . . . . . . . .4
   1.2   Causes of Packet Loss on a Link . . . . . . . . . . . . . . .5
   1.3   Why Use ARQ?. . . . . . . . . . . . . . . . . . . . . . . . .6
   1.4   Commonly-used ARQ Techniques. . . . . . . . . . . . . . . . .7
   1.4.1 Stop-and-wait ARQ . . . . . . . . . . . . . . . . . . . . . .7
   1.4.2 Sliding-Window ARQ. . . . . . . . . . . . . . . . . . . . . .7
   1.5   Causes of Delay Across a Link . . . . . . . . . . . . . . . .8
   2.    ARQ Persistence . . . . . . . . . . . . . . . . . . . . . . 10
   2.1   Perfectly-Persistent (Reliable) ARQ Protocols . . . . . . . 10
   2.2   High-Persistence (Highly-Reliable) ARQ Protocols. . . . . . 12
   2.3   Low-Persistence (Partially-Reliable) ARQ Protocols. . . . . 13
   2.4   Choosing Your Persistency . . . . . . . . . . . . . . . . . 13
   2.5   Impact of Link Outages. . . . . . . . . . . . . . . . . . . 14
   3.    Treatment of Packets and Flows. . . . . . . . . . . . . . . 15
   3.1   Packet Ordering . . . . . . . . . . . . . . . . . . . . . . 15
   3.2   Using Link ARQ to Support Multiple Flows. . . . . . . . . . 16
   3.3   Differentiation of Link Service Classes . . . . . . . . . . 17
   4.    Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19
   5.    Security Considerations . . . . . . . . . . . . . . . . . . 21
   6.    IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
   7.    Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 22
   8.    References. . . . . . . . . . . . . . . . . . . . . . . . . 22
   8.1   Normative References. . . . . . . . . . . . . . . . . . . . 22
   8.2   Informative References. . . . . . . . . . . . . . . . . . . 23
   9.    Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26
   10.   Full Copyright Statement. . . . . . . . . . . . . . . . . . 27

1. Introduction

   IP, the Internet Protocol [RFC791], forms the core protocol of the
   global Internet and defines a simple "connectionless" packet-switched
   network.  Over the years, Internet traffic using IP has been carried
   over a wide variety of links, of vastly different capacities, delays
   and loss characteristics.  In the future, IP traffic can be expected
   to continue to be carried over a very wide variety of new and
   existing link designs, again of varied characteristics.

   A companion document [DRAFTKARN02] describes the general issues
   associated with link design.  This document should be read in
   conjunction with that and with other documents produced by the
   Performance Implications of Link Characteristics (PILC) IETF
   workgroup [RFC3135, RFC3155].

Fairhurst & Wood         Best Current Practice                  [Page 2]
RFC 3366          Advice to Link Designers on Link ARQ       August 2002

   This document is intended for three distinct groups of readers:

   a. Link designers wishing to configure (or tune) a link for the IP
      traffic that it will carry, using standard link-layer mechanisms
      such as the ISO High-level Data Link Control (HDLC) [ISO4335a] or
      its derivatives.

   b. Link implementers who may wish to design new link mechanisms that