idnits 2.17.1 draft-ietf-issll-isslow-svcmap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-issl-isslow-svcmap-03', but the file name used is 'draft-ietf-issll-isslow-svcmap-03' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 6) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 61 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 129 has weird spacing: '...w), the admis...' == Line 133 has weird spacing: '... leased line....' == Line 403 has weird spacing: '...lues to apply...' == Line 618 has weird spacing: '...equires delay...' == Line 691 has weird spacing: '...hen for overl...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Nov 1998) is 9294 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 2216 (ref. '3') Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT S. Jackowski 3 draft-ietf-issl-isslow-svcmap-03.txt Deterministic Networks 5 D. Putzolu 6 Intel Architecture Labs 8 Nov 1998 9 Expires: 5/99 11 Network Element Service Specification for Low Speed Networks 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 This draft is a product of the Integrated Services Working Group of 32 the Internet Engineering Task Force. Comments are solicited and 33 should be addressed to the working group's mailing list at int- 34 serv@isi.edu and/or the author(s). 36 Abstract 38 This document defines the service mappings for controlled load and 39 guaranteed services over low-bitrate networks. These low-bitrate 40 networks typically include components such as analog phone lines, ISDN 41 connections and sub-T1 rate links. The document specifies the per- 42 network element packet handling behavior, parameters required, traffic 43 specification, policing requirements, and traffic ordering 44 relationships which are required to provide both Guaranteed and 45 Controlled Load service capabilities. It also includes evaluation 46 criteria for elements providing the service. 48 This document is a product of the IETF ISSL working group and is based 49 on [1] and [2] which describe modifications to the PPP protocol to 50 enable these services. 52 Table of Contents 54 1. Introduction 3 55 2. End to end Behavior 4 56 3. Motivation 5 57 4. Network Element Data Handling 5 58 4.01 Rate and delay 6 59 4.02 Link Aggregation 6 60 4.1 Controlled Load Versus Guaranteed Service 7 61 4.2 Controlled Load and Guaranteed Service Data Handling 7 62 4.3 Controlled Load and Guaranteed Service Class Mapping 8 63 5. Invocation Information 11 64 6. Exported Information 11 65 7. Policing 12 66 8. Ordering and Merging 12 67 9. Guidelines for Implementors 12 68 9.1 Bit and Byte Stuffing Considerations 12 69 9.2 Compression Considerations 13 70 9.3 Admission Control 14 71 9.4 Fragment Scheduling Considerations 15 72 10. Evaluation Criteria 16 73 11. Security Considerations 17 74 12. References 17 75 13. Authors' Addresses 17 76 Appendix A - Additional Admission Control Issues for PPP Links 18 77 1. Introduction 79 With the proliferation of Internet usage in both businesses and homes, 80 there has been an explosion in demand for non-LAN access to the 81 Internet. Most of these connections occur over dial up links. There 82 has also been a recent surge in the usage of ISDN and other sub- 83 T1 rate connections. Unfortunately, the nature of these 'low-bitrate' 84 links is that it is difficult to provide Quality of Service (QoS) when 85 there are multiple flows of data over the link. For example, it is 86 virtually impossible for a user to receive consistent performance when 87 running a browser, a file transfer and an IP telephony application 88 simultaneously over a low speed link. 90 The ISSLOW subgroup of the ISSL working group has focused on defining 91 mechanisms to permit flow differentiation and QoS capabilities for mixed 92 traffic over low speed links. This has been accomplished through a 93 series of extensions to the PPP protocol which permit fragmentation 94 and/or suspension of large packets in favor of packets on flows which 95 require QoS. These protocol extensions are presented in [1] and [2]. 97 This document describes the service mapping required to implement the 98 controlled load and guaranteed services over these PPP protocol 99 extensions. It is modeled on the Network Element Service Specification 100 Template described in [3]. It is assumed that the ISSLOW Network 101 Element is one portion of a PPP service available to the system. 103 2. End-to-end Behavior 105 Unlike many of the other specific link layers addressed in the ISSL 106 working group, ISSLOW operates only over low speed point to point links 107 or connections. Examples of these links include dial up lines, ISDN 108 channels, and leased lines. As such, 'end to end' simply means between 109 two points. In today's inter/intranet environment, this will include: 111 - host to directly connected host. 112 - host to/from network access device (router or switch). 113 - Edge device (subnet router or switch) to/from router or switch. 114 - In rare circumstances, the link may run from backbone router to 115 backbone router. 117 Thus, the endpoints are two network elements as described above. The 118 Controlled Load and Guaranteed services for ISSLOW links are applied on 119 the link between these elements and often represent the first or last 120 wide area hop in a true end to end service. It is important to note 121 that these links tend to be the most 'bandwidth constrained' along the 122 path. 124 ISSLOW services are only provided if both endpoints on the link support 125 ISSLOW. This is determined during the PPP negotiation. Because of the 126 unique characteristics of a point to point link with both endpoints 127 supporting ISSLOW, traffic is automatically shaped. That is, incoming 128 traffic will be TSpec conformant, and except for some special 129 considerations for Guaranteed Service (below), the admission control 130 function can make decisions based on local state: it does not need to 131 coordinate with the network element on the other end of the link. As 132 described in [5], Guaranteed Service should approximate the 133 functionality of a leased line. Since ISSLOW runs over point to point 134 links, when rate control and delay bounds are provided for individual 135 flows, the link inherently acts like a leased circuit. 137 Thus, even for Guaranteed Service, because this hop is the most 138 bandwidth constrained, and because the connection is dual simplex 139 (e.g., not a shared link for send & receive), all admission control 140 decisions can be made locally. 142 3. Motivation 144 Previous sections described the motivation for the ISSLOW capabilities. 145 Dial up users are now treating their relatively low-bitrate connections 146 as they would a higher speed connection. They are mixing multiple flows 147 of data and expect performance similar to what they see in a LAN 148 environment. However, it is deployment of realtime applications which 149 is the primary motivation for hosts to implement Integrated Services. 151 In particular, IP Telephony, which has tight delay constraints for 152 commercial-level performance, produces small packets. When these are 153 mixed with flows consisting of large packets (e.g. HTTP, FTP), delay 154 variance increases and absolute delay suffers as these small packets 155 wait in the queue behind even a single large packet being transmitted on 156 the link. Because of the jitter tolerance and adaptive nature of codecs 157 used for packet voice and video, just providing a controlled load 158 service would satisfy most of the need for IP Telephony and other 159 realtime applications which are expected to run over low-bitrate 160 connections. 162 Another consideration in handling of packets over low speed links occurs 163 when looking at the end-to-end issues. The low speed link is 164 usually just one hop on a longer path between endpoints. As such, it is 165 usually the limiting factor in performance. While this needs to be 166 considered in the host to router configuration, it becomes more critical 167 between edge devices and backbone routers where there is a multiuser 168 subnet as source and destination for traffic and a low-bitrate link to 169 the router. To ensure some performance bounds end-to-end, guaranteed 170 service should be considered over these links even if it cannot be 171 offered end to end in the network. 173 4. Network Element Data Handling Requirements 175 The ISSLOW Network Service element may be implemented in hardware or 176 software. As described in [1] and [2], for systems which can perform 177 bit-oriented transmission control, the suspend/resume approach optimizes 178 the available bandwidth by minimizing header overhead associated with 179 MLPPP fragmentation. For systems which provide frame-oriented 180 transmission control, the fragmentation approach can be implemented with 181 no hardware changes. Choice of suspend/resume versus fragmentation 182 should be made based on the hardware's capability to handle the new HDLC 183 framing described in [1] and the system overhead associated with byte by 184 byte scanning (required by suspend/resume). 186 To provide controlled load or guaranteed service with the suspend/resume 187 approach, when a packet for an IntServ admitted flow (QoS packet) 188 arrives during transmission of a best effort packet and continued 189 transmission of the best effort packet would violate delay constraints 190 of the QoS service flows, the best effort packet is preempted, the QoS 191 packet/fragments are added to the transmission, and the best effort 192 packet transmission is then resumed: usually all in one transmission. 193 The receiving station separates the best effort packet from the embedded 194 QoS fragments. It is also conceivable that one IntServe Flow's packet 195 might suspend another flow's packet if the delivery deadline of the new 196 packet is earlier than the current packet. 198 For systems which use fragmentation, since suspend/resume is not 199 possible, all packets longer than the maximum tolerable delay for an 200 IntServ packet are fragmented prior to transmission so that a short 201 packet for another flow can be interleaved between fragments of a large 202 packet and still meet the transmission deadline for the IntServ flow. 204 Note that the fragmentation discussed in this document refers to 205 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 206 as described in [1], not IP or other layer 3 fragmentation. MLPPP 207 fragmentation is local to the PPP link, and does not affect end-to-end 208 (IP) MTU. 210 4.01 Rate and Delay 212 ISSLOW assumes that the nature of point to point links is such that 213 rate, transmission time and delay are fixed and consistent. The rate of 214 the link is determined at connection time, and the devices on the link 215 (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. 216 Unfortunately this is not always true. 218 POTS modems can have varying rates, but the rate for a particular 219 POTS modem connection tends to converge over time to a particular 220 value as the modems adjust to line conditions. Implementations 221 may need to adjust their admission control policies to reflect 222 this convergence. Refer to Appendix A for more considerations 223 on link characteristics and associated delay. 225 4.02 Link Aggregation 227 Although certain link types, like ISDN, permit dynamic allocation of 228 Bandwidth across multiple links, it is assumed that the Admission 229 Control service will consider the impact of multiple physical links over 230 the point to point logical connection. 232 Note that because of the load balancing effect of Multilink PPP (MLPPP), 233 two 64 Kbps links should exhibit the delay and transmission 234 characteristics of a single 128 Kbps link. However, MLPPP 235 implementations may approach load balancing and fragmentation 236 differently. The mechanism used should be taken into consideration when 237 implementing the scheduler (especially token bucket) for packets, 238 fragments, and suspend/resume on top of existing MLPPP services to 239 ensure that adequate rate and delay characteristics are maintained. 241 4.1 Controlled Load versus Guaranteed Service 243 With most link layers, Guaranteed Service requires more tightly 244 controlled service by the Network Element, and in most cases, acceptance 245 of a Guaranteed Service request results in over-provisioning of link 246 level resources. Controlled Load (CL) Service is usually less 247 constrained and permits more flexibility in scheduling of packets for 248 the link. 250 Controlled Load requires that the delay associated with packet 251 transmission be 'closely equivalent to unloaded best effort service.' 252 Because ISSLOW operates over point to point links, unloaded best effort 253 service means that best effort packets will incur no more than burst 254 packet delay: M/r where M is the maximum packet size and r is the 255 transmission rate. Thus maximum permitted delay for a Controlled Load 256 packet (CLmDELAY) is bounded by M/r + P/r where P is the size of the 257 outgoing packet. 259 4.2 Controlled Load and Guaranteed Service Data Handling 261 Upon arrival of a QoS flow's packet, the ISSLOW Network Element 262 determines if the packet is conformant. If it is not, Policing is 263 applied (see Policing). Conformant means: 265 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 266 for Guaranteed Service: rT+b with T=time period). 267 2) The packet does not cause a token bucket overflow. 269 If the packet is conformant, it is compressed as required, fragmented 270 (if necessary), and scheduled. If there is no conflicting best effort 271 traffic, the packet is queued along with the rest of conformant QoS 272 traffic and scheduled with respect to any other IntServ flows such that 273 its transmission deadline is met. 275 For the suspend/resume implementation to achieve controlled load, any 276 packets being transmitted whose transmission would violate 277 the CLmDELAY are suspended. Otherwise, the QoS packet/fragments are 278 scheduled ahead of any queued best effort traffic. 280 For CL Fragmentation implementations, the packet/fragment is scheduled 281 ahead of any best effort packets. Note that all best effort packets 282 must be divided into fragments less than or equalto the smallest MRU 283 (or associated fragment size) of all the QoS flows. This incurs at 284 most one fragment delay for the QoS traffic: closely equivalent to 285 unloaded best effort service. 287 For Guaranteed Service for both Fragmentation and suspend/resume, the 288 scheduler determines if continued transmission of the best effort packet 289 being transmitted would cause delay greater than the acceptable delay. 290 If so, the best effort packet is preempted or, in the case of 291 fragmentation, the QoS packet is scheduled ahead of the rest of the 292 best effort packets' fragments. 294 4.3 Controlled Load and Guaranteed Service Class Mappings 296 Supporting integrated services over PPP links which implement MCML or 297 RTF can be accomplished in several ways. Guidelines for mapping these 298 services to PPP links are presented below. Note that these guidelines 299 assume that some sort of signaling is used to indicate desired quality 300 of service to both the sender and receiver of a flow over a PPP link. 301 These guidelines also assume that it is unlikely that a series of PPP 302 links be connected to each other. It is noted that even if a series of 303 PPP links were to be connected together, it is likely that each link 304 would have different characteristics, and further, that frames would 305 have to be reassembled at the terminus of each link for error 306 correction purposes, requiring that class assignment be performed on 307 each hop of the link, rather than just forwarding frames with 308 identical segmentation or fragmentation. These assumptions remove any 309 requirement on the service-mapping implementation that quality of 310 service information be implicit in the class selection applied to 311 particular flows, allowing the sender of an integrated services flow on 312 a PPP link complete freedom in assigning classes to flows (or packets 313 within flows). 315 One important observation that must be made is that the classes that 316 MCML and RTF provide can be viewed purely as PPP-specific 317 segmentation/fragmentation mechanisms. That is, while the class number 318 must remain constant on an intra-packet basis, it may vary on an inter- 319 packet basis for all flows transiting a PPP link. Actual assignment of 320 particular flows to fixed classes is unnecessary, as the class numbers 321 are not required to have any meaning other than in the context of 322 identifying the membership of fragments/segments as part of a single 323 packet. This consideration is very important, in that it offers 324 implementers with a large degree of flexibility in providing integrated 325 services over PPP links. This observation implies that the queuing 326 discipline used to differentiate different flows does not have any ties 327 to the class numbers used. This point is sufficiently important that an 328 example is provided below. 330 Consider a PPP link using the MCML short sequence number fragment 331 format (that is, four classes are provided). Assume that in addition 332 to carrying best effort traffic, this link is carrying four guaranteed 333 service flows, A, B, C, D, and E. Further assume that the link capacity 334 is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic 335 is sufficient to keep the pipe full at all times and that GS flows A-E 336 are each 10kbit/s and all have delay bounds of 145ms. 338 Time(ms) Action 339 0 BE traffic is queued up 340 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 341 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 342 9 8kbit packet from flow A arrives 343 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 344 11 8kbit packet from flow B arrives 345 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 346 13 8kbit packets from flows C, D, and E arrive 347 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 348 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 349 18 2kbit fragment from A sent, cls 1 350 20 2kbit fragment from B sent, cls 2 351 22 2kbit fragment from A sent, cls 1 352 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 353 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 354 27 8kbit packet from flow A arrives 355 28 2kbit fragment from B sent, cls 2 356 30 2kbit fragment from C sent, cls 3 357 32 2kbit fragment from E sent, cls 1 358 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 359 36 2kbit fragment from E sent, cls 1 360 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 361 (etc.) 363 This example shows several things. First, multiple flows may share the 364 same class, particularly in the case where there are more flows than 365 classes. More importantly, there is no reason that a particular flow 366 must be assigned to a fixed class - the only requirement is that a each 367 packet, when fragmented, must have the same class value assigned to all 368 fragments. 370 One suggestion to implementers of integrated services on MCML and RTF 371 links is that all BE and non-conformant traffic be logically separated 372 from conformant traffic, and mapped to a fragmentable (MCML classes 0-3 373 in short sequence number fragment format, 0-15 in long sequence number 374 fragment format) or suspendable (RTF classes 0-6) class. Since BE and 375 non-conformant traffic will in most implementations not be scheduled 376 for transmission except when a link is empty (that is, no CL or GS 377 traffic is ready for transmission), it is possible to recommend use of 378 class number 0 for BE/non-conformant traffic. Whether BE and non- 379 conformant traffic are treated differently in regards to transmission 380 (e.g., BE is given priority access over non-conformant traffic to the 381 link) or whether within each type of traffic special treatment is 382 afforded to individual flows (e.g., WFQ, RED, etc.) is implementation 383 dependent. 385 In the case where fewer reservations are expected than the total number 386 of classes negotiated for a PPP link, it is possible to assign 387 individual flows to fixed class numbers. This assignment is useful in 388 the case where the protocol identifier associated with one or more 389 flows is known at LCP negotiation time and the bandwidth of the 390 connection is relatively small. If these conditions hold true, then for 391 those flows that are known, a specific class can optionally be assigned 392 to them and the prefix elision PPP option can be used for those classes 393 to achieve a small bandwidth savings. 395 5. Invocation Information 397 To invoke Controlled Load and Guaranteed Services, both traffic 398 characteristics and the flow itself must be identified to the Network 399 Element. Several methods can be employed to identify the flows. For 400 RSVP, filtering can be used to identify the flows. For non-RSVP 401 implementations, mechanisms such as the FlowID field in IP Version 6, or 402 the TOS field in IP version 4 can be used. As described above, the 403 Network Element can then use the specified values to apply the 404 appropriate QoS and to map the flows to a particular class. 406 A number of major router and switch vendors currently support use of 407 the TOS bits to signal priority and class of service. As a result, 408 applications and host proxies have been developed to enable users and 409 network managers to apply policies requesting differential services via 410 TOS. Use of these bits is the easiest way to identify flows without 411 the overhead of filtering. 413 It is therefore strongly recommended that the Network Service Element 414 support mapping of the IP Precedence bits of the TOS field to MLPPP 415 classes described in [1] as follows: 417 IP Precedence Value Multiclass - short seq Multiclass - long seq 419 0 0 0 420 1 0 1 421 2 or 3 0 2 or 3 422 4 1 4 423 5 2 5 424 6 or 7 3 6 or 7 426 Note that use of the TOS field or of the FlowID field does not preclude 427 prefix elision. The Network Service Element can map the TOS or FlowID 428 to a MLPPP class, elide the prefix before transmission, and the prefix 429 (with TOS or FlowID) will be reapplied by the receiver. 431 If the Network Service Element is running on a system that doesn't 432 support application or proxy use of the TOS or FlowID fields, then 433 filtering must be applied and: 435 As described in [4], Controlled Load Service is invoked by specifying 436 the flow's traffic characteristics through a TSpec (see [5]). 438 As described in [5], Guaranteed Service is invoked by specifying the 439 flow's TSpec and a requested reservation via an RSpec (see [6]). 441 6. Exported Information. 443 For Controlled Load Service, there is no requirement to export 444 information. 446 For Guaranteed service, both C and D terms for delay computations must 447 be made available for export through the Adspec or other means. See 448 Sections 9.1 (Admission Control) for guidelines on computing the C and D 449 terms. 451 See [4] and [5] for additional information on Exported Information. 453 7. Policing 455 Policing is applied to non-conformant QoS traffic and to best effort 456 traffic whose transmission would violate the Controlled Load or 457 Guaranteed Service constraints. This document does not designate a 458 specific packet scheduling implementation. Ideally, best effort traffic can be 459 serviced through separate queues and a weighted queuing mechanism, or when a 460 conflict with QoS traffic arises, best-efforts traffic can simply be discarded. 462 Both Controlled Load and Guaranteed Services permit scheduling of non- 463 conformant traffic as well as the option to discard non-conformant 464 packets. See [4] and [5] for additional information on policing options 465 for Controlled Load and Guaranteed Services. 467 8. Ordering and Merging 469 Refer to [4] and [5] for TSpec and RSpec ordering and merging 470 guidelines. 472 9. Guidelines for Implementors 474 9.1 Bit and Byte Stuffing Considerations 476 Certain kinds of low bandwidth links present special challenges in providing 477 controlled load and guaranteed service even when the ISSLOW protocols are 478 used. These challenges are documented here as a caution to implementers to 479 prevent use of overly optimistic admission control policies. 481 One important consideration in provisioning any PPP link is reductions in 482 available link rate due to bit stuffing. Typical bit stuffing algorithms 483 can result in as much as 20% additional overhead. Thus, admission control 484 algorithms for guaranteed service over links where bit stuffing can take place 485 should take the RSpec rate of all flows and multiply by 1.2 in determining 486 whether a new flow can be admitted or not. Admission control algorithms for 487 controlled load reservations may use a similar algorithm using the TSpec peak 488 rate or may attempt to measure the actual degree of expansion occurring on a 489 link due to bit stuffing. This characterization can then be used to adjust 490 the calculated remaining link capacity. Such algorithms must be used 491 cautiously, in that the degree of bit stuffing occurs may vary significantly, 492 both in an inter- and intra-flow fashion. 494 Byte stuffing is also found on many PPP links, most frequently on POTS modems 495 when using the v.42 protocol. Byte stuffing poses a difficult problem to 496 admission control, particularly in the case of guaranteed service, due to 497 its highly variable nature. In the worse case, byte stuffing can result in 498 a doubling of frame sizes. As a consequence, a strict implementation of 499 admission control for guaranteed load on byte stuffed PPP links should double 500 RSpec of link traffic in making flow admission decisions. As with bit 501 stuffing, implementations of controlled load service admission control 502 algorithms for links with byte stuffing may attempt to determine average 503 packet expansion via observation or may use the theoretical worst case values. 505 In addition to PPP bit- and byte stuffing, other protocols used in POTS 506 modems also have ramifications on link capacity. The v.34 protocol, for 507 instance, is adaptive to link conditions, and is able to recalibrate its 508 transmission rate multiple times over the duration of a connection. 509 Typically this re-calibration will result in a small (~10%) increase in 510 transmission rate over the initial connection within the first minute of 511 a call. It is important to note, however, that other results are possible 512 as well, including decreases in available bandwidth. Admission control 513 algorithms must take such changes into consideration as they occur, and 514 implementations must be designed to gracefully handle the pathological case 515 where link rate actually drops below the currently reserved capacity of a link. 517 The v.42 protocol is another potential troublesome area in implementing 518 integrated services over low bandwidth links. This protocol, which provides 519 link layer reliability via retransmission, can result in frames experiencing 520 unpredictable delays in transiting such a link. Retransmissions also 521 implicitly steal link bandwidth from other traffic. These delays and 522 reductions in link bandwidth make it extremely difficult to honor a 523 guaranteed service reservation. On a link that is actually lightly or 524 moderately loaded, a controlled load service can to some extent accept 525 such events as part of the behavior of a lightly loaded link. Unfortunately, 526 as actual link utilization increases, v.42 retransmissions have the 527 potential of stealing larger and larger fractions of available link bandwidth; 528 making even controlled load service difficult to offer at high link utilization 529 when retransmissions occur. 531 Finally, the framing method must be factored into the overhead associated with 532 link level tramsmission. If fragmentation is used, the overhead associated with 533 fragment headers must be included in the admission control calculations below. 534 If suspend/resume is used, the additional framing overhead for inserted packets 535 must also be calculated. 537 9.2 Compression Considerations 539 The ISSLOW specification supports several PPP options. When deciding 540 whether to admit a flow, Admission Control must compute the impact of 541 the following on MTU size, rate, and fragment size: 543 Header compression: Van Jacobson or Casner-Jacobsen. 544 Prefix Elision. 545 CCP. 546 CRTP. 547 Fragment header option used. 548 Fragmentation versus suspend/resume approach. 550 If any of the compression options are implemented for the connection, 551 the actual transmission rate, and thus the bandwidth required of the 552 link, will be reduced by the compression method(s) used. 554 Prefix elision can take advantage of mapping flows to MLPPP classes 555 to elide prefixes which cannot be compressed at higher layers. By 556 establising agreement across the link, the sender may elide a prefix for 557 a certain class of traffic and upon receiving packets in that class, the 558 receiver can restore the prefix. 560 Both compression gain and elision gain must be included as described in 561 the admission control section below. 563 9.3 Admission Control 565 Admission Control must decide whether to admit a flow based on rate and 566 delay. Assume the following: 568 LinkRate is the rate of the link. 569 MTU is the maximum transmission unit from a protocol. 570 MRU is the maximum receive unit for a particular link. 571 CMTU is the maximum size of the MTU after compression is applied. 572 eMTU is the maximum effective size of the MTU after fragmentation. 573 FRAG is the fragment size including MLPPP header/trailers. 574 Header is the size of the header/trailers/framing for MLPPP/Fragments. 575 pHeader is the additional header/framing overhead associated with 576 suspend/resume. This should include FSE and worst case stuffing 577 overhead. 578 pDelay is the delay associated with suspend/resume packets. 579 b is the bucket depth in bytes 580 R is the requested Rate. 581 D is the fixed overhead delay for the link (Modem, DSU, etc). 582 C is the delay associated with transmission and fragmentation. 583 eRate is the effective rate after compression and fragmentation. 585 The D term may be configured by an administrative tool once the network 586 is installed; it may be computed using the Adspec or other realtime 587 measurement means; or it may be available from hardware during link 588 setup and/or PPP negotiation. Refer to Appendix A for more 589 considerations on PPP link characteristics and delays. 591 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 592 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 593 Service: 595 To determine whether the requested rate is available, Admission Control 596 must compute the effective rate of the request (eRate) - worst case - as 597 follows: 599 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 601 eMTU = (#_of_Fragments) * FRAG 603 eRate = eMTU/CMTU * R 605 Admission Control should compare the eRate of the request against the 606 remaining bandwidth available to determine if the requested rate can be 607 delivered. 609 For Controlled Load Service, a flow can be admitted as long as there is 610 sufficient bandwidth available (after the above computation) to meet the 611 rate requirement, and if there is sufficient buffer space (sum of the 612 token bucket sizes does not exceed the buffer capacity). While some 613 statistical multiplexing could be done in computing admissability, the 614 nature of the low-bitrate links could make this approach risky as any 615 delay incurred to address a temporary overcommitment could be difficult 616 to amortize. 618 Guaranteed Service requires delay computations. These computation are 619 based on the standard formula for delay: 621 Delay = b/R + C/R + D 623 Note that for suspend/resume, an additional term is required: 625 pDelay = b/R + C/R + D + pHeader/R. 627 This term exists because of the additional overhead associated with the 628 suspend/resume headers created when suspending a packet. In the worse 629 case, every transmission of a QoS packet could require suspension of a 630 best effort packet and thus incur the overhead. In most networks, this 631 term will be nominal at most. However, on some low-bitrate links, the 632 overhead may be worth computing. 634 Since MLPPP includes fragmentation, the C term is not fixed and must be 635 represented by the worse case fragmentation as computed in the effective 636 MTU size: 638 C = eMTU. 640 Note that because ISSLOW runs on point to point links, Guaranteed 641 Service can be offered over a link without any negotiated agreement from 642 the next hop. However, if these services are used in conjunction with 643 RSVP, the C and D values above should be used in the Adspec. 645 9.4 Fragment Scheduling Considerations 647 As described in Section 4, large packets should be fragmented to a size 648 sufficiently small to allow higher priority flows to get a hold of the 649 line quickly enough to not violate their reservation constraints. As 650 such, the upper bound for fragment sizes should be no larger than the 651 smallest MTU of all QoS flows. While a very small fragment size 652 is desirable from the point of view of efficient link utilization, the 653 overhead associated with highly granular fragmentation makes it 654 necessary to strike a balance between these considerations. While this 655 document will not specify a particular scheduling algorithm, the 656 following example should help illustrate the issue: 658 Assume we have three different priority flows, A, B, and C. 659 A is higher priority than B, B higher than C 660 (and of course it is transitive). Packets from flow C take 661 100ms, flow B takes 30ms, and flow A takes 30ms to transmit. B's 662 required maximum latency is 70ms, while A's is 50ms. The above scenario 663 results in flowsB and C needing to be segmented into 20ms long fragments - 664 that way a lower priority frame will hold the link at most 665 20ms before A gets to the link, taking another 30ms to transit, 666 totaling 50ms - all well and good. B has a problem, however - 667 in the scenario where a fragment from C is just starting 668 to transmit the link when packets from A and B arrive (call 669 this time 0). The fragment from C will transmit until time 20ms. 670 After that, the A packet will transmit - finishing by time 50ms, 671 just in time. At this point, the fragment from B starts to 672 transmit - taking 30ms more, finishing by time 80ms (thus violating 673 its reservation). 675 The important point above the scenario is not that it is possible 676 to underprovision a link, but that a link can be underutilized 677 by using too large a fragment size - in the above case, a 10ms 678 fragment size would have allowed both A and B to honor their 679 reservations, a 20ms size does not. 681 10. Evaluation Criteria 683 For Controlled Load Service, the ISSLOW network element must ensure that 684 the service requested via the TSpec is delivered to the requesting QoS 685 flow such that the PPP link appears to be a 'lightly loaded link. 687 As a baseline, it is suggested that performance measurements on 688 throughput, delay, and packet error measurements be performed on an 689 unloaded link with just the QoS flow using various packet sizes. The 690 baseline should measure performance for both conformant and non- 691 conformant traffic when for overloading the link with a single flow. 692 Once these measurements are complete, measurements of the 693 Controlled Load Service should be performed as follows: 695 1) Request QoS flows in the presence of best effort traffic and ensure 696 that the QoS flows' performance approximate the unloaded baseline 697 measurements. 699 2) Request QoS flows whose aggregate throughput would exceed the link 700 capacity. Admission Control should deny these service requests or admit 701 them as best effort only. 703 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. 704 Ensure recovery of the flow once the traffic becomes conformant. 706 For Guaranteed Service: 708 1) Ensure that Admission Control will deny service requests or convert 709 them to best effort when link capacity or delay bounds would be 710 exceeded. 712 2) On a best-efforts loaded link, ensure that the number of lost packets 713 does not exceed those established in the baseline measurements. 715 3) On a best-efforts loaded link, ensure that delay and rate commitments 716 can be met for QoS flows. 718 4) With multiple QoS flows, ensure that an admission of additional QoS 719 flows does not cause a violation in rate, error rate, or delay 720 constraints of any QoS flow. 722 11. Security Considerations 724 General security considerations for PPP links are 725 addressed elsewhere. A specific security consideration relevant to 726 providing quality of service over PPP links appears when relying 727 on either observed or theoretical average packet expansion 728 during admission control due to bit- or byte-stuffing. 729 Implementations based on these packet-expansion values 730 contain a potential vulnerability to denial of service attacks. 731 An adversary could intentionally send traffic that will result in worst 732 case bit- or byte stuffing packet expansion. This in turn could result 733 in quality of service guarantees not being met for other flows due to 734 overly permission admission control. This potential denial of service 735 attack argues strongly for using a worst case expansion factor in 736 admission control calculations, even for controlled load service. 738 12. References 740 [1] C. Bormann "The Multi-Class Extension to Multilink PPP" 741 Internet Draft, July 1997, 743 [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" 744 Internet Draft, July 1997, 746 [3] rfc2216 -- Network Element Service Specification Template. S. 747 Shenker, J. Wroclawski. September 1997 749 [4] rfc2211 -- Specification of the Controlled-Load Network 750 Element Service. J. Wroclawski. September 1997 752 [5] rfc2212 -- Specification of Guaranteed Quality of Service. S. 753 Shenker, C. Partridge, R. Guerin. September 1997 755 [6] rfc2215 -- General Characterization Parameters for Integrated 756 Service Network Elements. S. Shenker, J. Wroclawski. September 1997. 758 13 Author's Address: 760 Steve Jackowski 761 Deterministic Networks, Inc. 762 245M Mt Hermon Rd, #140 763 Scotts Valley, CA 95060 764 stevej@DeterministicNetworks.com 765 (408)813-6294 767 David M. Putzolu 768 Intel Architecture Labs (IAL) 769 JF3-206-H10 770 2111 NE 25th Avenue 771 Hillsboro, OR 97124-5961 772 David.Putzolu@intel.com 773 (503) 264-4510 775 Appendix A: Additional Admission Control Issues for PPP Links 777 PPP links present special challenges for correctly designing admission- 778 control algorithms. These challenges derive from both the nature of the 779 PPP protocol itself as well as some of the types of links it is 780 commonly used on. 782 A.1. PPP Bit Stuffing and Byte Stuffing Effects on Admission Control 784 An important consideration in performing admission control for PPP 785 links is reductions in effective link rate due to bit stuffing. Typical 786 bit stuffing algorithms can result in as much as 20% additional 787 overhead. Thus, admission control implementations for guaranteed 788 service over links where bit stuffing is used should take the RSpec 789 rate of all flows and multiply by 1.2 in determining whether a new flow 790 can be admitted or not. Admission control implementations for 791 controlled load reservations may use a similar algorithm using the 792 TSpec peak rate or may attempt to measure the actual degree of 793 expansion occurring on a link due to bit stuffing. This 794 characterization can then be used to adjust the calculated remaining 795 link capacity. Such measurements must be used cautiously, in that the 796 degree of bit stuffing that occurs may vary significantly, both in an 797 inter- and intra-flow fashion. 799 Byte stuffing is also used on many PPP links, most frequently on POTS 800 modems when using the v.42 protocol. Byte stuffing poses a difficult 801 problem to admission control, particularly in the case of guaranteed 802 service, due to its highly variable nature. In the worse case, byte 803 stuffing can result in a doubling of frame sizes. As a consequence, a 804 strict implementation of admission control for guaranteed load on byte 805 stuffed PPP links should double the RSpec of link traffic in making 806 flow admission decisions. As with bit stuffing, implementations of 807 controlled load service admission control algorithms for links with 808 byte stuffing may attempt to determine average packet expansion via 809 observation or may use the theoretical worst case values. 811 A.2. POTS Modem Considerations 813 The protocols used in current implementations of POTS modems can 814 exhibit significant changes in link rate and delay over the duration of 815 a connection. Admission control and link scheduling algorithms used 816 with these devices must be prepared to compensate for this variability 817 in order to provide a robust implementation of integrated services. 819 Link rate on POTS modems is typically reported at connection time. This 820 value may change over the duration of the connection. The v.34 821 protocol, used in most POTS modems, is adaptive to link conditions, and 822 is able to recalibrate transmission rate multiple times over the 823 duration of a connection. Typically this will result in a small (~10%) 824 increase in transmission rate over the initial connection within the 825 first minute of a call. It is important to note, however, that other 826 results are possible as well, including decreases in available 827 bandwidth. Admission control algorithms must take such changes into 828 consideration as they occur, and implementations must be able to 829 gracefully handle the pathological case where link rate actually drops 830 below the currently reserved capacity of a link. 832 Delay experienced by traffic over POTS modems can vary significantly 833 over time. Unlike link rate, the delay often does not converge to a 834 stable value. The v.42 protocol is used in most POTS modems to provide 835 link-layer reliability. This reliability, which is implemented via 836 retransmission, can cause frames to experience significant delays. 837 Retransmissions also implicitly steal link bandwidth from other 838 traffic. These delays and reductions in link bandwidth make it 839 extremely difficult to honor a guaranteed service reservation. On a 840 link that is actually lightly or moderately loaded, a controlled load 841 service can to some extent accept such events as part of the behavior 842 of a lightly loaded link. Unfortunately, as actual link utilization 843 increases, v.42 retransmissions have the potential of stealing larger 844 and larger fractions of available link bandwidth; making even 845 controlled load service difficult to offer at high link utilization 846 when retransmissions occur.