RFC 2688

Integrated Services Mappings for Low Speed Networks

📅 published September 1999, from ietf

Integrated Services Mappings for Low Speed Networks 🎀

Network Working Group · RFC 2688 · Category: Standards Track · September 1999

Authors: S. Jackowski (Deterministic Networks), D. Putzolu (Intel Architecture Labs), E. Crawley (Argon Networks), B. Davie (Cisco Systems) 💜

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

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

Abstract ✨

okay so there's a whole family of companion documents describing how to get integrated services working over low-bitrate links, like modem lines, ISDN B-channels, and sub-T1 links [1, 2, 3, 4] 🦋. The architecture has a few main pieces: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture tuned for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols that applications use so the negotiation can actually happen 💅.

This document is where the service mappings live for the IETF Integrated Services on low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. It's giving guidelines and considerations for implementing these services, plus evaluation criteria for the elements that provide them 🌸.

1. Introduction 🧚

bestie, the Internet is famous for "best-effort" service, but it's not the only vibe anymore. Other kinds of services ("integrated services") are being developed and deployed too 🌈. They handle traffic specially based on bandwidth, latency, and other requirements that "best-effort" usually can't meet 👑.

This document defines how the integrated services "controlled load" [5] and "guaranteed" [6] services get mapped onto low-bandwidth links 🍓. The architecture and mechanisms for doing that are defined in a set of companion documents. Those mechanisms include compressing flows to save bandwidth [4,10], plus a set of PPP extensions that allow fragmentation [2] or suspension [3] of large packets so that packets from flows with stricter service requirements can go first 🔥.

1.1. Specification Language 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [11] 🫶.

2. Issues for Providing Controlled and Guaranteed Service 💖

Unlike other link layers, the links in this document only run over low speed point to point connections 🐢. Think dial-up lines, ISDN channels, and low-speed (1.5Mbps or less) leased lines. These links can show up in a few different spots along the end-to-end path:

  • host to directly connected host.
  • host to/from network access device (router or switch).
  • Edge device (subnet router or switch) to/from router or switch.
  • In rare circumstances, a link from backbone router to backbone router.

These links are often the first or last wide area hop in a true end to end service, so ngl they can be the most bandwidth constrained part of the path between two hosts 😭.

The services used to map integrated services onto these links only get provided if both endpoints on the link support the architecture and mechanisms referenced above. That support is figured out during the PPP negotiation 🤝. Because these links aren't shared, and point-to-point links are typically dual simplex (meaning the send and receive channels are separate), all admission control decisions can be made locally 💅.

As described in [2] and [3], suspend/resume is the better choice for systems that can control their transmission at a finer grain than whole HDLC frames. It optimizes the available bandwidth by cutting down the header overhead of MLPPP pre-fragmentation, and it can give better delay. The catch is that every outgoing packet has to be prepared, and all incoming data has to be scanned for suspend/resume control information 👀. Fragmentation doesn't need that extra scanning of the data stream (beyond bit/byte-stuffing, which may happen in hardware), and it works for systems that only offer frame-oriented transmission control 🧃. So picking between suspend/resume and fragmentation should depend on the level of transmission control, whether the element can handle the HDLC-like framing described in [2], and the system overhead of byte by byte scanning (which suspend/resume requires) 🎀.

To give controlled load or guaranteed service with the suspend/resume approach: when a packet for an admitted flow (QoS packet) shows up while a best effort packet is being sent, and finishing the best effort packet would break the delay constraints of the QoS flows, the best effort packet gets preempted 😤. The QoS packet (or its fragments) gets slotted into the transmission, and then the best effort packet resumes, usually all in one transmission ✨. The receiving station pulls the best effort packet apart from the embedded QoS fragments. It's also possible that one QoS flow's packet could suspend another flow's packet, if the new packet's delivery deadline is earlier than the current one's 🏃‍♀️.

For systems that use fragmentation, any packet longer than the maximum tolerable delay for enhanced service flows gets fragmented before transmission. That way a short packet from another flow can be interleaved between the fragments of a larger packet and still hit the deadline of the flow that needs enhanced services 🦋.

Heads up: the fragmentation in this document means multilink PPP (MLPPP) fragmentation and the associated MCMLPPP modifications described in [2], not IP or other layer 3 fragmentation 🙅‍♀️. MLPPP fragmentation is local to the PPP link and doesn't affect the end-to-end (IP) MTU 💅.

2.1 Calculating "Acceptable Delay" for Int-serv flows 🧮

A router that provides Controlled Load or Guaranteed Service over a low speed serial link needs some idea of the "acceptable delay" for packets belonging to int-serv flows 🕰️. With fragmentation, the router needs to know what size to fragment packets into. With suspend/resume, it needs to know when it's appropriate to suspend one packet to meet another's delay goals 🎯.

Unfortunately, there's no hard and fast way to determine a single delay bound for a particular flow. The end-points of a flow have enough info to work out acceptable end-to-end delay bounds and to make reservation requests of the network to meet them, but they don't tell routers about a "per-hop" delay 🙈.

For Guaranteed Service [6], one approach is to let the network operator configure parameters on the router that directly affect its delay performance. Guaranteed service lets routers deviate from the ideal fluid flow model, and it advertises the extent of that deviation using two error terms, C and D: the rate-dependent and rate-independent error terms, defined in [6] 📐. A network operator can configure the parameters of the low speed link so that D is set to a value of her choice 👑.

If link-level fragmentation is used, the router controlling a low-speed link can be configured with a certain fragment size. That enables a component of the error term D to be calculated from the time it takes to send one fragment over the link. (D may have other components too, like the speed of light delay over the link.) The details of the D calculation are described below 🧠. Similarly, if suspend/resume is used, the router may be configured with a delay parameter, which lets it decide when it's appropriate to suspend a packet 💜.

For Controlled Load, there are no error terms, so the router has to figure out how best to meet the requirements of the admitted reservations using only the information in their TSpecs 🤔. The Controlled Load definition says a CL flow with Tspec rate r should get treatment similar to an unloaded network of capacity r. So CL packets should not generally experience end-to-end delays significantly greater than b/r + propagation delays 🌊. A router connected to a low speed link should not add a delay greater than b/r from transmitting other fragments. Ideally it adds substantially less than b/r, since other hops on the end-to-end path may add delay too 🫠. This can be tricky for flows with very small values of b 😬.

Implementers will make their own tradeoffs about how low to push the delay for Controlled Load flows 🍭. Similarly, it may not be possible or desirable to set the parameters affecting D to arbitrarily small values, because fragmenting packets into very small sizes has an overhead cost 💸. On the flip side, if D is too large, some applications may find they can't make a reservation that meets their delay objectives 💔.

For the rest of this document, we assume a router has some idea of the acceptable delay it may introduce before it starts transmitting a packet. That delay is in addition to any delay from the "ideal" queuing algorithm the router uses to schedule packets 🗓️.

3. Controlled Load and Guaranteed Service Class Mapping 🌈

Supporting integrated services over PPP links that implement MCML or RTF can be done in several ways. Guidelines for mapping these services onto PPP links, and onto the classes provided by the suspend/resume and fragmentation mechanisms, are presented below 🗺️. Note that these guidelines assume some sort of signaling protocol is used to indicate the desired quality of service to both the sender and receiver of a flow over a PPP link 🫶💅.

3.1 Predefined Class Mappings 🎀

okay so the simplest way to do class mapping is with predefined levels of service 💖 you just sort every admitted flow into one of a few buckets, and each bucket roughly matches the service level its flows want. this is a totally valid option you MAY use. here's an example set of mappings:

MCML Short   MCML Long  RTF     Service

  0b00        0b0000    0b000   Best Effort
  NA          0b0001    0b001   Reserved
  0b01        0b0010    0b010   Delay Sensitive, no bound
  NA          0b0011    0b011   Reserved
  NA          0b0100    0b100   Reserved
  0b10        0b0101    0b101   Delay Sensitive, 500ms bound
  NA          0b0110    0b110   Delay Sensitive, 250ms bound
  0b11        0b0111    0b111   Network Control

Table 1: Example Mappings of Classes to Services 🦋

ngl the table is doing a lot, so here's the tea ☕ MCML has two formats, short sequence numbers and long sequence numbers, and those give you 2 and 4 bits of class identification. RTF gives you 3 bits of class identification in every format. so the short MCML format has fewer slots, which is a big deal for later 👀

using a fixed default-mapping like this has some limits, though 🥺 every flow in the same bucket (the ones assigned to the same class) gets scheduled against the others at the level of packets, not the finer level of fragments. that can make admission control overly conservative when there are only a few classes to work with, like in the MCML short sequence number format. not ideal, babe 😭

3.2 Predefined Class Mappings and Prefix Elision ✨

if there are fewer reservations than the total number of classes negotiated for a PPP link, you can give individual flows their own fixed class numbers 🧚 this is handy when the protocol identifier of one or more flows is known at LCP negotiation time and the link bandwidth is pretty small. when those conditions hold, the known flows can optionally get a specific class, and the prefix elision PPP option [2] can be used for those classes to save a little bandwidth 💅

3.3 Dynamic Class Mappings 🌈

okay this one is my favourite bit 😭 when predefined mappings aren't cutting it, an implementer MAY map class values to individual packets instead of pinning flows to fixed classes. why is that allowed? because the classes MCML and RTF give you are basically just PPP-specific segmentation and fragmentation tools. so while the class number MUST stay constant across all the fragments of one packet, it MAY change from packet to packet for every flow crossing the PPP link. you don't have to assign flows to fixed classes at all, because the class numbers are NOT REQUIRED to mean anything beyond tracking which fragments belong to the same packet. this point is so important that here's an example 💜

Consider a PPP link using the MCML short sequence number fragment format (that is, four classes are provided). Assume that in addition to carrying best effort traffic, this link is carrying five guaranteed service flows, A, B, C, D, and E. Further assume that the link capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic is sufficient to keep the pipe full at all times and that GS flows A-E are each 10kbit/s and all have delay bounds of 145ms.

Time(ms)        Action
 0     BE traffic is queued up
 0     2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...)
 8     2kbit fragment from BE sent, cls 0 (10kbit BE packet done)
 9     8kbit packet from flow A arrives
10     2kbit fragment from A sent, cls 1 (8kbit flow A packet start)
11     8kbit packet from flow B arrives
12     2kbit fragment from B sent, cls 2 (8kbit flow B packet start)
13     8kbit packets from flows C, D, and E arrive
14     2kbit fragment from C sent, cls 3 (8kbit flow C packet start)
16     2kbit fragment from D sent, cls 0 (8kbit flow D packet start)
18     2kbit fragment from A sent, cls 1
20     2kbit fragment from B sent, cls 2
22     2kbit fragment from A sent, cls 1
24     2kbit fragment from A sent, cls 1 (8kbit flow A packet done)
26     2kbit fragment from E sent, cls 1 (8kbit flow E packet start)
27     8kbit packet from flow A arrives
28     2kbit fragment from B sent, cls 2
30     2kbit fragment from C sent, cls 3
32     2kbit fragment from E sent, cls 1
34     2kbit fragment from B sent, cls 2 (8kbit flow B packet done)
36     2kbit fragment from E sent, cls 1
38     2kbit fragment flow A sent, cls 2 (8kbit flow A packet start)
       (etc.)

so what does this show? first, multiple flows MAY share the same class, especially when there are more flows than classes 🙌 more importantly, a flow doesn't have to stick to one fixed class. the only real rule is that each packet, once fragmented, MUST have the same class value on all of its fragments. beyond that, the link scheduler may assign individual packets to changing class numbers whenever it's needed to meet reservation requirements ✨

one tip for implementers of integrated services on MCML and RTF links using dynamic mappings: all BE traffic SHOULD be logically separated from QoS traffic, and mapped to a fragmentable class (MCML classes 0-3 in short sequence number fragment format, 0-15 in long sequence number fragment format) or a suspendable class (RTF classes 0-6). BE traffic usually doesn't get sent unless the link is empty (no CL or GS traffic is ready to go), so implementers MAY choose to use class number 0 for BE traffic 🍓

3.4 Non-Conformant Traffic 💀

how non-conformant QoS traffic gets treated is mostly decided by the appropriate service specifications, but this draft leaves some wiggle room for the details 🫶 policing of flows with non-conformant traffic SHOULD always happen at the level of individual packets, not a finer level. so if a network element scheduling flows needs to drop non-conformant traffic, it SHOULD drop entire packets rather than individual fragments of those packets. and if a network element forwards non-conformant traffic when link bandwidth is free instead of dropping it, the implementation SHOULD fragment that traffic as if it were best effort traffic.

whether BE and non-conformant traffic get treated differently when transmitted (like BE getting priority access to the link over non-conformant traffic), or whether special treatment is given to individual flows within each type (like WFQ or RED), depends on the service 🌸

4. Guidelines for Implementers ✨

4.1. PPP Bit and Byte Stuffing Effects on Admission Control 💅

the big thing to remember for admission control on PPP links is that bit stuffing lowers the effective link rate 😤 typical bit stuffing algorithms can add as much as 20% extra overhead. so admission control for guaranteed service over links that use bit stuffing SHOULD take the RSpec rate of all flows and multiply it by 1.2 (that's the 20% bit stuffing overhead) when deciding whether a new flow can get in. admission control for controlled load reservations may use a similar algorithm based on the TSpec peak rate, or may try to measure how much expansion is actually happening on the link because of bit stuffing. that measurement can then adjust the calculated remaining link capacity. but be careful with it, because the amount of bit stuffing can change a lot, both between flows and within a single flow 🙈

byte stuffing shows up on lots of PPP links too, most often on POTS modems using the v.42 protocol. it's a seriously tricky problem for admission control, especially for guaranteed service, because it's so variable 😭 in the worst case, byte stuffing can double frame sizes. so a strict implementation of admission control for guaranteed load on byte stuffed PPP links SHOULD double the RSpec of link traffic when making flow admission decisions. same as with bit stuffing, controlled load service admission control algorithms for links with byte stuffing MAY attempt to determine average packet expansion by observation, or MAY use the theoretical worst case values 🔥

4.2. Compression Considerations 🧚

the architecture for integrated services over low bandwidth links uses several PPP options to negotiate the link configuration, as described in [4, 8, 10]. when deciding whether to admit a flow, admission control MUST compute the impact of the following on MTU size, rate, and fragment size:

  • Header compression: Van Jacobson or Casner-Jacobson [4,8,10].
  • Prefix Elision.
  • CCP.
  • Fragment header option used.
  • Fragmentation versus suspend/resume approach.

if any of the compression options are implemented for the connection, the actual transmission rate, and therefore the bandwidth the link needs, goes down because of the compression method(s) used 🦋

prefix elision can team up with mapping flows to MLPPP classes to skip prefixes that can't be compressed at higher layers 💜 once both ends agree across the link, the sender can elide a prefix for a certain class of traffic, and when packets arrive in that class, the receiver can restore the prefix.

both compression gain and elision gain MUST be included, as described in the admission control section below. also, the ability to do compression at higher layers (like TCP or RTP/UDP) may depend on the sender providing a hint, as described in [9] 🌈

4.3. Admission Control ✨

okay so admission control is the bouncer of the whole network 💅 and it MUST decide whether to let a flow in based on rate AND delay 🚪✨ here's the cast of characters you need to know:

  • LinkRate is the rate of the link.
  • MTU is the maximum transmission unit from a protocol.
  • MRU is the maximum receive unit for a particular link.
  • CMTU is the maximum size of the MTU after compression is applied.
  • eMTU is the effective size at the link layer of an MTU-sized packet after link layer fragmentation and addition of the fragment headers.
  • FRAG is the fragment size including MLPPP header/trailers.
  • Header is the size of the header/trailers/framing for MLPPP/Fragments.
  • pHeader is the additional header/framing overhead associated with suspend/resume. This should include FSE and worst case stuffing overhead.
  • pDelay is the time taken to suspend a packet already "in flight", e.g. due to the delay to empty the output FIFO.
  • b is the bucket depth in bytes.
  • R is the requested Rate.
  • Dlink is the fixed overhead delay for the link (Modem, DSU, speed-of-light, etc).
  • eRate is the effective rate after compression and fragmentation.

The Dlink term MAY be configured by an administrative tool once the network is installed 🛠️ it may be determined by real-time measurement means 📏 or it MAY be available from hardware during link setup and/or PPP negotiation 🔌 for more tea on PPP link characteristics and delays, go check out Appendix A 🍵

Admission control MUST compute CMTU, eMTU, and eRate for Controlled Load Service, and it MUST compute CMTU, eMTU, eRate, and D for Guaranteed Service 🎀

To figure out whether the requested rate is actually available, Admission Control MUST compute the effective rate of the request (eRate) in the worst case, like this:

#_of_Fragments = CMTU div (FRAG-Header) [Integer divide]
Last_Frag_Size = CMTU mod (FRAG-Header

If Last_Frag_Size != 0
   eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header
Else
   eMTU = (#_of_Fragments) * FRAG

eRate = eMTU/CMTU * R [floating point divide]

Admission control SHOULD compare the eRate of the request against the remaining bandwidth available 🧮 that tells you if the requested rate can be delivered 💖

For Controlled Load Service, a flow can get in as long as there is enough bandwidth left (after the math above) to meet the rate requirement, AND there is enough buffer space (the sum of the token bucket sizes does not exceed the buffer capacity) 🪣✨ now, some statistical multiplexing could be done when judging admissibility, BUT ngl the nature of low-bitrate links makes that risky 😬 any delay caused by fixing a temporary overcommitment could be really hard to make up for later 💀

4.4 Error Term Calculations 🧮

okay, Guaranteed Service needs the calculation of the C and D error terms 🎯 C is a rate-dependent error term, and there are no special considerations that change how it's calculated in the low-speed link environment 🙌 the D term is built from the inherent link delay (Dlink) PLUS the potential worst case delay from transmitting another fragment or from suspend/resume overhead 🧠 so D should be calculated as:

D = Dlink + FRAG/LinkRate

if you're in a fragmenting implementation, and:

D = Dlink + pHeader + pDelay

if you're in a suspend/resume implementation 💜

4.5 Scheduling Considerations 📅

the vibe here is that we can think of the link scheduler as having two parts 🧩 the first part schedules packets for transmission before passing them to the second part, which is the link level scheduler 👑 the link level scheduler is the one responsible for fragmenting packets, mapping them to classes, and scheduling among the classes 🫶

in the dynamic class mapping mode of Section 3.3, when deciding which class to assign a packet to, the link level scheduler should take account of the sizes of other packets currently assigned to that same class 👀 the big rule is that packets with the tightest delay constraints should not be assigned to classes where relatively large packets are in the middle of being transmitted 🙈 nobody wants their tiny urgent packet stuck behind a chonky one 🐘

in either the dynamic or the static class mapping approach, the link-level scheduler SHOULD control how much link bandwidth is assigned to each class at any instant ⏱️ the scheduler should assign bandwidth to a class according to the bandwidth reserved for the sum of all flows that currently have packets assigned to that class 📦 and check this example from Section 3.3: when packets from flows A and E were assigned to the same class (class 1), the scheduler gave class 1 more bandwidth, because it was carrying traffic from reservations totaling 20kbit/s while the other classes were only carrying 10kbit/s 📊 that's giving fairness with receipts 🧾✨

5. Security Considerations 🔐

okay this section is SERIOUS bestie, so read it carefully 🚨 general security considerations for MLPPP and PPP links are covered in RFC 1990 [12] and RFC 1661 [13], respectively 🛡️ security considerations relevant to RSVP (the signaling protocol used for integrated services) are discussed in RFC 2209 [14] 📜

a specific security consideration for providing quality of service over PPP links shows up when you rely on either observed or theoretical average packet expansion during admission control because of bit- or byte-stuffing 😱 implementations based on these packet-expansion values have a potential vulnerability to denial of service attacks 💀 an adversary could intentionally send traffic that results in worst case bit- or byte-stuffing packet expansion 👿 and that could mean quality of service guarantees aren't met for other flows, because admission control got too permissive 🥀 this potential denial of service attack argues STRONGLY for using a worst case expansion factor in admission control calculations, EVEN for controlled load service 🚩

⚠️ bestie, the worst case expansion factor is not optional vibes. Use it, even for controlled load service.

beyond the considerations documented above, this document introduces no new security issues on top of those discussed in the companion ISSLL documents [1], [2] and [3] and AVT document [4] 📚 any use of these service mappings assumes that all requests for service are authenticated appropriately 🔑

6. References 📖

[1] Bormann, C., "Providing Integrated Services over Low-bitrate Links", RFC 2689, September 1999.

[2] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.

[3] Bormann, C., "PPP in a Real-time Oriented HDLC-like Framing", RFC 2687, September 1999.

[4] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.

[5] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.

[6] Partridge, C. and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[7] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997.

[8] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links", RFC 1144, February 1990.

[9] B. Davie et al. "Integrated Services in the Presence of Compressible Flows", Work in Progress (draft-davie-intserv-compress-00.txt), Feb. 1999.

[10] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.

[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradettim, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[13] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[14] Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.

7. Authors' Addresses 🎀

meet the squad 🫶

Steve Jackowski
Deterministic Networks, Inc.
245M Mt Hermon Rd, #140
Scotts Valley, CA  95060
USA

Phone: +1 (408) 813 6294
EMail: stevej@DeterministicNetworks.com
David Putzolu
Intel Architecture Labs (IAL)
JF3-206-H10
2111 NE 25th Avenue
Hillsboro, OR 97124-5961
USA

Phone: +1 (503) 264 4510
EMail: David.Putzolu@intel.com
Eric S. Crawley
Argon Networks, Inc.
25 Porter Road
Littleton, MA 01460
USA

Phone: +1 (978) 486-0665
EMail: esc@argon.com
Bruce Davie
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
USA

Phone: +1 (978) 244 8921
EMail: bdavie@cisco.com

Acknowledgements 🫶

this document draws heavily on the work of the ISSLL WG of the IETF 🌈 literally iconic work, shoutout to them 👑

Appendix A. Admission Control Considerations for POTS Modems 📞

okay so POTS modems are kind of unpredictable, and the protocols they use can show big changes in link rate and delay over the course of a connection 🙃 admission control and link scheduling algorithms used with these devices MUST be prepared to compensate for this variability, so you can build a robust implementation of integrated services 💪

the link rate on POTS modems is typically reported at connection time 📟 but that value can change over the duration of the connection 🔄 the v.34 protocol, which most POTS modems use, is adaptive to link conditions and can recalibrate its transmission rate multiple times over a call ⚡ typically this gives a small (~10%) increase in transmission rate over the initial connection within the first minute of a call 📈 BUT, it's important to note that other results are possible too, including decreases in available bandwidth 📉 admission control algorithms MUST take such changes into consideration as they occur, and implementations MUST be able to gracefully handle the pathological case where the link rate actually drops below the currently reserved capacity of a link 😭

delay on POTS modems can vary a LOT over time 🌀 unlike link rate, the delay often doesn't converge to a stable value 🙅 the v.42 protocol is used in most POTS modems to provide link-layer reliability 🔁 this reliability is implemented via retransmission, and retransmissions can cause frames to experience significant delays 🐢 retransmissions also implicitly steal link bandwidth from other traffic 🥷 these delays and reductions in link bandwidth make it extremely difficult to honor a guaranteed service reservation 💔 on a link that's actually lightly or moderately loaded, a controlled load service can, to some extent, accept such events as part of the behavior of a lightly loaded link 🍃 unfortunately, as actual link utilization increases, v.42 retransmissions have the potential to steal larger and larger fractions of available link bandwidth 📉 which makes even controlled load service difficult to offer at high link utilization when retransmissions occur 😩

Copyright (C) The Internet Society (1999). All Rights Reserved. 💖

okay so this is the legal bit, but it's actually pretty chill 🧚 Anyone can copy and share this document, and the translations too. You can also write derivative works that comment on or explain it, or help people actually implement it. You can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🎀 The one catch is that the copyright notice and this paragraph have to stay on every copy and derivative work. ✨

BUT (and this part is so important bestie) the document itself may not be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. 🙈 The only exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's translated into languages other than English 🌈

The permissions I just described are perpetual. They will not be revoked by the Internet Society or its successors or assigns. Forever and ever 💜🦋

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. 💀

Translation: it's given to you as-is, and the ISOC and the IETF are not promising anything beyond that. Not that it won't infringe on anyone's rights, and not any implied warranties of merchantability or fitness for a particular purpose. Read the fine print, babe 😭

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from