rfc3366.txt

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

      be random, structured, and in some cases even periodic.

   c. A link outage, a period during which the link loses all or
      virtually all frames, until the link is restored.  This is a
      common characteristic of some types of link, e.g., mobile cellular
      radio.

   Other forms of packet loss are not related to channel conditions,
   but include:

   i.   Loss of a frame transmitted in a shared channel where a
        contention-aware MAC protocol is used (e.g., due to collision).
        Here, many protocols require that retransmission is deferred to
        promote stability of the shared channel (i.e., prevent excessive
        channel contention).  This is discussed further in section 1.5.

   ii.  Packet discards due to congestion.  Queues will eventually
        overflow as the arrival rate of new packets to send continues to
        exceed the outgoing packet transmission rate over the link.

   iii. Loss due to implementation errors, including hardware faults
        and software errors.  This is recognised as a common cause of
        packet corruption detected in the endhosts [STONE00].

   The rate of loss and patterns of loss experienced are functions of
   the design of the physical and link layers.  These vary significantly
   across different link configurations.  The performance of a specific
   implementation may also vary considerably across the same link
   configuration when operated over different types of channel.

1.3 Why Use ARQ?

   Reasons that encourage considering the use of ARQ include:

   a. ARQ across a single link has a faster control loop than TCP's
      acknowledgement control loop, which takes place over the longer
      end-to-end path over which TCP must operate.  It is therefore
      possible for ARQ to provide more rapid retransmission of TCP
      segments lost on the link, at least for a reasonable number of
      retries [RFC3155, SALT81].

   b. Link ARQ can operate on individual frames, using implicit
      transparent link fragmentation [DRAFTKARN02].  Frames may be
      much smaller than IP packets, and repetition of smaller frames
      containing lost or errored parts of an IP packet may improve the
      efficiency of the ARQ process and the efficiency of the link.




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


   A link ARQ procedure may be able to use local knowledge that is not
   available to endhosts, to optimise delivery performance for the
   current link conditions.  This information can include information
   about the state of the link and channel, e.g., knowledge of the
   current available transmission rate, the prevailing error
   environment, or available transmit power in wireless links.

1.4 Commonly-used ARQ Techniques

   A link ARQ protocol uses a link protocol mechanism to allow the
   sender to detect lost or corrupted frames and to schedule
   retransmission.  Detection of frame loss may be via a link protocol
   timer, by detecting missing positive link acknowledgement frames, by
   receiving explicit negative acknowledgement frames and/or by polling
   the link receiver status.

   Whatever mechanisms are chosen, there are two easily-described
   categories of ARQ retransmission process that are widely used:

1.4.1 Stop-And-Wait ARQ

   A sender using stop-and-wait ARQ (sometimes known as 'Idle ARQ'
   [LIN93]) transmits a single frame and then waits for an
   acknowledgement from the receiver for that frame.  The sender then
   either continues transmission with the next frame, or repeats
   transmission of the same frame if the acknowledgement indicates that
   the original frame was lost or corrupted.

   Stop-and-wait ARQ is simple, if inefficient, for protocol designers
   to implement, and therefore popular, e.g., tftp [RFC1350] at the
   transport layer.  However, when stop-and-wait ARQ is used in the link
   layer, it is well-suited only to links with low bandwidth-delay
   products.  This technique is not discussed further in this document.

1.4.2 Sliding-Window ARQ

   A protocol using sliding-window link ARQ [LIN93] numbers every frame
   with a unique sequence number, according to a modulus.  The modulus
   defines the numbering base for frame sequence numbers, and the size
   of the sequence space.  The largest sequence number value is viewed
   by the link protocol as contiguous with the first (0), since the
   numbering space wraps around.









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


   TCP is itself a sliding-window protocol at the transport layer
   [STE94], so similarities between a link-interface-to-link-interface
   protocol and end-to-end TCP may be recognisable.  A sliding-window
   link protocol is much more complex in implementation than the simpler
   stop-and-wait protocol described in the previous section,
   particularly if per-flow ordering is preserved.

   At any time the link sender may have a number of frames outstanding
   and awaiting acknowledgement, up to the space available in its
   transmission window.  A sufficiently-large link sender window
   (equivalent to or greater than the number of frames sent, or larger
   than the bandwidth*delay product capacity of the link) permits
   continuous transmission of new frames.  A smaller link sender window
   causes the sender to pause transmission of new frames until a timeout
   or a control frame, such as an acknowledgement, is received.  When
   frames are lost, a larger window, i.e., more than the link's
   bandwidth*delay product, is needed to allow continuous operation
   while frame retransmission takes place.

   The modulus numbering space determines the size of the frame header
   sequence number field.  This sequence space needs to be larger than
   the link window size and, if using selective repeat ARQ, larger than
   twice the link window size.  For continuous operation, the sequence
   space should be larger than the product of the link capacity and the
   link ARQ persistence (discussed in section 2), so that in-flight
   frames can be identified uniquely.

   As with TCP, which provides sliding-window delivery across an entire
   end-to-end path rather than across a single link, there are a large
   number of variations on the basic sliding-window implementation, with
   increased complexity and sophistication to make them suitable for
   various conditions.  Selective Repeat (SR), also known as Selective
   Reject (SREJ), and Go-Back-N, also known as Reject (REJ), are
   examples of ARQ techniques using protocols implementing sliding
   window ARQ.

1.5 Causes of Delay Across a Link

   Links and link protocols contribute to the total path delay
   experienced between communicating applications on endhosts.  Delay
   has a number of causes, including:

   a. Input packet queuing and frame buffering at the link head before
      transmission over the channel.

   b. Retransmission back-off, an additional delay introduced for
      retransmissions by some MAC schemes when operating over a shared
      channel to prevent excessive contention.  A high level of



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


      contention may otherwise arise, if, for example, a set of link
      receivers all retransmitted immediately after a collision on a
      busy shared channel.  Link ARQ protocols designed for shared
      channels may select a backoff delay, which increases with the
      number of attempts taken to retransmit a frame; analogies can be
      drawn with end-to-end TCP congestion avoidance at the transport
      layer [RFC2581].  In contrast, a link over a dedicated channel
      (which has capacity pre-allocated to the link) may send a
      retransmission at the earliest possible time.

   c. Waiting for access to the allocated channel when the channel is
      shared.  There may be processing or protocol-induced delay
      before transmission takes place [FER99, PAR00].

   d. Frame serialisation and transmission processing.  These are
      functions of frame size and the transmission speed of the link.

   e. Physical-layer propagation time, limited by the speed of
      transmission of the signal in the physical medium of the
      channel.

   f. Per-frame processing, including the cost of QoS scheduling,
      encryption, FEC and interleaving.  FEC and interleaving also add
      substantial delay and, in some cases, additional jitter.  Hybrid
      link ARQ schemes [LIN93], in particular, may incur significant
      receiver processing delay.

   g. Packet processing, including buffering frame contents at the
      link receiver for packet reassembly, before onward transmission
      of the packet.

   When link ARQ is used, steps (b), (c), (d), (e), and (f) may be
   repeated a number of times, every time that retransmission of a frame
   occurs, increasing overall delay for the packet carried in part by
   the frame.  Adaptive ARQ schemes (e.g., hybrid ARQ using adaptive FEC
   codes) may also incur extra per-frame processing for retransmitted
   frames.

   It is important to understand that applications and transport
   protocols at the endhosts are unaware of the individual delays
   contributed by each link in the path, and only see the overall path
   delay.  Application performance is therefore determined by the
   cumulative delay of the entire end-to-end Internet path.  This path
   may include an arbitrary or even a widely-fluctuating number of
   links, where any link may or may not use ARQ.  As a result, it is not
   possible to state fixed limits on the acceptable delay that a link
   can add to a path; other links in the path will add an unknown delay.




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


2. ARQ Persistence

   ARQ protocols may be characterised by their persistency.  Persistence
   is the willingness of the protocol to retransmit lost frames to
   ensure reliable delivery of traffic across the link.

   A link's retransmission persistency defines how long the link is
   allowed to delay a packet, in an attempt to transmit all the frames
   carrying the packet and its content over the link, before giving up
   and discarding the packet.  This persistency can normally be measured
   in milliseconds, but may, if the link propagation delay is specified,
   be expressed in terms of the maximum number of link retransmission
   attempts permitted.  The latter does not always map onto an exact
   time limit, for the reasons discussed in section 1.5.

   An example of a reliable link protocol that is perfectly persistent
   is the ISO HDLC protocol in the Asynchronous Balanced Mode (ABM)
   [ISO4335a].

   A protocol that only retransmits a number of times before giving up
   is less persistent, e.g., Ethernet [FER99], IEEE 802.11, or GSM RLP
   [RFC2757].  Here, lower persistence also ensures stability and fair
   sharing of a shared channel, even when many senders are attempting
   retransmissions.

   TCP, STCP [RFC2960] and a number of applications using UDP (e.g.,
   tftp) implement their own end-to-end reliable delivery mechanisms.
   Many TCP and UDP applications, e.g., streaming multimedia, benefit
   from timely delivery from lower layers with sufficient reliability,
   rather than perfect reliability with increased link delays.

2.1 Perfectly-Persistent (Reliable) ARQ Protocols

   A perfectly-persistent ARQ protocol is one that attempts to provide a
   reliable service, i.e., in-order delivery of packets to the other end
   of the link, with no missing packets and no duplicate packets.  The
   perfectly-persistent ARQ protocol will repeat a lost or corrupted
   frame an indefinite (and potentially infinite) number of times until
   the frame is successfully received.

   If traffic is going no further than across one link, and losses do
   not occur within the endhosts, perfect persistence ensures
   reliability between the two link ends without requiring any
   higher-layer protocols.  This reliability can become
   counterproductive for traffic traversing multiple links, as it
   duplicates and interacts with functionality in protocol mechanisms at
   higher layers [SALT81].




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


   Arguments against the use of perfect persistence for IP traffic
   include:

   a. Variable link delay; the impact of ARQ introduces a degree of
      jitter, a function of the physical-layer delay and frame
      serialisation and transmission times (discussed in section 1.5),
      to all flows sharing a link performing frame retransmission.