RFC 3366

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

📅 published September 2002, from ietf

RFC 3366 🦋

Okay bestie, here's the front-page tea ☕. This is RFC 3366, called "Advice to link designers on link Automatic Repeat reQuest (ARQ)" ✨. It came out in August 2002 from the Network Working Group. It's a Best Current Practice (that's BCP 62 for the nerds 🤓), and it was written by G. Fairhurst of the University of Aberdeen and L. Wood of Cisco Systems Ltd. The title block doesn't list anything it obsoletes or updates, so it's giving independent main character energy 💅.

Status of This Memo 🎀

So this document is an Internet Best Current Practice for the Internet Community, and it's asking everyone to talk about it and suggest improvements 🫶. Distribution of this memo is unlimited, so share it with your whole group chat 💜.

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

Abstract ✨

Okay so this doc is giving advice to the people designing digital communication equipment and link-layer protocols that use link-layer Automatic Repeat reQuest (ARQ) techniques 🔥. It assumes these designers do want to support Internet protocols, but they might not know much about how the Internet is built or how their design choices affect the performance and efficiency of Internet traffic on their links 🙈.

ARQ gets described in a general way, so it covers lots of physical media: cellular wireless, wireless LANs, RF links, and other kinds of channels 🧚. It also talks about IP traffic over physical-layer channels where performance keeps changing, and where link ARQ is likely to get used 🌈.

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 🧚‍♀️

Okay, so IP, the Internet Protocol [RFC791], is the core protocol of the whole global Internet, and it's a simple "connectionless" packet-switched network 💖. Over the years, IP traffic has ridden over a huge mix of links with wildly different capacities, delays, and loss characteristics 🌸. And honestly, IP traffic will keep being carried over a super wide variety of new and existing link designs, each with its own vibe 🌈.

There's a companion doc, [DRAFTKARN02], that goes over the general issues with link design ✨. You should read this one together with that one, plus other documents from the Performance Implications of Link Characteristics (PILC) IETF workgroup [RFC3135, RFC3155] 📚.

This document is meant for three different groups of readers 👑:

a. Link designers who want to set up (or tune) a link for the IP traffic it will carry, using standard link-layer mechanisms like the ISO High-level Data Link Control (HDLC) [ISO4335a] or its derivatives.

b. Link implementers who might want to design new link mechanisms that perform well for IP traffic.

c. The community of people who use or develop TCP, UDP, and related protocols, and who might want to know the ways links can operate.

Groups (a) and (b) are the main audience 🎯. Group (c) doesn't need to know the exact details of an ARQ scheme across a single link, and it doesn't have to think about those details for protocol implementations 🙈. Lots of the Internet runs across links that don't use any form of ARQ at all. Still, the TCP/IP community does need to know that IP runs over a really diverse range of underlying subnetworks, and this document might help with that awareness 💅.

Perfect reliability isn't a requirement for IP networks, and it isn't a requirement for links either [DRAFTKARN02] 🫶. IP networks can throw away packets for all sorts of reasons that have nothing to do with channel errors, like running out of queuing space, congestion management, faults, and route changes 😭. It's been widely understood for a long time that perfect end-to-end reliability can only be ensured at, or above, the transport layer [SALT81] 🔥.

You should already be a bit familiar with TCP, the Transmission Control Protocol [RFC793, STE94] 🎀. TCP gives a reliable byte-stream transport service on top of the best-effort datagram delivery service that IP provides 🦋. It does this by chopping data into TCP segments and carrying those segments in IP packets 📦. TCP guarantees that a TCP session will retransmit the TCP segments in any data packets that get lost along the Internet path between endhosts 💜. Normally it retransmits using its Fast Retransmit procedure, but if the loss isn't detected (or the retransmission doesn't work), TCP falls back to a Retransmission Time Out (RTO) retransmission that uses a timer [RFC2581, RFC2988] ⏰. (Link protocols also use timers to check the integrity of the link and to help link ARQ 🧠.) TCP also handles any duplication or reordering that the IP network introduces 🙌. There are a bunch of TCP variants, with different levels of sophistication in how they handle loss recovery and congestion avoidance 🌈. TCP isn't static at all. It keeps getting gradual refinement and evolution, e.g., [RFC2488, RFC2760] ✨.

Internet networks can reasonably be expected to carry traffic from a wide and changing range of applications 🍓. Not every application needs or benefits from the reliable service TCP provides 🙈. On the Internet, those applications run over alternate transport protocols, like the User Datagram Protocol (UDP) [RFC768] 🧚.

Here's the link-layer picture 🖼️. ARQ works on blocks of data called frames, and it tries to deliver frames from the link sender to the link receiver over a channel 🎀. The channel is the physical-layer connection that the link protocol runs over 🔌. In its simplest form, a channel can be a direct physical-layer connection between the two link nodes, like a length of cable or a wireless medium 📡. ARQ can also be used edge-to-edge across a subnetwork, where the path has more than one physical-layer medium 🛤️.

Frames usually have a small fixed or maximum size so that Medium-Access Control (MAC) and link protocols can process them easily 🧩. That's different from IP datagrams, which come in variable lengths and are also called 'packets' 📏. A link-layer frame might hold all of one or more IP packets, or just part of them 🍰.

A link ARQ mechanism relies on an integrity check for each frame (e.g., a strong link-layer CRC [DRAFTKARN02]) to detect channel errors 🔍. It then uses a retransmission process to resend lost frames, meaning frames that are missing or corrupted 🔁.

Links can be full-duplex (two-way communication over separate forward and reverse channels), half-duplex (two-way communication sharing one forward and reverse channel, e.g., IrDA or IEEE 802.11), or simplex (one channel that only lets communication go in one direction) ↔️.

ARQ needs both a forward and a return path, so link ARQ can be used over links that have full- or half-duplex 🤝. When a channel is shared between two or more link nodes, a link MAC protocol is required so that every node that needs to transmit can get access to the shared channel 🚦. These schemes can add delay (jitter) to the transmission of packet data and ARQ control frames 🐢.

When ARQ runs over a link where the chance of frame loss depends on the frame size, there's an optimal frame size for any specific target channel error rate ✨. To use the channel efficiently, this maximum link frame size may end up being a lot lower than the maximum IP datagram size set by the IP Maximum Transmission Unit (MTU) 📉. Then each frame carries only a fraction of an IP packet, and transparent implicit fragmentation of the IP datagram is used [DRAFTKARN02] 🧃. Smaller frames mean more frame header overhead for each payload byte transported 😬.

Explicit network-layer IP fragmentation is undesirable for a bunch of reasons, and it should be avoided [KEN87, DRAFTKARN02] 🚫. You can cut down how much it's used by using Path MTU discovery [RFC1191, RFC1435, RFC1981] 🔎.

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

FEC is commonly built into the physical-layer design of wireless links, and it can be used at the same time as link ARQ 📶. There are also FEC schemes that combine modulation and coding, and those can be adaptive too 🎛️. Hybrid ARQ [LIN93] mixes adaptive FEC with link ARQ procedures to lower the chance that retransmitted frames get lost 🔄. Interleaving can also cut the frame loss probability by spreading errors more widely across the channel so recovery works better, but it adds more delay on top of the channel's existing propagation delay 🕰️.

This document doesn't look at using link ARQ to support a broadcast or multicast service inside a subnetwork, where a link can send a single packet to more than one recipient in one link transmit operation 📣. Some subnetworks do support those schemes, but they bring up a bunch of extra issues that aren't covered here 🙃.

Links that support stateful reservation-based quality of service (QoS) under the Integrated Services (intserv) model aren't explicitly discussed here either 🚧.

Part 1 of 6 is done! 🎉 More parts are coming, so stay tuned, bestie 💅🌈

okay so not every packet you send down a link actually reaches the receiver on the other end 😭 there are a bunch of reasons frames can get lost along the way 💅 these can happen while frames are travelling across a link, and they include:

a. Loss due to channel noise, which often looks like random frame loss 🌸 channel noise can also come from other traffic making the channel conditions worse 🫶

b. Frame loss due to channel interference 📡 this interference can be random, structured, and in some cases even periodic 🔥

c. A link outage, which is a period where the link loses all or virtually all frames until it's restored 💀 this is a super common thing on some types of link, e.g., mobile cellular radio 📱

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

i. Loss of a frame sent over a shared channel where a contention-aware MAC protocol is in use (e.g., due to collision) 💥 here, lots of protocols want retransmission to be deferred so the shared channel stays stable (aka no excessive channel contention) 🧘 this gets talked about more in section 1.5 🎀

ii. Packet discards due to congestion 🚦 queues will eventually overflow when new packets keep arriving faster than they can be sent out 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 the patterns of loss you get depend on the design of the physical and link layers 🧩 these vary a lot across different link configurations 🌈 and how one specific implementation performs can also vary quite a bit across the same link configuration when it's run 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 runs over the longer end-to-end path TCP has to work with 🏃‍♀️ so it's possible for ARQ to retransmit TCP segments lost on the link more rapidly, 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 can be much smaller than IP packets, and repeating the smaller frames that hold lost or errored parts of an IP packet may improve the efficiency of the ARQ process and the efficiency of the link 💜

A link ARQ procedure may be able to use local knowledge that endhosts simply don't have, so it can optimise delivery for the current link conditions 🧠 this info can include the state of the link and channel, like the current available transmission rate, the prevailing error environment, or the available transmit power in wireless links 📶

1.4 Commonly-used ARQ Techniques

A link ARQ protocol uses a link protocol mechanism so the sender can detect lost or corrupted frames and schedule retransmission 🗓️ detecting frame loss can happen via a link protocol timer, by spotting missing positive link acknowledgement frames, by receiving explicit negative acknowledgement frames, and/or by polling the link receiver status 🕵️‍♀️

Whatever mechanisms get chosen, there are two easy-to-describe 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 🛑 after that, the sender either carries on with the next frame, or repeats the same frame if the acknowledgement says the original got lost or corrupted 🔁

Stop-and-wait ARQ is simple, if inefficient, for protocol designers to implement, which is why it's so popular, e.g., tftp [RFC1350] at the transport layer 🥰 however, when stop-and-wait ARQ is used in the link layer, it's only well-suited to links with low bandwidth-delay products 😬 this technique isn't 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 🔄

TCP is itself a sliding-window protocol at the transport layer [STE94], so you might notice similarities between a link-interface-to-link-interface protocol and end-to-end TCP 👯‍♀️ a sliding-window link protocol is way more complex to implement than the simpler stop-and-wait protocol from the previous section, especially 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 huge number of variations on the basic sliding-window implementation 🌷 they get more complex and sophisticated to suit 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 that implement sliding window ARQ 💖

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, which is an additional delay introduced for retransmissions by some MAC schemes when operating over a shared channel, to prevent excessive contention 🙅 a high level of 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 retransmission of a frame occurs, increasing the 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's not possible to state fixed limits on the acceptable delay that a link can add to a path, because other links in the path will add an unknown delay 🤷‍♀️

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 doesn't 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 helps keep things stable and fairly shared on 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 ✨

Okay so a perfectly-persistent ARQ protocol is the total overachiever 💅 It tries to give you a fully reliable service: packets arrive in order at the other end of the link, with no missing packets and no duplicates, periodt. If a frame gets lost or corrupted, it keeps resending it an indefinite (and potentially infinite) number of times until that frame finally gets through 🫶

If traffic only crosses one link and nothing gets lost inside the endhosts, perfect persistence gives you reliability between the two link ends with no higher-layer protocols needed 🎀 Lowkey though, this can backfire for traffic crossing multiple links, because it doubles up on and interacts with stuff that higher-layer protocol mechanisms are already doing [SALT81] 🙈

Here's the tea on why perfect persistence is a hard sell for IP traffic:

  • (a) Variable link delay: ARQ adds a bit of jitter 🦋 The amount depends on the physical-layer delay and on how long frames take to serialise and transmit (more on that in section 1.5). Every flow sharing a link that's doing frame retransmission gets hit by it.
  • (b) No clear ceiling on retransmission delay: Perfect persistence doesn't give you a clear upper bound on how long retransmission can take on the link 😭 Big swings in path delay caused by lots of link retransmissions can make TCP retransmission timers go off, although a high variance in link delay and the resulting overall path delay might also cause a large TCP RTO value to get picked [LUD99b, PAR00]. This changes TCP throughput and drops overall performance, but on the plus side it can also cut down on timeouts caused by continued packet loss.
  • (c) Redundant reliability: Apps that need perfectly-reliable delivery can build a form of perfectly-persistent ARQ on their own, or use a reliable transport protocol in the endhosts 💖 Doing perfect persistence on every link along the path between the endhosts is redundant, and it still can't match the reliability of end-to-end transport [SALT81].
  • (d) Don't slow down the control info: Link ARQ should not adversely delay the flow of end-to-end control information 👑 For example, ARQ retransmitting data for one or more flows should not excessively stretch the protocol control loops. If duplicate TCP acknowledgements (dupacks [STE94, BAL97]), SACK, or Explicit Congestion Notification (ECN) indicators get delayed too much, TCP flows become less responsive to congestion events. TCP-Friendly Rate Control (TFRC) has similar problems, since it uses equation-based congestion control with UDP [DRAFTHAN01] 😩

Perfectly-persistent link protocols that do unlimited ARQ, meaning they keep retransmitting frames until those frames get through, are seldom found in real implementations 🥲

Most practical link protocols do give up retransmitting at some point, but not necessarily because they're trying to bound ARQ retransmission persistence. A protocol might, for example, stop retransmitting after a link connection failure, such as when no frames have been successfully received within a pre-configured timer period ⏰ So the number of times a protocol retransmits a specific frame (or the maximum number of retransmissions) ends up depending on lots of different parameters (the ARQ procedure, link timer values, and the procedure for link monitoring), rather than being pre-configured 🧚

Another common vibe here is that some protocol implementers assume that, after a link failure, packets queued to go over the link are no longer significant and can be discarded when ARQ retransmission gets abandoned 🗑️

Examples of perfectly-persistent ARQ protocols include ISO/ITU-T LAP-B [ISO7776] and ISO HDLC in Asynchronously Balanced Mode (ABM) [ISO4335a], for instance using Multiple Selective Reject (MSREJ [ISO4335b]). These protocols will retransmit a frame an unlimited number of times until receipt of that frame is acknowledged 🌸

2.2 High-Persistence (Highly-Reliable) ARQ Protocols 💜

High-persistence ARQ protocols put a limit on the number of times (or the number of attempts) that ARQ can retransmit a particular frame. Once that limit's hit, the sender gives up on the missing frame and moves on to forwarding the subsequent buffered in-sequence frames 🏃‍♀️ Giving up on retransmitting a frame doesn't mean the link has lost connectivity, and it doesn't trigger a link protocol state change either.

It's been recommended that a single IP packet should never get held up by the network for longer than the Maximum Segment Lifetime (MSL) of 120 seconds defined for TCP [RFC1122]. The thing is, it's really hard in practice to bound the maximum path delay of an Internet path 🤷‍♀️ Segment (packet) lifetime can matter a lot where alternate paths with different delays exist between endhosts and route flapping or flow-unaware traffic engineering is in use. Some TCP packets might take a short path while others take a much longer one, for example by using persistent ARQ over a link outage 🛣️

If you don't limit the maximum packet lifetime, TCP sequence numbers can wrap around at high transmission rates. Then old data segments might get confused with newer ones if the sequence number space has run out and been reused in the meantime 😱 Some TCP implementations use the Round Trip Timestamp Measurement (RTTM) option in TCP packets to clear up this ambiguity, using the Protection Against Wrapped Sequence number (PAWS) algorithm [RFC1323] ✨

In practice, the MSL is usually really big compared to the typical TCP RTO. The TCP RTO gets calculated from the estimated round-trip path delay [RFC2988]. If the number of link retransmissions makes the path delay bigger than the RTO value, the TCP retransmission timer can expire, which leads to a timeout and a retransmission of a segment (packet) by the TCP sender 💀

High persistency might be great for bulk flows, but the extra delay (and the variations in delay) it adds can be super undesirable for other types of flows 🙅‍♀️ Being able to treat flows separately, with different classes of link service, is really useful, and we'll get into that in section 3.

Examples of high-persistence ARQ protocols include [BHA97, ECK98, LUD99a, MEY99] 🍓

2.3 Low-Persistence (Partially-Reliable) ARQ Protocols 🌈

Here's how a link using a low-persistence ARQ protocol can be summed up:

  • (a) The link isn't perfectly reliable and doesn't guarantee delivery. The transmitter will discard some frames as it 'gives up' before getting an acknowledgement of successful transmission across the link 🥀
  • (b) There's a lowered limit on the maximum added delay that IP packets experience when travelling across the link (usually lower than the TCP path RTO). This cuts down on interaction with TCP timers or with UDP-based error-control schemes ⏱️
  • (c) The link offers a low bound on how long retransmission of any one frame can hold up the completed transmission and assembly of other correctly and completely-received IP packets whose transmission started before the missing frame was sent. Limiting the delay stops things from getting worse with contention or with interaction between different packet flows (see also section 3.2) 🫧

Examples of low-persistence ARQ protocols include [SAM96, WARD95, CHE00] 💅

2.4 Choosing Your Persistency 💭

The TCP Maximum RTO is the upper limit on how long TCP will wait before it does a retransmission. Most TCP implementations generally have a TCP RTO of at least several times the path delay ⏳

Setting a lower link persistency (something on the order of 2-5 retransmission attempts) cuts down on potential interaction with the TCP RTO timer. That can reduce the chance of duplicate copies of the same packet sitting in the link transmit buffer under certain loss patterns 🧃

A link using a physical layer with low propagation delay might let tens of retransmission attempts deliver a single frame and still meet the bound for (b) in section 2.3 🚀 Here, a low delay means the total packet transmission time across the link is much less than 100 ms (a common value for the granularity of the internal TCP system timer).

A packet may cross a bunch of successive links on its total end-to-end path. That's an argument for much lower persistency on any individual link, since delay from persistency piles up along the path each packet takes 🛤️

Some implementers have gone with lower persistence, leaning on TCP or on a UDP application's judgement to retransmit any packets the link ARQ protocol doesn't recover 🫶

Okay bestie, links with persistent loss need attention too. This is where lots of consecutive frames get corrupted over a long stretch of time 😭. Fading, roaming, and some kinds of interference can all cause this kind of channel behaviour. During the loss event, a retransmission request is more likely to get corrupted, and a retransmitted frame is more likely to get lost too. People call this a "transient outage" 🦋.

If the transient outage lasts longer than the TCP RTO, the TCP sender also does its own transport-layer retransmission 🔁. At the same time, it drops its congestion window (cwnd) down to 1 segment (packet), recalculates its RTO, and waits for an ACK packet 🥺. If no acknowledgement comes back, TCP retransmits again, up to a retry limit. The only way TCP figures out the outage is over (so, that path capacity is restored) is by receiving an ACK ✨. Here's the tea: if link ARQ persistency makes a link in the path discard that ACK, the TCP sender has to wait for the next RTO retransmission and its ACK to learn the link is back. That can be many seconds after the transient outage ended 💀.

When a link layer can tell apart a set of link service classes (see section 3.3), a link ARQ persistency longer than the largest link loss event may benefit a TCP session 👑. This would let TCP restart transmission quickly without waiting for a retransmission time out, which generally improves TCP performance during transient outages. Implementing these schemes is still a research issue 🧪.

When an outage hits a sender that shares a common channel with other nodes, uncontrolled high persistence can keep eating transmission resources for the whole outage 😤. That's not ideal, because it cuts into the capacity left for the other nodes on the channel, who may not be experiencing the same outage at all. Those nodes could be using the channel for more productive transfers. In these cases, another controlling mechanism often limits the persistence. To counter these contention effects, ARQ protocols may delay retransmission requests, or defer retransmitting requested frames until the outage ends for the sender 🫶.

Another approach, for a link layer that can identify separate flows, is to use low link persistency (section 2.3) together with a higher-layer mechanism 🌈. For example, one mechanism tries to deliver one packet (or whole TCP segment) per TCP flow after a loss event [DRAFTKARN02]. The goal is to make sure TCP transmission gets restored fast ⚡. How to implement this is still an area of research 🔬.

3. Treatment of Packets and Flows 🍓

3.1. Packet Ordering 📦

Here's a big debate: should a link be allowed to forward packets in a different order from the one they arrived in at its transmit interface? 🤔

IP networks aren't required to deliver every IP packet in order, but in most cases they do deliver IP packets in their original transmission order 💅. Routers that support class-based queuing do reorder received packets, since they reorder packets across different flows. Usually though, they keep the ordering within each flow 🧚.

Policy-based queuing, which gives fairer access to the link, can also reorder packets 🎀. There's still a lot of debate about the best algorithms and the best queue sizes for particular link speeds. This isn't related to link ARQ, though. It applies to any (potential) bottleneck router 🙄.

Small amounts of reordering are common in IP networks [BEN00], but significant reordering within a flow is undesirable because it can cause a bunch of problems 😩:

  • a. Reordering increases packet jitter for real-time applications. That can lead to application data loss if the receiving application uses a small play-out buffer 🎵.
  • b. Reordering interleaves the arrival of TCP segments, which leads to duplicate ACKs (dupacks), and dupacks lead to assumptions of loss 🙃. When the TCP sender gets an ACK followed by a sequence of three identical dupacks, it triggers fast retransmission and recovery, which is a form of congestion avoidance. That's because TCP always presumes packet loss is due to congestion [RFC2581, STE94]. This lowers TCP throughput efficiency as far as the application is concerned, although it should not hurt data integrity 💖.

Reordering can also mess with some existing poorly-implemented TCP/IP stacks 🤦. It can cause unwanted side-effects in poorly-implemented IP fragment reassembly code, poorly-implemented IP demultiplexing (filter) code, or poorly-implemented UDP applications.

Ordering effects also have to be considered when you break the end-to-end paradigm and evaluate transport-layer relays, such as split-TCP implementations or Protocol Enhancing Proxies [RFC3135] 🧩.

Just like total path delay, TCP and UDP flows are affected by the cumulative effect of reordering along the whole path 🛣️. Link protocol designers must not assume their link is the only one doing packet reordering. Some reordering may be introduced by other links along the same path, or by router processing inside the network [BEN00]. Ideally, the link protocol should not contribute to reordering within a flow, or at least make sure it doesn't significantly increase the level of reordering within the flow 🌸. To achieve that, buffering is required at the link receiver. The total buffering needed depends on the link's bandwidth*delay product and the level of ARQ persistency, and it's bounded by the link window size 📏.

A number of experimental ARQ protocols have allowed out-of-order delivery [BAL95, SAM96, WARD95] 🧪.

Most links are expected to carry more than one IP flow at a time 💜. Some high-capacity links are expected to carry a very large number of simultaneous flows, often to and from lots of different endhosts. With multiple applications running on one endhost, multiple flows are the norm rather than the exception, even on last-hop links 🙌.

When packets from several flows are in transit within a link ARQ protocol at the same time, ARQ can cause a few extra effects 👀:

  • a. ARQ introduces variable delay (jitter) to a TCP flow that shares a link with another flow experiencing loss. That extra delay comes from the link needing to provide in-sequence delivery of packets. It may hurt other applications sharing the link, and it can lengthen the initial slow-start period for TCP flows for those applications 🐢. This matters a lot for short-lived TCP flows (like the ones used by HTTP/1.0 and earlier), which spend most of their lives in slow-start 😵.
  • b. ARQ introduces jitter to UDP flows that share a link with another flow experiencing loss 🎧. An end-to-end protocol may not need reliable delivery for its flows, especially if it's supporting a delay-sensitive application ⏱️.
  • c. High-persistence ARQ may delay packets long enough to trigger the premature timeout of another TCP flow's RTO timer 😬. Modern TCP implementations shouldn't run into this, though, since their computed RTO values should leave a sufficient margin over path RTTs to handle reasonable amounts of jitter 🛡️.

Reordering packets that belong to different flows may actually be desirable [LUD99b, CHE00] ✨. It helps share the link fairly between established bulk-data transfer sessions and sessions that send less data but would benefit from lower link transit delay 🫧. Preserving ordering within each individual flow is still worthwhile, so you avoid the reordering effects described earlier in section 3.1 💜.

okay so high ARQ persistency is generally considered unsuitable for a lot of apps using UDP 🫶 because reliable delivery isn't always needed there, and it can introduce unacceptable jitter 😭. it may still benefit bulk data transfers under certain link conditions 🔥, so a scheme that sorts packet flows into two or more classes and gives each class a different service is therefore desirable ✨

watching how a flow behaves can tell you which flows are controlled and congestion-sensitive, or uncontrolled and not, so you can treat them differently and keep things fair 💖. however, it can't tell you whether an app intends a flow to be reliable or unreliable, or what the app needs to run its best 🙈

so supporting different link services for different classes of flows requires the link to be able to tell the flows apart from each other 🧚. this generally needs an explicit indication of the class attached to each flow.

some potential schemes for indicating the class of a packet include:

a. Using the Type of Service (ToS) bits in the IP header [RFC791]. the IETF replaced these globally-defined bits, which weren't widely used, with the differentiated services model (diffserv [RFC2475, RFC3260]) 🎀. in diffserv, each packet carries a Differentiated Service Code Point (DSCP), which says which one of a set of diffserv classes the flow belongs to. each router maps the DSCP value of a received IP packet to one of a set of Per Hop Behaviours (PHBs) as the packet moves through the network. diffserv is used for things like policy-based routing, class-based queuing, and support for other QoS metrics, including IP packet priority, delay, reliability, and cost 👑

b. Inspecting the network packet header and looking at the IP protocol type [RFC791] to get an idea of the transport protocol in use, and so guess its needs 🔍. this isn't possible when the payload is encrypted, e.g., using the IP security extensions (IPSec) with Encapsulation Security Payload (ESP) [RFC2406] payload encryption 🙅‍♀️

c. By inspecting the transport packet header information to view the TCP or UDP headers and port numbers (e.g., [PAR00, BAL95]). this isn't possible with payload encryption, e.g., IPSec with ESP payload encryption [RFC2406], and it adds processing overhead for every packet sent over the link 🐢

there are, however, some drawbacks to these schemes 🥲

i. The ToS/Differentiated Services Code Point (DSCP) values [RFC2475] may not be set reliably, and intermediate routers along the packet's path may overwrite them. these values may be set by an ISP, and they don't necessarily reflect the level of reliability the end application needs. the link must be configured with knowledge of what the values mean locally.

ii. Tunnelling of traffic (e.g., GRE, MPLS, L2TP, IP-in-IP encapsulation) can bundle together flows of different transport classes. that makes it harder to classify individual flows with schemes (b) and (c), and adds more header processing if the tunnel contents get inspected 🌀

iii. Using the TCP/UDP port number makes assumptions about application behaviour and requirements. new applications or protocols can break these assumptions, and so can things like Network Address Port Translation, where port numbers get remapped [RFC3022] 🙃

iv. In IPv6, the entire IPv6 header has to be parsed to find the transport layer protocol, which makes header inspection more complicated. once again, this assumes that IPSec payload encryption isn't used 😵‍💫

despite the difficulties in building a framework for accurate flow identification, approach (a) may be beneficial, and it's preferable to adding optimisations that are triggered by inspecting the contents of specific IP packets. some of those optimisations are discussed in detail in [LUD99b] 🧐

flow management is desirable 💅. clear flow identification gives the link designer more tools, and allows more complex ARQ strategies. without flow identification, those strategies might make wrong assumptions about traffic requirements and behaviour 🙈

links that can't clearly and safely tell apart delay-sensitive flows (e.g., real-time multimedia, DNS queries or telnet) from delay-insensitive flows (e.g., bulk ftp transfers or reliable multicast file transfer) can't separate link service classes safely either. so all flows should experience the same link behaviour 🫠

in general, if separating flows by class isn't practicable, a low persistency is best for link ARQ 🌸

4. Conclusions ✨

okay so a number of techniques can be used by link protocol designers to counter the effects of channel errors or loss. one of them is Automatic Repeat ReQuest, ARQ, which has been and still is used on links that carry IP traffic 🔁. an ARQ protocol retransmits link frames that got corrupted during transmission across a channel. link ARQ may significantly improve the probability of successful transmission of IP packets over links that are prone to occasional frame loss 💪

a lower rate of packet loss generally benefits transport protocols and endhost applications 🫶. apps using TCP generally benefit from Internet paths with little or no loss and low round trip path delay 🏃‍♀️. that means less impact on the app, faster growth of TCP's congestion window during slow start, and prompt reactions to end-to-end protocol exchanges (e.g., retransmission, congestion indications) ⚡. apps using other transport protocols, e.g., UDP or SCTP, also benefit from low loss and timely delivery 🦋

a side-effect of link ARQ is that link transit delay goes up when frames get retransmitted ⏳. at low error rates, a lot of the ARQ details, like the degree of persistence or any resulting out-of-order delivery, stop mattering 😌. most frame losses get resolved in one or two retransmission attempts, which is generally unlikely to cause significant impact to e.g., TCP. however, on shared high-delay links, the impact of ARQ on other UDP or TCP flows may lead to unwanted jitter 😬

when error rates are highly variable, high link ARQ persistence may give good performance for a single TCP flow 📈. but interactions between flows can pop up when lots of flows share capacity on the same link 🤯. a link ARQ procedure that provides flow management will be beneficial 👑. lower ARQ persistence may also have merit, and it's preferable for apps using UDP. the reasoning is that the link can still do useful work forwarding some complete packets, and blocking all flows by retransmitting the frames of a single packet with high persistence is undesirable 🙅‍♀️

during a link outage, interactions between ARQ and multiple flows are less significant, because the ARQ protocol is likely to be equally unsuccessful at retransmitting frames for all flows 🌧️. high persistence may benefit TCP flows, by enabling prompt recovery once the channel is restored ☀️

low ARQ persistence is especially useful where it's hard or impossible to classify traffic flows and so treat each flow independently, and where the link capacity can handle a large number of simultaneous flows 🧚

link ARQ designers should think about what their design means for the wider Internet 🌍. effects like increased transit delay, jitter, and re-ordering add up when they happen on multiple links along an Internet path. so it's really hard to say how many ARQ links may exist in series along an arbitrary Internet path between endhosts, especially since the path taken and its links may change over time 🌀

in summary, when links can't classify traffic flows and treat them separately, low persistence is generally desirable, and preserving packet ordering is generally desirable too 💖. extremely high persistence and perfect persistence are generally undesirable. highly-persistent ARQ is a bad idea unless flow classification and detailed, accurate knowledge of flow requirements make it possible to deploy high persistency where it'll actually help 🙈

there's currently insufficient experience to recommend a specific ARQ scheme for any class of link 🤷‍♀️. it's also important to realize that link ARQ is just one method of error recovery, and other complementary physical-layer techniques may be used instead of, or together with, ARQ to improve overall link throughput for IP traffic 🔧

the choice of potential schemes includes adapting the data rate, adapting the signal bandwidth, adapting the transmission power, adaptive modulation, adaptive information redundancy / forward error control, and interleaving 🎛️. all of these can be used to improve the received signal energy per bit, and hence reduce error, frame loss and resulting packet loss rates given specific channel conditions 📉

there's a need for more research to more clearly identify the importance of, and trade-offs between, the above issues over various types of link and various types of channels 🔬. it would be really useful if researchers and implementers clearly indicated the loss model, link capacity and characteristics, link and end-to-end path delays, details of TCP, and the number (and details) of flows sharing a link when they describe their experiences 📝. in each case, it is recommended that specific details of the link characteristics and mechanisms also be considered, because solutions vary with conditions 🌈

5. Security Considerations 🔐

no security implications have been identified as directly impacting IP traffic 👀. however, an unreliable link service may adversely impact some existing link-layer key management distribution protocols if link encryption is also used over the link 😱

denial-of-service attacks that exploit the behaviour of the link protocol are a real concern 🚨. for example, an attacker using knowledge of its retransmission behaviour and propagation delay could cause a particular form of jamming. this may be specific to an individual link scenario, but take it seriously anyway 💀

6. IANA Considerations 🌸

no assignments from the IANA are required 🫶.

7. Acknowledgements 🫶

much of what is described here was developed from a summary of a subset of the discussions on the archived IETF PILC mailing list 💌. we thank the contributors to PILC for their vigorous debate 🔥.

in particular, the authors would like to thank Spencer Dawkins, Aaron Falk, Dan Grossman, Merkourios Karaliopoulos, Gary Kenward, Reiner Ludwig and Jean Tourrilhes for their detailed comments 💜.

8. References 📚

references of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/ 🧚

8.1. Normative References 📚✨

Okay bestie, here are the core docs this one leans on, the foundations of the whole thing 🫶

  • [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981.
  • [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
  • [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
  • [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
  • [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
  • [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.

8.2. Informative References 🦋

Now the extra reading list, the "ooh, go deeper" section 🌈 Here's everything, exactly as it's cited:

  • [BAL95] Balakrishnan, H., Seshan, S. and R. H. Katz, "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks", ACM MOBICOM, Berkeley, 1995.
  • [BAL97] Balakrishnan, H., Padmanabhan, V. N., Seshan, S. and R. H. Katz, "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links", IEEE/ACM Transactions on Networking, 5(6), pp. 756-759, 1997.
  • [BEN00] Bennett, J. C., Partridge, C. and N. Schectman, "Packet Reordering is Not Pathological Network Behaviour", IEEE/ACM Transactions on Networking, 7(6), pp. 789-798, 2000.
  • [BHA97] Bhagwat, P., Bhattacharya, P., Krishna A. and S. K. Tripathi, "Using channel state dependent packet scheduling to improve TCP throughput over wireless LANs", ACM/Baltzer Wireless Networks Journal, (3)1, 1997.
  • [CHE00] Cheng, H. S., G. Fairhurst et al., "An Efficient Partial Retransmission ARQ Strategy with Error Codes by Feedback Channel", IEE Proceedings - Communications, (147)5, pp. 263-268, 2000.
  • [DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork Designers", Work in Progress.
  • [DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work in Progress.
  • [ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless LAN Performance via Adaptive Local Error Control", IEEE ICNP, 1998.
  • [FER99] Ferrero, A., "The Eternal Ethernet", Addison-Wesley, 1999.
  • [ISO4335a] HDLC Procedures: Specification for Consolidation of Elements of Procedures, ISO 4335 and AD/1, International Standardization Organization, 1985.
  • [ISO4335b] HDLC Procedures: Elements of Procedures, Amendment 4: Multi-Selective Reject Option, ISO 4335/4, International Standards Organization, 1991.
  • [ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link Procedures, ISO 4335/4, International Standards Organization, 1985.
  • [KEN87] Kent, C. A. and J. C. Mogul, "Fragmentation Considered Harmful", Proceedings of ACM SIGCOMM 1987, ACM Computer Communications Review, 17(5), pp. 390-401, 1987.
  • [LIN93] Lin, S. and D. Costello, "Error Control Coding: Fundamentals and Applications", Prentice Hall, 1993.
  • [LUD99a] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., and A. Joseph, "Multi-Layer Tracing of TCP over a Reliable Wireless Link", ACM SIGMETRICS, pp. 144-154, 1999.
  • [LUD99b] Ludwig, R., Konrad, A., Joseph, A. and R. H. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", ACM MobiCOM, 1999.
  • [MEY99] Meyer, M., "TCP Performance over GPRS", IEEE Wireless Communications and Networking Conference, 1999.
  • [PAR00] Parsa, C. and J. J. Garcia-Luna-Aceves, "Improving TCP Performance over Wireless Networks at the Link Layer", ACM Mobile Networks and Applications Journal, (5)1, pp. 57-71, 2000.
  • [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
  • [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
  • [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
  • [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
  • [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
  • [RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
  • [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
  • [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott K. and J. Semke "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
  • [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
  • [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
  • [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
  • [SALT81] Saltzer, J. H., Reed, D. P. and D. Clark, "End-to-End Arguments in System Design", Second International Conference on Distributed Computing Systems, pp. 509-512, 1981. Published with minor changes in ACM Transactions in Computer Systems (2)4, pp. 277-288, 1984.
  • [SAM96] Samaraweera, N. and G. Fairhurst, "Robust Data Link Protocols for Connection-less Service over Satellite Links", International Journal of Satellite Communications, 14(5), pp. 427-437, 1996.
  • [SAM98] Samaraweera, N. and G. Fairhurst, "Reinforcement of TCP/IP Error Recovery for Wireless Communications", ACM Computer Communications Review, 28(2), pp. 30-38, 1998.
  • [STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
  • [STONE00] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", Proceedings of SIGCOMM 2000, ACM Computer Communications Review 30(4), pp. 309-321, September 2000.
  • [WARD95] Ward, C., et al., "A Data Link Control Protocol for LEO Satellite Networks Providing a Reliable Datagram Service", IEEE/ACM Transactions on Networking, 3(1), 1995.

Authors' Addresses 💌

Meet the brains behind it, bestie 🧚 Here are their contact details, straight from the original:

Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen AB24 3UE
United Kingdom

EMail: gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk/users/gorry/


Lloyd Wood
Cisco Systems Ltd
4 The Square
Stockley Park
Uxbridge UB11 1BY
United Kingdom

EMail: lwood@cisco.com
http://www.ee.surrey.ac.uk/Personal/L.Wood/

Now the legal bit, which I'm keeping word-for-word so nothing gets lost 🎀

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌸

Last but not least, the funding bit 💖 Funding for the RFC Editor function is currently provided by the Internet Society. Iconic, thank you for sticking with me through all six parts 😭✨

📦 where this page comes from