idnits 2.17.1 draft-ietf-issll-isslow-svcmap-04.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-03-29) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 3) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 55 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 118 has weird spacing: '...w), the admis...' == Line 122 has weird spacing: '... leased line....' == Line 390 has weird spacing: '...lues to apply...' == Line 554 has weird spacing: '...equires delay...' == Line 625 has weird spacing: '...hen for overl...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Nov 1998) is 9266 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 (~~), 8 warnings (==), 5 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-issll-isslow-svcmap-04.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), ds.internic.net (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 The ISSLOW subgroup of the ISSL working group has focused on defining 80 mechanisms to permit flow differentiation and QoS capabilities for mixed 81 traffic over low speed links. This has been accomplished through a 82 series of extensions to the PPP protocol which permit fragmentation 83 and/or suspension of large packets in favor of packets on flows which 84 require QoS. These protocol extensions are presented in [1] and [2]. 86 This document describes the service mapping required to implement the 87 controlled load and guaranteed services over these PPP protocol 88 extensions. It is modeled on the Network Element Service Specification 89 Template described in [3]. It is assumed that the ISSLOW Network 90 Element is one portion of a PPP service available to the system. 92 2. End-to-end Behavior 94 Unlike many of the other specific link layers addressed in the ISSL 95 working group, ISSLOW operates only over low speed point to point links 96 or connections. Examples of these links include dial up lines, ISDN 97 channels, and leased lines. As such, 'end to end' simply means between 98 two points. In today's inter/intranet environment, this will include: 100 - host to directly connected host. 101 - host to/from network access device (router or switch). 102 - Edge device (subnet router or switch) to/from router or switch. 103 - In rare circumstances, the link may run from backbone router to 104 backbone router. 106 Thus, the endpoints are two network elements as described above. The 107 Controlled Load and Guaranteed services for ISSLOW links are applied on 108 the link between these elements and often represent the first or last 109 wide area hop in a true end to end service. It is important to note 110 that these links tend to be the most 'bandwidth constrained' along the 111 path. 113 ISSLOW services are only provided if both endpoints on the link support 114 ISSLOW. This is determined during the PPP negotiation. Because of the 115 unique characteristics of a point to point link with both endpoints 116 supporting ISSLOW, traffic is automatically shaped. That is, incoming 117 traffic will be TSpec conformant, and except for some special 118 considerations for Guaranteed Service (below), the admission control 119 function can make decisions based on local state: it does not need to 120 coordinate with the network element on the other end of the link. As 121 described in [5], Guaranteed Service should approximate the 122 functionality of a leased line. Since ISSLOW runs over point to point 123 links, when rate control and delay bounds are provided for individual 124 flows, the link inherently acts like a leased circuit. 126 Thus, even for Guaranteed Service, because this hop is the most 127 bandwidth constrained, and because the connection is dual simplex 128 (e.g., not a shared link for send & receive), all admission control 129 decisions can be made locally. 131 3. Motivation 133 Previous sections described the motivation for the ISSLOW capabilities. 134 Dial up users are now treating their relatively low-bitrate connections 135 as they would a higher speed connection. They are mixing multiple flows 136 of data and expect performance similar to what they see in a LAN 137 environment. However, it is deployment of realtime applications which 138 is the primary motivation for hosts to implement Integrated Services. 140 Realtime applications typically have tight delay constraints to achieve 141 consistent performance, requiring small packets. When these are 142 mixed with flows consisting of large packets (e.g. HTTP, FTP), delay 143 variance increases and absolute delay suffers as these small packets 144 wait in the queue behind even a single large packet being transmitted on 145 the link. Because of the jitter tolerance and adaptive nature of many 146 modern realtime applications, just providing a controlled load 147 service would satisfy most of the needs of this class of applications. 149 Another consideration in handling of packets over low speed links occurs 150 when looking at the end-to-end issues. The low speed link is 151 usually just one hop on a longer path between endpoints. As such, it is 152 usually the limiting factor in performance. While this needs to be 153 considered in the host to router configuration, it becomes more critical 154 between edge devices and backbone routers where there is a multiuser 155 subnet as source and destination for traffic and a low-bitrate link to 156 the router. To ensure some performance bounds end-to-end, guaranteed 157 service should be considered over these links even if it cannot be 158 offered end to end in the network. 160 4. Network Element Data Handling Requirements 162 The ISSLOW Network Service element may be implemented in hardware or 163 software. As described in [1] and [2], for systems which can perform 164 bit-oriented transmission control, the suspend/resume approach optimizes 165 the available bandwidth by minimizing header overhead associated with 166 MLPPP fragmentation. For systems which provide frame-oriented 167 transmission control, the fragmentation approach can be implemented with 168 no hardware changes. Choice of suspend/resume versus fragmentation 169 should be made based on the hardware's capability to handle the new HDLC 170 framing described in [1] and the system overhead associated with byte by 171 byte scanning (required by suspend/resume). 173 To provide controlled load or guaranteed service with the suspend/resume 174 approach, when a packet for an IntServ admitted flow (QoS packet) 175 arrives during transmission of a best effort packet and continued 176 transmission of the best effort packet would violate delay constraints 177 of the QoS service flows, the best effort packet is preempted, the QoS 178 packet/fragments are added to the transmission, and the best effort 179 packet transmission is then resumed: usually all in one transmission. 180 The receiving station separates the best effort packet from the embedded 181 QoS fragments. It is also conceivable that one IntServe Flow's packet 182 might suspend another flow's packet if the delivery deadline of the new 183 packet is earlier than the current packet. 185 For systems which use fragmentation, since suspend/resume is not 186 possible, all packets longer than the maximum tolerable delay for an 187 IntServ packet are fragmented prior to transmission so that a short 188 packet for another flow can be interleaved between fragments of a large 189 packet and still meet the transmission deadline for the IntServ flow. 191 Note that the fragmentation discussed in this document refers to 192 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 193 as described in [1], not IP or other layer 3 fragmentation. MLPPP 194 fragmentation is local to the PPP link, and does not affect end-to-end 195 (IP) MTU. 197 4.01 Rate and Delay 199 ISSLOW assumes that the nature of point to point links is such that 200 rate, transmission time and delay are fixed and consistent. The rate of 201 the link is determined at connection time, and the devices on the link 202 (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. 203 Unfortunately this is not always true. 205 POTS modems can have varying rates, but the rate for a particular 206 POTS modem connection tends to converge over time to a particular 207 value as the modems adjust to line conditions. Implementations 208 may need to adjust their admission control policies to reflect 209 this convergence. Refer to Appendix A for more considerations 210 on link characteristics and associated delay. 212 4.02 Link Aggregation 214 Although certain link types, like ISDN, permit dynamic allocation of 215 Bandwidth across multiple links, it is assumed that the Admission 216 Control service will consider the impact of multiple physical links over 217 the point to point logical connection. 219 Note that because of the load balancing effect of Multilink PPP (MLPPP), 220 two 64 Kbps links should exhibit the delay and transmission 221 characteristics of a single 128 Kbps link. However, MLPPP 222 implementations may approach load balancing and fragmentation 223 differently. The mechanism used should be taken into consideration when 224 implementing the scheduler (especially token bucket) for packets, 225 fragments, and suspend/resume on top of existing MLPPP services to 226 ensure that adequate rate and delay characteristics are maintained. 228 4.1 Controlled Load versus Guaranteed Service 230 With most link layers, Guaranteed Service requires more tightly 231 controlled service by the Network Element, and in most cases, acceptance 232 of a Guaranteed Service request results in over-provisioning of link 233 level resources. Controlled Load (CL) Service is usually less 234 constrained and permits more flexibility in scheduling of packets for 235 the link. 237 Controlled Load requires that the delay associated with packet 238 transmission be 'closely equivalent to unloaded best effort service.' 239 Because ISSLOW operates over point to point links, unloaded best effort 240 service means that best effort packets will incur no more than burst 241 packet delay: M/r where M is the maximum packet size and r is the 242 transmission rate. Thus maximum permitted delay for a Controlled Load 243 packet (CLmDELAY) is bounded by M/r + P/r where P is the size of the 244 outgoing packet. 246 4.2 Controlled Load and Guaranteed Service Data Handling 248 Upon arrival of a QoS flow's packet, the ISSLOW Network Element 249 determines if the packet is conformant. If it is not, Policing is 250 applied (see Policing). Conformant means: 252 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 253 for Guaranteed Service: rT+b with T=time period). 254 2) The packet does not cause a token bucket overflow. 256 If the packet is conformant, it is compressed as required, fragmented 257 (if necessary), and scheduled. If there is no conflicting best effort 258 traffic, the packet is queued along with the rest of conformant QoS 259 traffic and scheduled with respect to any other IntServ flows such that 260 its transmission deadline is met. 262 For the suspend/resume implementation to achieve controlled load, any 263 packets being transmitted whose transmission would violate 264 the CLmDELAY are suspended. Otherwise, the QoS packet/fragments are 265 scheduled ahead of any queued best effort traffic. 267 For CL Fragmentation implementations, the packet/fragment is scheduled 268 ahead of any best effort packets. Note that all best effort packets 269 must be divided into fragments less than or equal to the smallest MRU 270 (or associated fragment size) of all the QoS flows. This incurs at 271 most one fragment delay for the QoS traffic: closely equivalent to 272 unloaded best effort service. 274 For Guaranteed Service for both fragmentation and suspend/resume, the 275 scheduler determines if continued transmission of the best effort packet 276 being transmitted would cause delay greater than the acceptable delay. 277 If so, the best effort packet is preempted or, in the case of 278 fragmentation, the QoS packet is scheduled ahead of the rest of the 279 best effort packets' fragments. 281 4.3 Controlled Load and Guaranteed Service Class Mappings 283 Supporting integrated services over PPP links which implement MCML or 284 RTF can be accomplished in several ways. Guidelines for mapping these 285 services to PPP links are presented below. Note that these guidelines 286 assume that some sort of signaling is used to indicate desired quality 287 of service to both the sender and receiver of a flow over a PPP link. 288 These guidelines also assume that it is unlikely that a series of PPP 289 links be connected to each other. It is noted that even if a series of 290 PPP links were to be connected together, it is likely that each link 291 would have different characteristics, and further, that frames would 292 have to be reassembled at the terminus of each link for error 293 correction purposes, requiring that class assignment be performed on 294 each hop of the link, rather than just forwarding frames with 295 identical segmentation or fragmentation. These assumptions remove any 296 requirement on the service-mapping implementation that quality of 297 service information be implicit in the class selection applied to 298 particular flows, allowing the sender of an integrated services flow on 299 a PPP link complete freedom in assigning classes to flows (or packets 300 within flows). 302 One important observation that must be made is that the classes that 303 MCML and RTF provide can be viewed purely as PPP-specific 304 segmentation/fragmentation mechanisms. That is, while the class number 305 must remain constant on an intra-packet basis, it may vary on an inter- 306 packet basis for all flows transiting a PPP link. Actual assignment of 307 particular flows to fixed classes is unnecessary, as the class numbers 308 are not required to have any meaning other than in the context of 309 identifying the membership of fragments/segments as part of a single 310 packet. This consideration is very important, in that it offers 311 implementers with a large degree of flexibility in providing integrated 312 services over PPP links. This observation implies that the queuing 313 discipline used to differentiate different flows does not have any ties 314 to the class numbers used. This point is sufficiently important that an 315 example is provided below. 317 Consider a PPP link using the MCML short sequence number fragment 318 format (that is, four classes are provided). Assume that in addition 319 to carrying best effort traffic, this link is carrying four guaranteed 320 service flows, A, B, C, D, and E. Further assume that the link capacity 321 is 100kbit/s and the latency is 100ms. Finally, assume the BE traffic 322 is sufficient to keep the pipe full at all times and that GS flows A-E 323 are each 10kbit/s and all have delay bounds of 145ms. 325 Time(ms) Action 326 0 BE traffic is queued up 327 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 328 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 329 9 8kbit packet from flow A arrives 330 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 331 11 8kbit packet from flow B arrives 332 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 333 13 8kbit packets from flows C, D, and E arrive 334 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 335 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 336 18 2kbit fragment from A sent, cls 1 337 20 2kbit fragment from B sent, cls 2 338 22 2kbit fragment from A sent, cls 1 339 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 340 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 341 27 8kbit packet from flow A arrives 342 28 2kbit fragment from B sent, cls 2 343 30 2kbit fragment from C sent, cls 3 344 32 2kbit fragment from E sent, cls 1 345 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 346 36 2kbit fragment from E sent, cls 1 347 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 348 (etc.) 350 This example shows several things. First, multiple flows may share the 351 same class, particularly in the case where there are more flows than 352 classes. More importantly, there is no reason that a particular flow 353 must be assigned to a fixed class - the only requirement is that a each 354 packet, when fragmented, must have the same class value assigned to all 355 fragments. 357 One suggestion to implementers of integrated services on MCML and RTF 358 links is that all BE and non-conformant traffic be logically separated 359 from conformant traffic, and mapped to a fragmentable (MCML classes 0-3 360 in short sequence number fragment format, 0-15 in long sequence number 361 fragment format) or suspendable (RTF classes 0-6) class. Since BE and 362 non-conformant traffic will in most implementations not be scheduled 363 for transmission except when a link is empty (that is, no CL or GS 364 traffic is ready for transmission), it is possible to recommend use of 365 class number 0 for BE/non-conformant traffic. Whether BE and non- 366 conformant traffic are treated differently in regards to transmission 367 (e.g., BE is given priority access over non-conformant traffic to the 368 link) or whether within each type of traffic special treatment is 369 afforded to individual flows (e.g., WFQ, RED, etc.) is implementation 370 dependent. 372 In the case where fewer reservations are expected than the total number 373 of classes negotiated for a PPP link, it is possible to assign 374 individual flows to fixed class numbers. This assignment is useful in 375 the case where the protocol identifier associated with one or more 376 flows is known at LCP negotiation time and the bandwidth of the 377 connection is relatively small. If these conditions hold true, then for 378 those flows that are known, a specific class can optionally be assigned 379 to them and the prefix elision PPP option can be used for those classes 380 to achieve a small bandwidth savings. 382 5. Invocation Information 384 To invoke Controlled Load and Guaranteed Services, both traffic 385 characteristics and the flow itself must be identified to the Network 386 Element. Several methods can be employed to identify the flows. For 387 RSVP, filtering can be used to identify the flows. For non-RSVP 388 implementations, mechanisms such as the FlowID field in IP Version 6, or 389 the TOS field in IP version 4 can be used. As described above, the 390 Network Element can then use the specified values to apply the 391 appropriate QoS and to map the flows to a particular class. 393 A number of major router and switch vendors currently support use of 394 the TOS bits to signal priority and class of service. As a result, 395 applications and host proxies have been developed to enable users and 396 network managers to apply policies requesting differential services via 397 TOS. Use of these bits is the easiest way to identify flows without 398 the overhead of filtering. 400 If the Network Service Element is running on a system that doesn't 401 support application or proxy use of the TOS or FlowID fields, then 402 filtering must be applied and: 404 As described in [4], Controlled Load Service is invoked by specifying 405 the flow's traffic characteristics through a TSpec (see [5]). 407 As described in [5], Guaranteed Service is invoked by specifying the 408 flow's TSpec and a requested reservation via an RSpec (see [6]). 410 6. Exported Information. 412 For Controlled Load Service, there is no requirement to export 413 information. 415 For Guaranteed service, both C and D terms for delay computations must 416 be made available for export through the Adspec or other means. See 417 Sections 9.1 (Admission Control) for guidelines on computing the C and D 418 terms. 420 See [4] and [5] for additional information on Exported Information. 422 7. Policing 424 Policing is applied to non-conformant QoS traffic and to best effort 425 traffic whose transmission would violate the Controlled Load or 426 Guaranteed Service constraints. This document does not designate a 427 specific packet scheduling implementation. Ideally, best effort traffic 428 can be serviced through separate queues and a weighted queuing mechanism, 429 or when a conflict with QoS traffic arises, best-efforts traffic can 430 simply be discarded. 432 Both Controlled Load and Guaranteed Services permit scheduling of non- 433 conformant traffic as well as the option to discard non-conformant 434 packets. See [4] and [5] for additional information on policing options 435 for Controlled Load and Guaranteed Services. 437 8. Ordering and Merging 439 Refer to [4] and [5] for TSpec and RSpec ordering and merging 440 guidelines. 442 9. Guidelines for Implementors 444 9.1. PPP Bit Stuffing and Byte Stuffing Effects on Admission Control 446 An important consideration in performing admission control for PPP 447 links is reductions in effective link rate due to bit stuffing. Typical 448 bit stuffing algorithms can result in as much as 20% additional 449 overhead. Thus, admission control implementations for guaranteed 450 service over links where bit stuffing is used should take the RSpec 451 rate of all flows and multiply by 1.2 in determining whether a new flow 452 can be admitted or not. Admission control implementations for 453 controlled load reservations may use a similar algorithm using the 454 TSpec peak rate or may attempt to measure the actual degree of 455 expansion occurring on a link due to bit stuffing. This 456 characterization can then be used to adjust the calculated remaining 457 link capacity. Such measurements must be used cautiously, in that the 458 degree of bit stuffing that occurs may vary significantly, both in an 459 inter- and intra-flow fashion. 461 Byte stuffing is also used on many PPP links, most frequently on POTS 462 modems when using the v.42 protocol. Byte stuffing poses a difficult 463 problem to admission control, particularly in the case of guaranteed 464 service, due to its highly variable nature. In the worse case, byte 465 stuffing can result in a doubling of frame sizes. As a consequence, a 466 strict implementation of admission control for guaranteed load on byte 467 stuffed PPP links should double the RSpec of link traffic in making 468 flow admission decisions. As with bit stuffing, implementations of 469 controlled load service admission control algorithms for links with 470 byte stuffing may attempt to determine average packet expansion via 471 observation or may use the theoretical worst case values. 473 9.2 Compression Considerations 475 The ISSLOW specification supports several PPP options. When deciding 476 whether to admit a flow, Admission Control must compute the impact of 477 the following on MTU size, rate, and fragment size: 479 Header compression: Van Jacobson or Casner-Jacobsen. 480 Prefix Elision. 481 CCP. 482 CRTP. 483 Fragment header option used. 484 Fragmentation versus suspend/resume approach. 486 If any of the compression options are implemented for the connection, 487 the actual transmission rate, and thus the bandwidth required of the 488 link, will be reduced by the compression method(s) used. 490 Prefix elision can take advantage of mapping flows to MLPPP classes 491 to elide prefixes which cannot be compressed at higher layers. By 492 establishing agreement across the link, the sender may elide a prefix for 493 a certain class of traffic and upon receiving packets in that class, the 494 receiver can restore the prefix. 496 Both compression gain and elision gain must be included as described in 497 the admission control section below. 499 9.3 Admission Control 501 Admission Control must decide whether to admit a flow based on rate and 502 delay. Assume the following: 504 LinkRate is the rate of the link. 505 MTU is the maximum transmission unit from a protocol. 506 MRU is the maximum receive unit for a particular link. 507 CMTU is the maximum size of the MTU after compression is applied. 508 eMTU is the maximum effective size of the MTU after fragmentation. 509 FRAG is the fragment size including MLPPP header/trailers. 510 Header is the size of the header/trailers/framing for MLPPP/Fragments. 511 pHeader is the additional header/framing overhead associated with 512 suspend/resume. This should include FSE and worst case stuffing 513 overhead. 514 pDelay is the delay associated with suspend/resume packets. 515 b is the bucket depth in bytes 516 R is the requested Rate. 517 D is the fixed overhead delay for the link (Modem, DSU, etc). 518 C is the delay associated with transmission and fragmentation. 519 eRate is the effective rate after compression and fragmentation. 521 The D term may be configured by an administrative tool once the network 522 is installed; it may be computed using the Adspec or other realtime 523 measurement means; or it may be available from hardware during link 524 setup and/or PPP negotiation. Refer to Appendix A for more 525 considerations on PPP link characteristics and delays. 527 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 528 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 529 Service: 531 To determine whether the requested rate is available, Admission Control 532 must compute the effective rate of the request (eRate) - worst case - as 533 follows: 535 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 537 eMTU = (#_of_Fragments) * FRAG 539 eRate = eMTU/CMTU * R 541 Admission Control should compare the eRate of the request against the 542 remaining bandwidth available to determine if the requested rate can be 543 delivered. 545 For Controlled Load Service, a flow can be admitted as long as there is 546 sufficient bandwidth available (after the above computation) to meet the 547 rate requirement, and if there is sufficient buffer space (sum of the 548 token bucket sizes does not exceed the buffer capacity). While some 549 statistical multiplexing could be done in computing admissibility, the 550 nature of the low-bitrate links could make this approach risky as any 551 delay incurred to address a temporary overcommitment could be difficult 552 to amortize. 554 Guaranteed Service requires delay computations. These computation are 555 based on the standard formula for delay: 557 Delay = b/R + C/R + D 559 Note that for suspend/resume, an additional term is required: 561 pDelay = b/R + C/R + D + pHeader/R. 563 This term exists because of the additional overhead associated with the 564 suspend/resume headers created when suspending a packet. In the worse 565 case, every transmission of a QoS packet could require suspension of a 566 best effort packet and thus incur the overhead. In most networks, this 567 term will be nominal at most. However, on some low-bitrate links, the 568 overhead may be worth computing. 570 Since MLPPP includes fragmentation, the C term is not fixed and must be 571 represented by the worse case fragmentation as computed in the effective 572 MTU size: 574 C = eMTU. 576 Note that because ISSLOW runs on point to point links, Guaranteed 577 Service can be offered over a link without any negotiated agreement from 578 the next hop. However, if these services are used in conjunction with 579 RSVP, the C and D values above should be used in the Adspec. 581 9.4 Fragment Scheduling Considerations 583 As described in Section 4, large packets should be fragmented to a size 584 sufficiently small to allow higher priority flows to get a hold of the 585 line quickly enough to not violate their reservation constraints. As 586 such, the upper bound for fragment sizes should be no larger than the 587 smallest MTU of all QoS flows. While a very small fragment size 588 is desirable from the point of view of efficient link utilization, the 589 overhead associated with highly granular fragmentation makes it 590 necessary to strike a balance between these considerations. While this 591 document will not specify a particular scheduling algorithm, the 592 following example should help illustrate the issue: 594 Assume we have three different priority flows, A, B, and C. 595 Packets from flow C take 100ms, flow B takes 30ms, and flow A takes 30ms 596 to transmit. B's required maximum latency is 70ms, while A's is 50ms. 597 The above scenario results in flows B and C needing to be segmented 598 into 20ms long fragments - that way a lower priority frame will hold 599 the link at most 20ms before A gets to the link, taking another 600 30ms to transit, totaling 50ms - all well and good. B has a 601 problem, however - in the scenario where a fragment from C is just 602 starting to transmit the link when packets from A and B arrive (call 603 this time 0). The fragment from C will transmit until time 20ms. 604 After that, the A packet will transmit - finishing by time 50ms, 605 just in time. At this point, the fragment from B starts to 606 transmit - taking 30ms more, finishing by time 80ms (thus violating 607 its reservation). 609 The important point above the scenario is not that it is possible 610 to overcommit a link, but that a link can be underutilized 611 by using too large a fragment size - in the above case, a 10ms 612 fragment size would have allowed both A and B to honor their 613 reservations, a 20ms size does not. 615 10. Evaluation Criteria 617 For Controlled Load Service, the ISSLOW network element must ensure that 618 the service requested via the TSpec is delivered to the requesting QoS 619 flow such that the PPP link appears to be a 'lightly loaded link. 621 As a baseline, it is suggested that performance measurements on 622 throughput, delay, and packet error measurements be performed on an 623 unloaded link with just the QoS flow using various packet sizes. The 624 baseline should measure performance for both conformant and non- 625 conformant traffic when for overloading the link with a single flow. 626 Once these measurements are complete, measurements of the 627 Controlled Load Service should be performed as follows: 629 1) Request QoS flows in the presence of best effort traffic and ensure 630 that the QoS flows' performance approximate the unloaded baseline 631 measurements. 633 2) Request QoS flows whose aggregate throughput would exceed the link 634 capacity. Admission Control should deny these service requests or admit 635 them as best effort only. 637 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. 638 Ensure recovery of the flow once the traffic becomes conformant. 640 For Guaranteed Service: 642 1) Ensure that Admission Control will deny service requests or convert 643 them to best effort when link capacity or delay bounds would be 644 exceeded. 646 2) On a best-efforts loaded link, ensure that the number of lost packets 647 does not exceed those established in the baseline measurements. 649 3) On a best-efforts loaded link, ensure that delay and rate commitments 650 can be met for QoS flows. 652 4) With multiple QoS flows, ensure that an admission of additional QoS 653 flows does not cause a violation in rate, error rate, or delay 654 constraints of any QoS flow. 656 11. Security Considerations 658 General security considerations for PPP links are 659 addressed elsewhere. A specific security consideration relevant to 660 providing quality of service over PPP links appears when relying 661 on either observed or theoretical average packet expansion 662 during admission control due to bit- or byte-stuffing. 663 Implementations based on these packet-expansion values 664 contain a potential vulnerability to denial of service attacks. 665 An adversary could intentionally send traffic that will result in worst 666 case bit- or byte stuffing packet expansion. This in turn could result 667 in quality of service guarantees not being met for other flows due to 668 overly permission admission control. This potential denial of service 669 attack argues strongly for using a worst case expansion factor in 670 admission control calculations, even for controlled load service. 672 12. References 674 [1] C. Bormann "The Multi-Class Extension to Multilink PPP" 675 Internet Draft, July 1997, 677 [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" 678 Internet Draft, July 1997, 680 [3] rfc2216 -- Network Element Service Specification Template. S. 681 Shenker, J. Wroclawski. September 1997 683 [4] rfc2211 -- Specification of the Controlled-Load Network 684 Element Service. J. Wroclawski. September 1997 686 [5] rfc2212 -- Specification of Guaranteed Quality of Service. S. 687 Shenker, C. Partridge, R. Guerin. September 1997 689 [6] rfc2215 -- General Characterization Parameters for Integrated 690 Service Network Elements. S. Shenker, J. Wroclawski. September 1997. 692 13 Author's Address: 694 Steve Jackowski 695 Deterministic Networks, Inc. 696 245M Mt Hermon Rd, #140 697 Scotts Valley, CA 95060 698 stevej@DeterministicNetworks.com 699 (408)813-6294 701 David M. Putzolu 702 Intel Architecture Labs (IAL) 703 JF3-206-H10 704 2111 NE 25th Avenue 705 Hillsboro, OR 97124-5961 706 David.Putzolu@intel.com 707 (503) 264-4510 709 Appendix A: Admission Control Considerations for POTS Modems 711 The protocols used in current implementations of POTS modems can 712 exhibit significant changes in link rate and delay over the duration of 713 a connection. Admission control and link scheduling algorithms used 714 with these devices must be prepared to compensate for this variability 715 in order to provide a robust implementation of integrated services. 717 Link rate on POTS modems is typically reported at connection time. This 718 value may change over the duration of the connection. The v.34 719 protocol, used in most POTS modems, is adaptive to link conditions, and 720 is able to recalibrate transmission rate multiple times over the 721 duration of a connection. Typically this will result in a small (~10%) 722 increase in transmission rate over the initial connection within the 723 first minute of a call. It is important to note, however, that other 724 results are possible as well, including decreases in available 725 bandwidth. Admission control algorithms must take such changes into 726 consideration as they occur, and implementations must be able to 727 gracefully handle the pathological case where link rate actually drops 728 below the currently reserved capacity of a link. 730 Delay experienced by traffic over POTS modems can vary significantly 731 over time. Unlike link rate, the delay often does not converge to a 732 stable value. The v.42 protocol is used in most POTS modems to provide 733 link-layer reliability. This reliability, which is implemented via 734 retransmission, can cause frames to experience significant delays. 735 Retransmissions also implicitly steal link bandwidth from other 736 traffic. These delays and reductions in link bandwidth make it 737 extremely difficult to honor a guaranteed service reservation. On a 738 link that is actually lightly or moderately loaded, a controlled load 739 service can to some extent accept such events as part of the behavior 740 of a lightly loaded link. Unfortunately, as actual link utilization 741 increases, v.42 retransmissions have the potential of stealing larger 742 and larger fractions of available link bandwidth; making even 743 controlled load service difficult to offer at high link utilization 744 when retransmissions occur.