rfc3366.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,431 行 · 第 1/5 页

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
      perform well for IP traffic.

   c. The community of people using or developing TCP, UDP and related
      protocols, who may wish to be aware of the ways in which links
      can operate.

   The primary audiences are intended to be groups (a) and (b).  Group
   (c) should not need to be aware of the exact details of an ARQ scheme
   across a single link, and should not have to consider such details
   for protocol implementations; much of the Internet runs across links
   that do not use any form of ARQ.  However, the TCP/IP community does
   need to be aware that the IP protocol operates over a diverse range
   of underlying subnetworks.  This document may help to raise that
   awareness.

   Perfect reliability is not a requirement for IP networks, nor is it a
   requirement for links [DRAFTKARN02].  IP networks may discard packets
   due to a variety of reasons entirely unrelated to channel errors,
   including lack of queuing space, congestion management, faults, and
   route changes.  It has long been widely understood that perfect
   end-to-end reliability can be ensured only at, or above, the
   transport layer [SALT81].

   Some familiarity with TCP, the Transmission Control Protocol [RFC793,
   STE94], is presumed here.  TCP provides a reliable byte-stream
   transport service, building upon the best-effort datagram delivery
   service provided by the Internet Protocol.  TCP achieves this by
   dividing data into TCP segments, and transporting these segments in
   IP packets.  TCP guarantees that a TCP session will retransmit the
   TCP segments contained in any data packets that are lost along the
   Internet path between endhosts.  TCP normally performs retransmission
   using its Fast Retransmit procedure, but if the loss fails to be
   detected (or retransmission is unsuccessful), TCP falls back to a
   Retransmission Time Out (RTO) retransmission using a timer [RFC2581,
   RFC2988].  (Link protocols also implement timers to verify integrity
   of the link, and to assist link ARQ.)  TCP also copes with any
   duplication or reordering introduced by the IP network.  There are a
   number of variants of TCP, with differing levels of sophistication in





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


   their procedures for handling loss recovery and congestion avoidance.
   Far from being static, the TCP protocol is itself subject to ongoing
   gradual refinement and evolution, e.g., [RFC2488, RFC2760].

   Internet networks may reasonably be expected to carry traffic from a
   wide and evolving range of applications.  Not all applications
   require or benefit from using the reliable service provided by TCP.
   In the Internet, these applications are carried by alternate
   transport protocols, such as the User Datagram Protocol (UDP)
   [RFC768].

1.1 Link ARQ

   At the link layer, ARQ operates on blocks of data, known as frames,
   and attempts to deliver frames from the link sender to the link
   receiver over a channel.  The channel provides the physical-layer
   connection over which the link protocol operates.  In its simplest
   form, a channel may be a direct physical-layer connection between the
   two link nodes (e.g., across a length of cable or over a wireless
   medium).  ARQ may also be used edge-to-edge across a subnetwork,
   where the path includes more than one physical-layer medium.  Frames
   often have a small fixed or maximum size for convenience of
   processing by Medium-Access Control (MAC) and link protocols.  This
   contrasts with the variable lengths of IP datagrams, or 'packets'.  A
   link-layer frame may contain all, or part of, one or more IP packets.
   A link ARQ mechanism relies on an integrity check for each frame
   (e.g., strong link-layer CRC [DRAFTKARN02]) to detect channel errors,
   and uses a retransmission process to retransmit lost (i.e., missing
   or corrupted) frames.

   Links may be full-duplex (allowing two-way communication over
   separate forward and reverse channels), half-duplex (where two-way
   communication uses a shared forward and reverse channel, e.g., IrDA,
   IEEE 802.11) or simplex (where a single channel permits communication
   in only one direction).

   ARQ requires both a forward and return path, and therefore link ARQ
   may be used over links that employ full- or half-duplex links.  When
   a channel is shared between two or more link nodes, a link MAC
   protocol is required to ensure all nodes requiring transmission can
   gain access to the shared channel.  Such schemes may add to the delay
   (jitter) associated with transmission of packet data and ARQ control
   frames.

   When using ARQ over a link where the probability of frame loss is
   related to the frame size, there is an optimal frame size for any
   specific target channel error rate.  To allow for efficient use of
   the channel, this maximum link frame size may be considerably lower



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


   than the maximum IP datagram size specified by the IP Maximum
   Transmission Unit (MTU).  Each frame will then contain only a
   fraction of an IP packet, and transparent implicit fragmentation of
   the IP datagram is used [DRAFTKARN02].  A smaller frame size
   introduces more frame header overhead per payload byte transported.

   Explicit network-layer IP fragmentation is undesirable for a variety
   of reasons, and should be avoided [KEN87, DRAFTKARN02].  Its use can
   be minimized with use of Path MTU discovery [RFC1191, RFC1435,
   RFC1981].

   Another way to reduce the frame loss rate (or reduce transmit signal
   power for the same rate of frame loss) is to use coding, e.g.,
   Forward Error Correction (FEC) [LIN93].

   FEC is commonly included in the physical-layer design of wireless
   links and may be used simultaneously with link ARQ.  FEC schemes
   which combine modulation and coding also exist, and may also be
   adaptive.  Hybrid ARQ [LIN93] combines adaptive FEC with link ARQ
   procedures to reduce the probability of loss of retransmitted frames.
   Interleaving may also be used to reduce the probability of frame loss
   by dispersing the occurrence of errors more widely in the channel to
   improve error recovery; this adds further delay to the channel's
   existing propagation delay.

   The document does not consider the use of link ARQ to support a
   broadcast or multicast service within a subnetwork, where a link may
   send a single packet to more than one recipient using a single link
   transmit operation.  Although such schemes are supported in some
   subnetworks, they raise a number of additional issues not examined
   here.

   Links supporting stateful reservation-based quality of service (QoS)
   according to the Integrated Services (intserv) model are also not
   explicitly discussed.

1.2 Causes of Packet Loss on a Link

   Not all packets sent to a link are necessarily received successfully
   by the receiver at the other end of the link.  There are a number of
   possible causes of packet loss.  These may occur as frames travel
   across a link, and include:

   a. Loss due to channel noise, often characterised by random frame
      loss.  Channel noise may also result from other traffic degrading
      channel conditions.





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


   b. Frame loss due to channel interference.  This interference can