idnits 2.17.1 draft-ietf-issll-isslow-svcmap-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ietf-issl-isslow-svcmap-05', but the file name used is 'draft-ietf-issll-isslow-svcmap-05' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 121 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 25 instances of lines with control characters in the document. ** The abstract seems to contain references (4], [5], [6], 3,, [1,2,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 83 has weird spacing: '...ices on such ...' == Line 98 has weird spacing: '... layers the l...' == Line 192 has weird spacing: '...a short packe...' == Line 208 has weird spacing: '...d delay chara...' == Line 237 has weird spacing: '...tics of some ...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (February 3, 1999) is 9214 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) == Missing Reference: '10' is mentioned on line 704, but not defined == Unused Reference: '7' is defined on line 732, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-04 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') -- No information found for draft-ietf-issl-isslow-mcml - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-ietf-issl-isslow-rtf - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Steve Jackowski/Deterministic Networks 2 Expires: August 1999 David Putzolu/Intel Architecture Labs 3 February 3, 1999 5 Network Element Service Specification for Low Speed Networks 6 draft-ietf-issl-isslow-svcmap-05.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 A set of companion documents describe an architecture for providing 31 integrated services over low-bitrate links, such as modem lines, 32 ISDN B-channels, and sub-T1 links [1, 2, 3, 4]. The main components 33 of the architecture are: a set of real-time encapsulation formats for 34 asynchronous and synchronous low-bitrate links, a header compression 35 architecture optimized for real-time flows, elements of negotiation 36 protocols used between routers (or between hosts and routers), and 37 announcement protocols used by applications to allow this negotiation 38 to take place. 40 This document defines the service mappings for controlled load [5] and 41 guaranteed [6] services for use with the real-time encapsulation part 42 of the architecture. The approach takes the form of a set of guidelines 43 and considerations for implementing these services, along with 44 evaluation criteria for elements providing these services. 46 Table of Contents 48 1. Introduction 3 49 1.1 Specification Language 3 50 2. End to End Behavior 3 51 3. Motivation 4 52 4. Network Element Data Handling Requirements 5 53 4.1 Rate and Delay 5 54 4.2 Link Aggregation 6 55 4.3 Controlled Load Versus Guaranteed Service 6 56 4.4 Controlled Load and Guaranteed Service Data Handling 7 57 4.5 Controlled Load and Guaranteed Service Class Mapping 7 58 5. Invocation Information 10 59 6. Exported Information 10 60 7. Ordering and Merging 10 61 8. Guidelines for Implementors 10 62 8.1 PPP Bit and Byte Stuffing Effects on Admission Control 10 63 8.2 Compression Considerations 11 64 8.3 Admission Control 11 65 8.4 Fragment Scheduling Considerations 13 66 9. Evaluation Criteria 14 67 10. Security Considerations 14 68 11. References 15 69 12. Authors' Addresses 16 70 Acknowledgements 16 71 Appendix A. Admission Control Considerations for POTS Modems 16 72 1. Introduction 74 In addition to the ``best-effort'' services the Internet is well-known 75 for, other types of services (``integrated services'') are being 76 developed and deployed in the Internet. These services support special 77 handling of traffic based on bandwidth, latency, and other requirements 78 that cannot usually be met using ``best-effort'' service. 80 This document defines how to map integrated services ``controlled 81 load'' [5] and ``guaranteed'' [6] services on to low- 82 bandwidth links. The architecture and mechanisms used to implement 83 these services on such links are defined in a set of companion 84 documents. The mechanisms defined in these documents include both 85 compression of flows (for bandwidth savings) [4] and a set of 86 extensions to the PPP protocol which permit fragmentation [2] 87 or suspension [3] of large packets in favor of packets from flows 88 with more stringent service requirements. 90 1.1. Specification Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 2. End-to-end Behavior 98 Unlike other link layers the links referred to in this document operate 99 only over low speed point to point links or connections. Examples 100 of the kinds of links addressed here include dial-up lines, ISDN 101 channels, and leased lines. In this context, 'end to end' simply means 102 between two points. In typical inter/intranet environments, this will 103 include: 105 - host to directly connected host. 106 - host to/from network access device (router or switch). 107 - Edge device (subnet router or switch) to/from router or switch. 108 - In rare circumstances, the link may run from backbone router to 109 backbone router. 111 Thus, the endpoints are two network elements as described above. The 112 Controlled Load and Guaranteed services for the links addressed here 113 are applied between these elements and often represent the first or last 114 wide area hop in a true end to end service. It is important to note 115 that these links can be the most ``bandwidth constrained'' along the 116 path. 118 The services utilized in mapping integrated services to these links 119 are only provided if both endpoints on the link support the architecture 120 and mechanisms referenced above. Support for these mechanisms is 121 determined during the PPP negotiation. Because of the unique 122 characteristics of a point to point link with both endpoints 123 supporting these mechanisms, traffic is automatically shaped. 124 That is, incoming traffic will be TSpec conformant and the 125 admission control function can make decisions based on local state: 126 it does not need to coordinate with the network element on the other 127 end of the link. Furthermore, since the context that these services 128 is implemented in is a point to point link, when rate control and 129 delay bounds are provided for individual flows, the link inherently 130 acts like a leased circuit (that is, it is not shared with any other 131 sources of traffic). The non-shared nature of these links, along with 132 the fact that point-to-point links are typically dual simplex 133 (i.e., the send and receive channels are separate) is what allows all 134 admission control decisions to be made locally. 136 3. Motivation 138 Many applications are now beginning to make more and more use of such 139 services. As this use grows, the likelihood of a low bandwidth link of 140 some sort being present in the end to end connection grows. In order to 141 meet the service requirements of these applications, it will be necessary 142 to provide these enhanced services on the low bandwidth links in the 143 end to end connection. The presence of integrated services on low 144 bandwidth links is critical to providing a good end to end service 145 because it is precisely on these links that traffic is most likely to 146 experience undesirable effects on latency, jitter, and bandwidth. 148 The negative effects on service can stem both from traditional causes 149 of poor service as well as low bandwidth link specific causes. The 150 traditional cause of poor service is multiple packet queuing effects, 151 and is alleviated by intelligent ordering of outgoing packets on 152 links supporting enhanced services. Low bandwidth links introduce an 153 additional cause for latency - the time for a MTU-sized packet to 154 transit such a link is often large enough to be a significant 155 component in the end to end latency and jitter requirements of 156 flows requiring enhanced services. As such, mechanisms for allowing 157 packets to be suspended or fragmented so as to allow transmission of 158 packets with more stringent service requirements are necessary, 159 along with guidelines for mapping the enhanced services defined in 160 integrated services onto these mechanisms. It is the particular 161 considerations specific to low bandwidth links in providing a good 162 end to end service that this document focuses on. 164 4. Network Element Data Handling Requirements 166 The Network Service element may be implemented in hardware or 167 the available bandwidth by minimizing header overhead associated with 168 software. As described in [2] and [3], for systems which can perform 169 bit-oriented transmission control, the suspend/resume approach optimizes 170 MLPPP fragmentation. For systems which provide frame-oriented 171 transmission control, the fragmentation approach can be implemented with 172 no hardware changes. Choice of suspend/resume versus fragmentation 173 should be made based on the hardware's capability to handle the new HDLC 174 framing described in [2] and the system overhead associated with byte by 175 byte scanning (required by suspend/resume). 177 To provide controlled load or guaranteed service with the suspend/resume 178 approach, when a packet for an admitted flow (QoS packet) arrives 179 during transmission of a best effort packet and continued 180 transmission of the best effort packet would violate delay constraints 181 of the QoS service flows, the best effort packet is preempted, the QoS 182 packet/fragments are added to the transmission, and the best effort 183 packet transmission is then resumed: usually all in one transmission. 184 The receiving station separates the best effort packet from the embedded 185 QoS packet's fragments. It is also conceivable that one QoS flow's packet 186 might suspend another flow's packet if the delivery deadline of the new 187 packet is earlier than the current packet. 189 For systems which use fragmentation where suspend/resume is not 190 possible, any packets longer than the maximum tolerable delay for packets 191 from enhanced service flows are fragmented prior to transmission so that 192 a short packet for another flow can be interleaved between fragments of 193 a larger packet and still meet the transmission deadline for the 194 flow requiring enhanced services. 196 Note that the fragmentation discussed in this document refers to 197 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 198 as described in [2], not IP or other layer 3 fragmentation. MLPPP 199 fragmentation is local to the PPP link, and does not affect end-to-end 200 (IP) MTU. 202 4.1. Rate and Delay 204 One assumption made about the nature of point to point links is that 205 rate, transmission time and delay are fixed and consistent. The rate 206 of the link is assumed to be determined at connection time, and the 207 devices on the link (adapters, modems, DSU/CSUs, etc) traditionally 208 exhibit fixed delay characteristics. Unfortunately these assumptions 209 do not always hold true. Certain link types (e.g., POTS modems) can 210 vary both in terms of data rates and in terms of delay characteristics. 211 Implementations of these services on such links need to adjust their 212 admission control policies to reflect these characteristics. Refer 213 to Appendix A for more considerations on specific link characteristics. 215 4.2. Link Aggregation 217 Although certain link types, like ISDN, permit dynamic allocation of 218 bandwidth across multiple links, it is assumed that the Admission 219 Control service will consider the impact of multiple physical links over 220 the point to point logical connection. 221 Note that because of the load balancing effect of Multilink PPP (MLPPP), 222 two 64 Kbps links should exhibit the delay and transmission 223 characteristics of a single 128 Kbps link. However, MLPPP 224 implementations may approach load balancing and fragmentation 225 differently. The mechanism used should be taken into consideration when 226 implementing the scheduler (especially token bucket) for packets, 227 fragments, and suspend/resume on top of existing MLPPP services to 228 ensure that adequate rate and delay characteristics are maintained. 230 4.3. Controlled Load versus Guaranteed Service 232 With most link layers, Guaranteed Service (GS) requires more tightly 233 controlled service by the Network Element, and in most cases, acceptance 234 of a Guaranteed Service request results in over-provisioning of link 235 level resources. Controlled Load (CL) Service is usually less 236 constrained and permits more flexibility in scheduling of packets for 237 the link. However, due to the characteristics of some types of 238 point to point links (e.g., low bandwidth links such as ISDN, POTS, 239 etc.), providing Controlled Load service may actually be equally or 240 more difficult than Guaranteed Service for certain kinds of traffic. 242 Controlled Load requires that the delay associated with packet 243 transmission be 'closely approximating unloaded best effort service.' 244 Because the links being discussed are not shared (i.e., point-to-point) 245 links, unloaded best effort service means that best effort packets 246 will incur no more than burst packet delay: M/r where M is the maximum 247 packet size and r is the transmission rate. Thus, the maximum permitted 248 delay for a Controlled Load packet (CLmDELAY) is bounded by M/r + P/r 249 where P is the size of the outgoing packet. 251 In the case where the transmission rate is relatively high, the 252 difference in queuing delay between a packet being sent on a 253 totally unloaded link & a lightly loaded link is relatively small. 254 Consider a scenario wherein a 10MBit/s link is being used to carry 255 CL traffic with a burst size of 30 bytes. If the link is totally 256 unloaded, the time to transmit a burst will be 0.024ms. If BE traffic 257 is also being carried on the link, perhaps with a packet size of 258 1000 bytes, and a CL packet is queued after a BE packet, the time 259 before it is transmitted grows to 0.824ms. While this is a 3400% 260 increase, it actually only changes the overall delay for the QoS 261 packet by less than a millisecond - a relatively small amount in the 262 end-to-end latency expected for a large fraction of CL flows. In 263 contrast to this, consider the same traffic being carried over a 264 relatively slow link with a 56Kbit/s data rate. The burst transmit 265 time for a CL packet on an unloaded link would be approximately 4ms. 266 If a single BE packet was queued before a CL packet, the transmit time 267 for the CL packet would grow to 147ms - an increase in transmission 269 time of over 140ms. This change is quite significant in the timescales 270 used for many CL reservations. 272 Given the special considerations associated with scheduling CL flows on 273 low bandwidth links, "standard" assumptions and implementations of 274 controlled load service may not result in expected performance. 275 Implementors must careful review all assumptions and parameters in 276 order to ensure correct functioning. 278 4.4. Controlled Load and Guaranteed Service Data Handling 280 Upon arrival of a QoS flow's packet, the Network Element determines 281 if the packet is conformant. If it is not, Policing is applied 282 (see Policing). Conformant means: 284 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 285 for Guaranteed Service: rT+b with T=time period). 286 2) The packet does not cause a token bucket overflow. 288 If the packet is conformant, it is compressed as required, fragmented 289 (if necessary), and scheduled. If there is no conflicting best effort 290 traffic, the packet is queued along with the rest of conformant QoS 291 traffic and scheduled with respect to any other enhanced services flows 292 such that its transmission deadline is met. 294 For the suspend/resume implementation to achieve controlled load, any 295 packets being transmitted whose transmission would violate 296 the CLmDELAY are suspended. Otherwise, the QoS packet/fragments are 297 scheduled ahead of any queued best effort traffic. 299 For CL Fragmentation implementations, the packet/fragment is scheduled 300 ahead of any best effort packets. Note that all best effort packets 301 must be divided into fragments less than or equal to the smallest MRU 302 (or associated fragment size) of all the QoS flows. This incurs at 303 most one fragment delay for the QoS traffic: closely equivalent to 304 unloaded best effort service. 306 For Guaranteed Service for both fragmentation and suspend/resume, the 307 scheduler determines if continued transmission of the best effort packet 308 being transmitted would cause delay greater than the acceptable delay. 309 If so, the best effort packet is preempted or, in the case of 310 fragmentation, the QoS packet is scheduled ahead of the rest of the 311 best effort packets' fragments. 313 4.5. Controlled Load and Guaranteed Service Class Mapping 315 Supporting integrated services over PPP links which implement MCML or 316 RTF can be accomplished in several ways. Guidelines for mapping these 317 services to PPP links, and specifically, to the classes provided by the 318 suspend/resume and fragmentation mechanisms mentioned above, are 319 presented below. Note that these guidelines assume that some sort 320 of signaling is used to indicate desired quality of service to both 321 the sender and receiver of a flow over a PPP link. These guidelines 322 also assume that it is unlikely that a series of PPP links be 323 connected to each other. It is noted that even if a series of PPP 324 links were to be connected together, it is likely that each link 325 would have different characteristics, and further, that frames would 326 have to be reassembled at the terminus of each link for error 327 correction purposes, requiring that class assignment be performed on 328 each hop of the link, rather than just forwarding frames with 329 identical segmentation or fragmentation. These assumptions remove any 330 requirement on the service-mapping implementation that quality of 331 service information be implicit in the class selection applied to 332 particular flows, allowing the sender of an integrated services flow on 333 a PPP link complete freedom in assigning classes to flows (or to 334 packets within flows). 336 One important observation that must be made is that the classes that 337 MCML and RTF provide can be viewed purely as PPP-specific 338 segmentation/fragmentation mechanisms. That is, while the class number 339 must remain constant on an intra-packet basis, it may vary on an inter- 340 packet basis for all flows transiting a PPP link. Actual assignment of 341 particular flows to fixed classes is unnecessary, as the class numbers 342 are not required to have any meaning other than in the context of 343 identifying the membership of fragments/segments as part of a single 344 packet. This consideration is very important, in that it offers 345 implementers with a large degree of flexibility in providing integrated 346 services over PPP links. This observation implies that the queuing 347 discipline used to differentiate different flows does not have any ties 348 to the class numbers used. This point is sufficiently important that an 349 example is provided below. 351 Consider a PPP link using the MCML short sequence number fragment 352 format (that is, four classes are provided). Assume that in addition 353 to carrying best effort traffic, this link is carrying four guaranteed 354 service flows, A, B, C, D, and E. Further assume that the link capacity 355 is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic 356 is sufficient to keep the pipe full at all times and that GS flows A-E 357 are each 10kbit/s and all have delay bounds of 145ms. 359 Time(ms) Action 360 0 BE traffic is queued up 361 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 362 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 363 9 8kbit packet from flow A arrives 364 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 365 11 8kbit packet from flow B arrives 366 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 367 13 8kbit packets from flows C, D, and E arrive 368 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 369 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 370 18 2kbit fragment from A sent, cls 1 371 20 2kbit fragment from B sent, cls 2 372 22 2kbit fragment from A sent, cls 1 373 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 374 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 375 27 8kbit packet from flow A arrives 376 28 2kbit fragment from B sent, cls 2 377 30 2kbit fragment from C sent, cls 3 378 32 2kbit fragment from E sent, cls 1 379 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 380 36 2kbit fragment from E sent, cls 1 381 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 382 (etc.) 384 This example shows several things. First, multiple flows may share the 385 same class, particularly in the case where there are more flows than 386 classes. More importantly, there is no reason that a particular flow 387 must be assigned to a fixed class - the only requirement is that a each 388 packet, when fragmented, must have the same class value assigned to all 389 fragments. 391 One suggestion to implementers of integrated services on MCML and RTF 392 links is that all BE traffic may be logically separated from QoS traffic, 393 and mapped to a fragmentable (MCML classes 0-3 in short sequence number 394 fragment format, 0-15 in long sequence number fragment format) or 395 suspendable (RTF classes 0-6) class. Since BE traffic will in most 396 implementations not be scheduled for transmission except when a link 397 is empty (that is, no CL or GS traffic is ready for transmission), it 398 is possible to recommend use of class number 0 for BE traffic. 400 Treatment of non-conformant QoS traffic is a policy and implementation 401 issue. It is recommended that policing of flows containing non- 402 conformant traffic always be done at the level of granularity of 403 individual packets rather than at a finer grained level. In 404 particular, network elements scheduling flows for transmission 405 that drop non-conformant traffic should drop entire packets rather 406 than dropping individual fragments of packets belonging to non- 407 conformant traffic. For those network elements whose implementation 408 allows forwarding of non-conformant traffic when link bandwidth is 409 available rather than dropping the traffic, the implementation should 410 fragment packets of such traffic to the smallest MTU of all 411 admitted CL flows so as to ensure that CLmDELAY targets are met. 413 Whether BE and traffic are treated differently in regards to transmission 414 (e.g., BE is given priority access over non-conformant traffic to the 415 link) or whether within each type of traffic special treatment is 416 afforded to individual flows (e.g., WFQ, RED, etc.) is implementation 417 dependent. 419 In the case where fewer reservations are expected than the total number 420 of classes negotiated for a PPP link, it is possible to assign 421 individual flows to fixed class numbers. This assignment is useful in 422 the case where the protocol identifier associated with one or more 423 flows is known at LCP negotiation time and the bandwidth of the 424 connection is relatively small. If these conditions hold true, then for 425 those flows that are known, a specific class can optionally be assigned 426 to them and the prefix elision PPP option can be used for those classes 427 to achieve a small bandwidth savings. 429 5. Invocation Information 431 To invoke Controlled Load and Guaranteed Services, both traffic 432 characteristics and the flow itself must be identified to the Network 433 Element. Several methods can be employed to identify the flows. For 434 RSVP, classification can be used to identify the flows. For non-RSVP 435 implementations, other mechanisms have been described such as the 436 FlowID field in IP Version 6 and the TOS field in IP version 4. 438 If the Network Service Element is running on a system that doesn't 439 support application or proxy use of the TOS or FlowID fields, then 440 classification must be applied and: 442 As described in [4], Controlled Load Service is invoked by specifying 443 the flow's traffic characteristics through a TSpec (see [5]). 445 As described in [5], Guaranteed Service is invoked by specifying the 446 flow's TSpec and a requested reservation via an RSpec (see [6]). 448 6. Exported Information 450 For Controlled Load Service, there is no requirement to export 451 information. 453 For Guaranteed service, both C and D terms for delay computations must 454 be made available for export through the Adspec or other means. See 455 Sections 9.1 (Admission Control) for guidelines on computing the C and D 456 terms. 458 See [4] and [5] for additional information on Exported Information. 460 7. Ordering and Merging 462 Refer to [4] and [5] for TSpec and RSpec ordering and merging 463 guidelines. 465 8. Guidelines for Implementors 467 8.1. PPP Bit and Byte Stuffing Effects on Admission Control 469 An important consideration in performing admission control for PPP 470 links is reductions in effective link rate due to bit stuffing. Typical 471 bit stuffing algorithms can result in as much as 20% additional 472 overhead. Thus, admission control implementations for guaranteed 473 service over links where bit stuffing is used should take the RSpec 474 rate of all flows and multiply by 1.2 in determining whether a new flow 475 can be admitted or not. Admission control implementations for 476 controlled load reservations may use a similar algorithm using the 477 TSpec peak rate or may attempt to measure the actual degree of 478 expansion occurring on a link due to bit stuffing. This 479 characterization can then be used to adjust the calculated remaining 480 link capacity. Such measurements must be used cautiously, in that the 481 degree of bit stuffing that occurs may vary significantly, both in an 482 inter- and intra-flow fashion. 484 Byte stuffing is also used on many PPP links, most frequently on POTS 485 modems when using the v.42 protocol. Byte stuffing poses a difficult 486 problem to admission control, particularly in the case of guaranteed 487 service, due to its highly variable nature. In the worse case, byte 488 stuffing can result in a doubling of frame sizes. As a consequence, a 489 strict implementation of admission control for guaranteed load on byte 490 stuffed PPP links should double the RSpec of link traffic in making 491 flow admission decisions. As with bit stuffing, implementations of 492 controlled load service admission control algorithms for links with 493 byte stuffing may attempt to determine average packet expansion via 494 observation or may use the theoretical worst case values. 496 8.2. Compression Considerations 498 The architecture for providing integrated services over low bandwidth 499 links uses several PPP options to negotiate link configuration as 500 described in [4, 8]. When deciding whether to admit a flow, Admission 501 Control must compute the impact of the following on MTU size, rate, 502 and fragment size: 504 Header compression: Van Jacobson or Casner-Jacobson. 505 Prefix Elision. 506 CCP. 507 CRTP. 508 Fragment header option used. 509 Fragmentation versus suspend/resume approach. 511 If any of the compression options are implemented for the connection, 512 the actual transmission rate, and thus the bandwidth required of the 513 link, will be reduced by the compression method(s) used. 515 Prefix elision can take advantage of mapping flows to MLPPP classes 516 to elide prefixes which cannot be compressed at higher layers. By 517 establishing agreement across the link, the sender may elide a prefix for 518 a certain class of traffic and upon receiving packets in that class, the 519 receiver can restore the prefix. 521 Both compression gain and elision gain must be included as described in 522 the admission control section below. 524 8.3. Admission Control 526 Admission Control must decide whether to admit a flow based on rate and 527 delay. Assume the following: 529 LinkRate is the rate of the link. 530 MTU is the maximum transmission unit from a protocol. 531 MRU is the maximum receive unit for a particular link. 533 CMTU is the maximum size of the MTU after compression is applied. 534 eMTU is the maximum effective size of the MTU after fragmentation. 535 FRAG is the fragment size including MLPPP header/trailers. 536 Header is the size of the header/trailers/framing for MLPPP/Fragments. 537 pHeader is the additional header/framing overhead associated with 538 suspend/resume. This should include FSE and worst case stuffing 539 overhead. 540 pDelay is the delay associated with suspend/resume packets. 541 b is the bucket depth in bytes 542 R is the requested Rate. 543 D is the fixed overhead delay for the link (Modem, DSU, etc). 544 C is the delay associated with transmission and fragmentation. 545 eRate is the effective rate after compression and fragmentation. 547 The D term may be configured by an administrative tool once the network 548 is installed; it may be computed using the Adspec or other real-time 549 measurement means; or it may be available from hardware during link 550 setup and/or PPP negotiation. Refer to Appendix A for more 551 considerations on PPP link characteristics and delays. 553 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 554 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 555 Service: 557 To determine whether the requested rate is available, Admission Control 558 must compute the effective rate of the request (eRate) - worst case - as 559 follows: 561 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 563 eMTU = (#_of_Fragments) * FRAG 565 eRate = eMTU/CMTU * R 567 Admission Control should compare the eRate of the request against the 568 remaining bandwidth available to determine if the requested rate can be 569 delivered. 571 For Controlled Load Service, a flow can be admitted as long as there is 572 sufficient bandwidth available (after the above computation) to meet the 573 rate requirement, and if there is sufficient buffer space (sum of the 574 token bucket sizes does not exceed the buffer capacity). While some 575 statistical multiplexing could be done in computing admissibility, the 576 nature of the low-bitrate links could make this approach risky as any 577 delay incurred to address a temporary overcommitment could be difficult 578 to amortize. 580 Guaranteed Service requires delay computations. These computation are 581 based on the standard formula for delay: 583 Delay = b/R + C/R + D 584 Note that for suspend/resume, an additional term is required: 586 pDelay = b/R + C/R + D + pHeader/R. 588 This term exists because of the additional overhead associated with the 589 suspend/resume headers created when suspending a packet. In the worse 590 case, every transmission of a QoS packet could require suspension of a 591 best effort packet and thus incur the overhead. In most networks, this 592 term will be nominal at most. However, on some low-bitrate links, the 593 overhead may be worth computing. 595 Since MLPPP includes fragmentation, the C term is not fixed and must be 596 represented by the worse case fragmentation as computed in the effective 597 MTU size: 599 C = eMTU. 601 Note that because the links under consideration are point to point, 602 Guaranteed Service can be offered over a link without any 603 negotiated agreement from the next hop. However, if these services 604 are used in conjunction with RSVP, the C and D values above should be 605 used in the Adspec. 607 8.4. Fragment Scheduling Considerations 609 As described in Section 4, large packets should be fragmented to a size 610 sufficiently small to allow higher priority flows to get a hold of the 611 line quickly enough to not violate their reservation constraints. As 612 such, the upper bound for fragment sizes should be no larger than the 613 smallest MTU of all QoS flows. While a very small fragment size 614 is desirable from the point of view of meeting QoS deadlines, the 615 overhead associated with highly granular fragmentation makes it 616 necessary to strike a balance between these considerations. While this 617 document will not specify a particular scheduling algorithm, the 618 following example should help illustrate the issue: 620 Assume we have three different priority flows, A, B, and C. 621 Packets from flow C take 100ms, flow B takes 30ms, and flow A takes 30ms 622 to transmit. B's required maximum latency is 70ms, while A's is 50ms. 623 The above scenario results in flows B and C needing to be segmented 624 into 20ms long fragments - that way a lower priority frame will hold 625 the link at most 20ms before A gets to the link, taking another 626 30ms to transit, totaling 50ms - all well and good. B has a 627 problem, however - in the scenario where a fragment from C is just 628 starting to transmit the link when packets from A and B arrive (call 629 this time 0). The fragment from C will transmit until time 20ms. 630 After that, the A packet will transmit - finishing by time 50ms, 631 just in time. At this point, the fragment from B starts to 632 transmit - taking 30ms more, finishing by time 80ms (thus violating 633 its reservation). 635 The important point above the scenario is not that it is possible 636 to overcommit a link, but that a link can be underutilized 637 by using too large a fragment size - in the above case, a 10ms 638 fragment size would have allowed both A and B to honor their 639 reservations, a 20ms size does not. 641 9. Evaluation Criteria 643 For Controlled Load Service, the network element must ensure that 644 the service requested via the TSpec is delivered to the requesting QoS 645 flow such that the PPP link appears to be a lightly loaded link. 647 As a baseline, it is suggested that performance measurements on 648 throughput, delay, and packet error measurements be performed on an 649 unloaded link with just the QoS flow using various packet sizes. The 650 baseline should measure performance for both conformant and non- 651 conformant traffic when for overloading the link with a single flow. 652 Once these measurements are complete, measurements of the 653 Controlled Load Service should be performed as follows: 655 1) Request QoS flows in the presence of best effort traffic and ensure 656 that the QoS flows' performance approximate the unloaded baseline 657 measurements. 659 2) Request QoS flows whose aggregate throughput would exceed the link 660 capacity. Admission Control should deny these service requests or admit 661 them as best effort only. 663 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. 664 Ensure recovery of the flow once the traffic becomes conformant. 666 For Guaranteed Service: 668 1) Ensure that Admission Control will deny service requests or convert 669 them to best effort when link capacity or delay bounds would be 670 exceeded. 672 2) On a best-efforts loaded link, ensure that the number of lost packets 673 does not exceed those established in the baseline measurements. 675 3) On a best-efforts loaded link, ensure that delay and rate commitments 676 can be met for QoS flows. 678 4) With multiple QoS flows, ensure that an admission of additional QoS 679 flows does not cause a violation in rate, error rate, or delay 680 constraints of any QoS flow. 682 10. Security Considerations 684 General security considerations for MLPPP and PPP links are 685 addressed in RFC 1990 and RFC 1661, respectively. Security 686 considerations relevant to RSVP, used as the signaling protocol 687 for integrated services, are discussed in RFC 2209. 689 A specific security consideration relevant to providing quality 690 of service over PPP links appears when relying on either observed 691 or theoretical average packet expansion during admission control 692 due to bit- or byte-stuffing. Implementations based on these 693 packet-expansion values contain a potential vulnerability to 694 denial of service attacks. An adversary could intentionally send 695 traffic that will result in worst case bit- or byte stuffing 696 packet expansion. This in turn could result in quality of service 697 guarantees not being met for other flows due to overly permissive 698 admission control. This potential denial of service attack 699 argues strongly for using a worst case expansion factor in 700 admission control calculations, even for controlled load service. 702 Beyond the considerations documented above, this document introduces 703 no new security issues on top of those discussed in the companion 704 ISSLL documents [5] and [10]. Any use of these service mappings 705 assumes that all requests for service are authenticated 706 appropriately. 708 11. References 710 [1] C. Bormann, ``Providing integrated services over low-bitrate 711 links'', Work in Progress (draft-ietf-issll-isslow-04.txt), 712 August 1998. 714 [2] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 715 Work in Progress (draft-ietf-issl-isslow-mcml-04.txt), 716 August 1998. 718 [3] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 719 Work in Progress (draft-ietf-issl-isslow-rtf-03.txt), 720 August 1998. 722 [4] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 723 Low-Speed Serial Links'', Work in Progress (draft-ietf-avt- 724 crtp-05.txt), July 1998. 726 [5] J. Wroclawski, ``Specification of the Controlled-Load Network 727 Element Service'', RFC 2211, September 1997. 729 [6] C. Partridge, R. Guerin, ``Specification of Guaranteed Quality 730 of Service'', RFC 2212, September 1997. 732 [7] S. Shenker, J. Wroclawski, ``General Characterization Parameters 733 for Integrated Service Network Elements'', RFC 2215, 734 September 1997. 736 [8] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," 737 RFC 1144. 739 12. Authors' Addresses: 741 Steve Jackowski 742 Deterministic Networks, Inc. 743 245M Mt Hermon Rd, #140 744 Scotts Valley, CA 95060 745 stevej@DeterministicNetworks.com 746 (408)813-6294 748 David Putzolu 749 Intel Architecture Labs (IAL) 750 JF3-206-H10 751 2111 NE 25th Avenue 752 Hillsboro, OR 97124-5961 753 David.Putzolu@intel.com 754 (503) 264-4510 756 Acknowledgements 758 This document draws heavily on the work of the ISSLL WG of the IETF. 760 Appendix A. Admission Control Considerations for POTS Modems 762 The protocols used in current implementations of POTS modems can 763 exhibit significant changes in link rate and delay over the duration of 764 a connection. Admission control and link scheduling algorithms used 765 with these devices must be prepared to compensate for this variability 766 in order to provide a robust implementation of integrated services. 768 Link rate on POTS modems is typically reported at connection time. This 769 value may change over the duration of the connection. The v.34 770 protocol, used in most POTS modems, is adaptive to link conditions, and 771 is able to recalibrate transmission rate multiple times over the 772 duration of a connection. Typically this will result in a small (~10%) 773 increase in transmission rate over the initial connection within the 774 first minute of a call. It is important to note, however, that other 775 results are possible as well, including decreases in available 776 bandwidth. Admission control algorithms must take such changes into 777 consideration as they occur, and implementations must be able to 778 gracefully handle the pathological case where link rate actually drops 779 below the currently reserved capacity of a link. 781 Delay experienced by traffic over POTS modems can vary significantly 782 over time. Unlike link rate, the delay often does not converge to a 783 stable value. The v.42 protocol is used in most POTS modems to provide 784 link-layer reliability. This reliability, which is implemented via 785 retransmission, can cause frames to experience significant delays. 786 Retransmissions also implicitly steal link bandwidth from other 787 traffic. These delays and reductions in link bandwidth make it 788 extremely difficult to honor a guaranteed service reservation. On a 789 link that is actually lightly or moderately loaded, a controlled load 790 service can to some extent accept such events as part of the behavior 791 of a lightly loaded link. Unfortunately, as actual link utilization 792 increases, v.42 retransmissions have the potential of stealing larger 793 and larger fractions of available link bandwidth; making even 794 controlled load service difficult to offer at high link utilization 795 when retransmissions occur.