From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2598.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc2598.txt (limited to 'doc/rfc/rfc2598.txt') diff --git a/doc/rfc/rfc2598.txt b/doc/rfc/rfc2598.txt new file mode 100644 index 0000000..d3d8d7f --- /dev/null +++ b/doc/rfc/rfc2598.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group V. Jacobson +Request for Comments: 2598 K. Nichols +Category: Standards Track Cisco Systems + K. Poduri + Bay Networks + June 1999 + + + An Expedited Forwarding PHB + +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 Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + The definition of PHBs (per-hop forwarding behaviors) is a critical + part of the work of the Diffserv Working Group. This document + describes a PHB called Expedited Forwarding. We show the generality + of this PHB by noting that it can be produced by more than one + mechanism and give an example of its use to produce at least one + service, a Virtual Leased Line. A recommended codepoint for this PHB + is given. + + A pdf version of this document is available at + ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf + +1. Introduction + + Network nodes that implement the differentiated services enhancements + to IP use a codepoint in the IP header to select a per-hop behavior + (PHB) as the specific forwarding treatment for that packet [RFC2474, + RFC2475]. This memo describes a particular PHB called expedited + forwarding (EF). The EF PHB can be used to build a low loss, low + latency, low jitter, assured bandwidth, end-to-end service through DS + domains. Such a service appears to the endpoints like a point-to- + point connection or a "virtual leased line". This service has also + been described as Premium service [2BIT]. + + + + + +Jacobson, et al. Standards Track [Page 1] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + + Loss, latency and jitter are all due to the queues traffic + experiences while transiting the network. Therefore providing low + loss, latency and jitter for some traffic aggregate means ensuring + that the aggregate sees no (or very small) queues. Queues arise when + (short-term) traffic arrival rate exceeds departure rate at some + node. Thus a service that ensures no queues for some aggregate is + equivalent to bounding rates such that, at every transit node, the + aggregate's maximum arrival rate is less than that aggregate's + minimum departure rate. + + Creating such a service has two parts: + + 1) Configuring nodes so that the aggregate has a well-defined + minimum departure rate. ("Well-defined" means independent of + the dynamic state of the node. In particular, independent of + the intensity of other traffic at the node.) + + 2) Conditioning the aggregate (via policing and shaping) so that + its arrival rate at any node is always less than that node's + configured minimum departure rate. + + The EF PHB provides the first part of the service. The network + boundary traffic conditioners described in [RFC2475] provide the + second part. + + The EF PHB is not a mandatory part of the Differentiated Services + architecture, i.e., a node is not required to implement the EF PHB in + order to be considered DS-compliant. However, when a DS-compliant + node claims to implement the EF PHB, the implementation must conform + to the specification given in this document. + + The next sections describe the EF PHB in detail and give examples of + how it might be implemented. The keywords "MUST", "MUST NOT", + "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this + document are to be interpreted as described in [Bradner97]. + +2. Description of EF per-hop behavior + + The EF PHB is defined as a forwarding treatment for a particular + diffserv aggregate where the departure rate of the aggregate's + packets from any diffserv node must equal or exceed a configurable + rate. The EF traffic SHOULD receive this rate independent of the + intensity of any other traffic attempting to transit the node. It + SHOULD average at least the configured rate when measured over any + time interval equal to or longer than the time it takes to send an + output link MTU sized packet at the configured rate. (Behavior at + time scales shorter than a packet time at the configured rate is + + + + +Jacobson, et al. Standards Track [Page 2] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + + deliberately not specified.) The configured minimum rate MUST be + settable by a network administrator (using whatever mechanism the + node supports for non-volatile configuration). + + If the EF PHB is implemented by a mechanism that allows unlimited + preemption of other traffic (e.g., a priority queue), the + implementation MUST include some means to limit the damage EF traffic + could inflict on other traffic (e.g., a token bucket rate limiter). + Traffic that exceeds this limit MUST be discarded. This maximum EF + rate, and burst size if appropriate, MUST be settable by a network + administrator (using whatever mechanism the node supports for non- + volatile configuration). The minimum and maximum rates may be the + same and configured by a single parameter. + + The Appendix describes how this PHB can be used to construct end-to- + end services. + +2.2 Example Mechanisms to Implement the EF PHB + + Several types of queue scheduling mechanisms may be employed to + deliver the forwarding behavior described in section 2.1 and thus + implement the EF PHB. A simple priority queue will give the + appropriate behavior as long as there is no higher priority queue + that could preempt the EF for more than a packet time at the + configured rate. (This could be accomplished by having a rate + policer such as a token bucket associated with each priority queue to + bound how much the queue can starve other traffic.) + + It's also possible to use a single queue in a group of queues + serviced by a weighted round robin scheduler where the share of the + output bandwidth assigned to the EF queue is equal to the configured + rate. This could be implemented, for example, using one PHB of a + Class Selector Compliant set of PHBs [RFC2474]. + + Another possible implementation is a CBQ [CBQ] scheduler that gives + the EF queue priority up to the configured rate. + + All of these mechanisms have the basic properties required for the EF + PHB though different choices result in different ancillary behavior + such as jitter seen by individual microflows. See Appendix A.3 for + simulations that quantify some of these differences. + +2.3 Recommended codepoint for this PHB + + Codepoint 101110 is recommended for the EF PHB. + + + + + + +Jacobson, et al. Standards Track [Page 3] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + +2.4 Mutability + + Packets marked for EF PHB MAY be remarked at a DS domain boundary + only to other codepoints that satisfy the EF PHB. Packets marked for + EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS + domain. + +2.5 Tunneling + + When EF packets are tunneled, the tunneling packets must be marked as + EF. + +2.6 Interaction with other PHBs + + Other PHBs and PHB groups may be deployed in the same DS node or + domain with the EF PHB as long as the requirement of section 2.1 is + met. + +3. Security Considerations + + To protect itself against denial of service attacks, the edge of a DS + domain MUST strictly police all EF marked packets to a rate + negotiated with the adjacent upstream domain. (This rate must be <= + the EF PHB configured rate.) Packets in excess of the negotiated + rate MUST be dropped. If two adjacent domains have not negotiated an + EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all + EF marked packets). + + Since the end-to-end premium service constructed from the EF PHB + requires that the upstream domain police and shape EF marked traffic + to meet the rate negotiated with the downstream domain, the + downstream domain's policer should never have to drop packets. Thus + these drops SHOULD be noted (e.g., via SNMP traps) as possible + security violations or serious misconfiguration. Similarly, since the + aggregate EF traffic rate is constrained at every interior node, the + EF queue should never overflow so if it does the drops SHOULD be + noted as possible attacks or serious misconfiguration. + +4. IANA Considerations + + This document allocates one codepoint, 101110, in Pool 1 of the code + space defined by [RFC2474]. + + + + + + + + + +Jacobson, et al. Standards Track [Page 4] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + +5. References + + [Bradner97] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475, December 1998. + + [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit + Differentiated Services Architecture for the Internet", + Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf + + [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource + Management Models for Packet Networks", IEEE/ACM + Transactions on Networking, Vol. 3 no. 4, pp. 365-386, + August 1995. + + [RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of + Increased Initial TCP Window Size", RFC 2415, September + 1998. + + [LCN] K. Nichols, "Improving Network Simulation with Feedback", + Proceedings of LCN '98, October 1998. + + + + + + + + + + + + + + + + + + + + + + +Jacobson, et al. Standards Track [Page 5] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + +6. Authors' Addresses + + Van Jacobson + Cisco Systems, Inc + 170 W. Tasman Drive + San Jose, CA 95134-1706 + + EMail: van@cisco.com + + + Kathleen Nichols + Cisco Systems, Inc + 170 W. Tasman Drive + San Jose, CA 95134-1706 + + EMail: kmn@cisco.com + + + Kedarnath Poduri + Bay Networks, Inc. + 4401 Great America Parkway + Santa Clara, CA 95052-8185 + + EMail: kpoduri@baynetworks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jacobson, et al. Standards Track [Page 6] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + +Appendix A: Example use of and experiences with the EF PHB + +A.1 Virtual Leased Line Service + + A VLL Service, also known as Premium service [2BIT], is quantified by + a peak bandwidth. + +A.2 Experiences with its use in ESNET + + A prototype of the VLL service has been deployed on DOE's ESNet + backbone. This uses weighted-round-robin queuing features of Cisco + 75xx series routers to implement the EF PHB. The early tests have + been very successful and work is in progress to make the service + available on a routine production basis (see + ftp://ftp.ee.lbl.gov/talks/vj-doeqos.pdf and + ftp://ftp.ee.lbl.gov/talks/vj-i2qos-may98.pdf for details). + +A.3 Simulation Results + +A.3.1 Jitter variation + + In section 2.2, we pointed out that a number of mechanisms might be + used to implement the EF PHB. The simplest of these is a priority + queue (PQ) where the arrival rate of the queue is strictly less than + its service rate. As jitter comes from the queuing delay along the + path, a feature of this implementation is that EF-marked microflows + will see very little jitter at their subscribed rate since packets + spend little time in queues. The EF PHB does not have an explicit + jitter requirement but it is clear from the definition that the + expected jitter in a packet stream that uses a service based on the + EF PHB will be less with PQ than with best-effort delivery. We used + simulation to explore how weighted round-robin (WRR) compares to PQ + in jitter. We chose these two since they"re the best and worst cases, + respectively, for jitter and we wanted to supply rough guidelines for + EF implementers choosing to use WRR or similar mechanisms. + + Our simulation model is implemented in a modified ns-2 described in + [RFC2415] and [LCN]. We used the CBQ modules included with ns-2 as a + basis to implement priority queuing and WRR. Our topology has six + hops with decreasing bandwidth in the direction of a single 1.5 Mbps + bottleneck link (see figure 6). Sources produce EF-marked packets at + an average bit rate equal to their subscribed packet rate. Packets + are produced with a variation of +-10% from the interpacket spacing + at the subscribed packet rate. The individual source rates were + picked aggregate to 30% of the bottleneck link or 450 Kbps. A mixture + of FTPs and HTTPs is then used to fill the link. Individual EF packet + sources produce either all 160 byte packets or all 1500 byte packets. + + + + +Jacobson, et al. Standards Track [Page 7] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + + Though we present the statistics of flows with one size of packet, + all of the experiments used a mixture of short and long packet EF + sources so the EF queues had a mix of both packet lengths. + + We defined jitter as the absolute value of the difference between the + arrival times of two adjacent packets minus their departure times, + |(aj-dj) - (ai-di)|. For the target flow of each experiment, we + record the median and 90th percentile values of jitter (expressed as + % of the subscribed EF rate) in a table. The pdf version of this + document contains graphs of the jitter percentiles. + + Our experiments compared the jitter of WRR and PQ implementations of + the EF PHB. We assessed the effect of different choices of WRR queue + weight and number of queues on jitter. For WRR, we define the + service-to-arrival rate ratio as the service rate of the EF queue (or + the queue"s minimum share of the output link) times the output link + bandwidth divided by the peak arrival rate of EF-marked packets at + the queue. Results will not be stable if the WRR weight is chosen to + exactly balance arrival and departure rates thus we used a minimum + service-to-arrival ratio of 1.03. In our simulations this means that + the EF queue gets at least 31% of the output links. In WRR + simulations we kept the link full with other traffic as described + above, splitting the non-EF-marked traffic among the non-EF queues. + (It should be clear from the experiment description that we are + attempting to induce worst-case jitter and do not expect these + settings or traffic to represent a "normal" operating point.) + + Our first set of experiments uses the minimal service-to-arrival + ratio of 1.06 and we vary the number of individual microflows + composing the EF aggregate from 2 to 36. We compare these to a PQ + implementation with 24 flows. First, we examine a microflow at a + subscribed rate of 56 Kbps sending 1500 byte packets, then one at the + same rate but sending 160 byte packets. Table 1 shows the 50th and + 90th percentile jitter in percent of a packet time at the subscribed + rate. Figure 1 plots the 1500 byte flows and figure 2 the 160 byte + flows. Note that a packet-time for a 1500 byte packet at 56 Kbps is + 214 ms, for a 160 byte packet 23 ms. The jitter for the large packets + rarely exceeds half a subscribed rate packet-time, though most + jitters for the small packets are at least one subscribed rate + packet-time. Keep in mind that the EF aggregate is a mixture of small + and large packets in all cases so short packets can wait for long + packets in the EF queue. PQ gives a very low jitter. + + Table 1: Variation in jitter with number of EF flows: Service/arrival + ratio of 1.06 and subscription rate of 56 Kbps (all values given as % + of subscribed rate) + + + + + +Jacobson, et al. Standards Track [Page 8] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + + 1500 byte pack. 160 byte packet + # EF flows 50th % 90th % 50th % 90th % + PQ (24) 1 5 17 43 + 2 11 47 96 513 + 4 12 35 100 278 + 8 10 25 96 126 + 24 18 47 96 143 + + Next we look at the effects of increasing the service-to-arrival + ratio. This means that EF packets should remain enqueued for less + time though the bandwidth available to the other queues remains the + same. In this set of experiments the number of flows in the EF + aggregate was fixed at eight and the total number of queues at five + (four non-EF queues). Table 2 shows the results for 1500 and 160 byte + flows. Figures 3 plots the 1500 byte results and figure 4 the 160 + byte results. Performance gains leveled off at service-to-arrival + ratios of 1.5. Note that the higher service-to-arrival ratios do not + give the same performance as PQ, but now 90% of packets experience + less than a subscribed packet-time of jitter even for the small + packets. + + Table 2: Variation in Jitter of EF flows: service/arrival ratio + varies, 8 flow aggregate, 56 Kbps subscribed rate + + WRR 1500 byte pack. 160 byte packet + Ser/Arr 50th % 90th % 50th % 90th % + PQ 1 3 17 43 + 1.03 14 27 100 178 + 1.30 7 21 65 113 + 1.50 5 13 57 104 + 1.70 5 13 57 100 + 2.00 5 13 57 104 + 3.00 5 13 57 100 + + Increasing the number of queues at the output interfaces can lead to + more variability in the service time for EF packets so we carried out + an experiment varying the number of queues at each output port. We + fixed the number of flows in the aggregate to eight and used the + minimal 1.03 service-to-arrival ratio. Results are shown in figure 5 + and table 3. Figure 5 includes PQ with 8 flows as a baseline. + + + + + + + + + + + +Jacobson, et al. Standards Track [Page 9] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + + Table 3: Variation in Jitter with Number of Queues at Output + Interface: Service-to-arrival ratio is 1.03, 8 flow aggregate + + # EF 1500 byte packet + flows 50th % 90th % + PQ (8) 1 3 + 2 7 21 + 4 7 21 + 6 8 22 + 8 10 23 + + It appears that most jitter for WRR is low and can be reduced by a + proper choice of the EF queue's WRR share of the output link with + respect to its subscribed rate. As noted, WRR is a worst case while + PQ is the best case. Other possibilities include WFQ or CBQ with a + fixed rate limit for the EF queue but giving it priority over other + queues. We expect the latter to have performance nearly identical + with PQ though future simulations are needed to verify this. We have + not yet systematically explored effects of hop count, EF allocations + other than 30% of the link bandwidth, or more complex topologies. The + information in this section is not part of the EF PHB definition but + provided simply as background to guide implementers. + +A.3.2 VLL service + + We used simulation to see how well a VLL service built from the EF + PHB behaved, that is, does it look like a `leased line' at the + subscribed rate. In the simulations of the last section, none of the + EF packets were dropped in the network and the target rate was always + achieved for those CBR sources. However, we wanted to see if VLL + really looks like a `wire' to a TCP using it. So we simulated long- + lived FTPs using a VLL service. Table 4 gives the percentage of each + link allocated to EF traffic (bandwidths are lower on the links with + fewer EF microflows), the subscribed VLL rate, the average rate for + the same type of sender-receiver pair connected by a full duplex + dedicated link at the subscribed rate and the average of the VLL + flows for each simulation (all sender-receiver pairs had the same + value). Losses only occur when the input shaping buffer overflows but + not in the network. The target rate is not achieved due to the + well-known TCP behavior. + + Table 4: Performance of FTPs using a VLL service + + % link Average delivered rate (Kbps) + to EF Subscribed Dedicated VLL + 20 100 90 90 + 40 150 143 143 + 60 225 213 215 + + + +Jacobson, et al. Standards Track [Page 10] + +RFC 2598 An Expedited Forwarding PHB June 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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 + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Jacobson, et al. Standards Track [Page 11] + -- cgit v1.2.3