idnits 2.17.1 draft-ietf-issll-isslow-svcmap-02.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-27) 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 6 longer pages, the longest (page 6) being 76 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 40 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 36 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 126 has weird spacing: '...w), the admis...' == Line 130 has weird spacing: '... leased line....' == Line 221 has weird spacing: '...ol will almos...' == Line 332 has weird spacing: '...lues to apply...' == Line 546 has weird spacing: '...equires delay...' == (1 more instance...) -- 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 (June 1998) is 9448 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-02.txt Deterministic Networks 4 D. Putzolu 5 Intel Architecture Labs 6 June 1998 7 Expires: 1/99 9 Network Element Service Specification for Low Speed Networks 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 This draft is a product of the Integrated Services Working Group of 30 the Internet Engineering Task Force. Comments are solicited and 31 should be addressed to the working group's mailing list at int- 32 serv@isi.edu and/or the author(s). 34 Abstract 36 This document defines the service mappings for controlled load and 37 guaranteed services over low-bitrate networks. These low-bitrate 38 networks typically include components such as analog phone lines, ISDN 39 connections and sub-T1 rate links. The document specifies the per- 40 network element packet handling behavior, parameters required, traffic 41 specification, policing requirements, and traffic ordering 42 relationships which are required to provide both Guaranteed and 43 Controlled Load service capabilities. It also includes evaluation 44 criteria for elements providing the service. 46 This document is a product of the IETF ISSL working group and is based 47 on [1] and [2] which describe modifications to the PPP protocol to 48 enable these services. 50 Table of Contents 52 1. Introduction 3 53 2. End to end Behavior 4 54 3. Motivation 5 55 4. Network Element Data Handling 5 56 4.01 Rate and delay 6 57 4.02 Link Aggregation 6 58 4.1 Controlled Load Versus Guaranteed Service 7 59 4.2 Controlled Load and Guaranteed Service Data Handling 7 60 4.3 Controlled Load and Guaranteed Service Class Mapping 8 61 5. Invocation Information 9 62 6. Exported Information 9 63 7. Policing 10 64 8. Ordering and Merging 10 65 9. Guidelines for Implementors 10 66 9.1 Bit and Byte Stuffing Considerations 10 67 9.2 Compression Considerations 11 68 9.3 Admission Control 12 69 9.4 Fragment Scheduling Considerations 13 70 10. Evaluation Criteria 14 71 11. Security Considerations 15 72 12. References 15 73 13. Authors' Addresses 15 74 1. Introduction 76 With the proliferation of Internet usage in both businesses and homes, 77 there has been an explosion in demand for non-LAN access to the 78 Internet. Most of these connections occur over dial up links. There 79 has also been a recent surge in the usage of ISDN and other sub- 80 T1 rate connections. Unfortunately, the nature of these 'low-bitrate' 81 links is that it is difficult to provide Quality of Service (QoS) when 82 there are multiple flows of data over the link. For example, it is 83 virtually impossible for a user to receive consistent performance when 84 running a browser, a file transfer and an IP telephony application 85 simultaneously over a low speed link. 87 The ISSLOW subgroup of the ISSL working group has focused on defining 88 mechanisms to permit flow differentiation and QoS capabilities for mixed 89 traffic over low speed links. This has been accomplished through a 90 series of extensions to the PPP protocol which permit fragmentation 91 and/or suspension of large packets in favor of packets on flows which 92 require QoS. These protocol extensions are presented in [1] and [2]. 94 This document describes the service mapping required to implement the 95 controlled load and guaranteed services over these PPP protocol 96 extensions. It is modeled on the Network Element Service Specification 97 Template described in [3]. It is assumed that the ISSLOW Network 98 Element is one portion of a PPP service available to the system. 100 2. End-to-end Behavior 102 Unlike many of the other specific link layers addressed in the ISSL 103 working group, ISSLOW operates only over low speed point to point links 104 or connections. Examples of these links include dial up lines, ISDN 105 channels, and leased lines. As such, 'end to end' simply means between 106 two points. In today's inter/intranet environment, this will include: 108 - host to directly connected host. 109 - host to/from network access device (router or switch). 110 - Edge device (subnet router or switch) to/from router or switch. 111 - In rare circumstances, the link may run from backbone router to 112 backbone router. 114 Thus, the endpoints are two network elements as described above. The 115 Controlled Load and Guaranteed services for ISSLOW links are applied on 116 the link between these elements and often represent the first or last 117 wide area hop in a true end to end service. It is important to note 118 that these links tend to be the most 'bandwidth constrained' along the 119 path. 121 ISSLOW services are only provided if both endpoints on the link support 122 ISSLOW. This is determined during the PPP negotiation. Because of the 123 unique characteristics of a point to point link with both endpoints 124 supporting ISSLOW, traffic is automatically shaped. That is, incoming 125 traffic will be TSpec conformant, and except for some special 126 considerations for Guaranteed Service (below), the admission control 127 function can make decisions based on local state: it does not need to 128 coordinate with the network element on the other end of the link. As 129 described in [5], Guaranteed Service should approximate the 130 functionality of a leased line. Since ISSLOW runs over point to point 131 links, when rate control and delay bounds are provided for individual 132 flows, the link inherently acts like a leased circuit. 134 Thus, even for Guaranteed Service, because this hop is the most 135 bandwidth constrained, and because the connection is dual simplex 136 (e.g., not a shared link for send & receive), all admission control 137 decisions can be made locally. 139 3. Motivation 141 Previous sections described the motivation for the ISSLOW capabilities. 142 Dial up users are now treating their relatively low-bitrate connections 143 as they would a higher speed connection. They are mixing multiple flows 144 of data and expect performance similar to what they see in a LAN 145 environment. However, it is deployment of realtime applications which 146 is the primary motivation for hosts to implement Integrated Services. 148 In particular, IP Telephony, which has tight delay constraints for 149 commercial-level performance, produces small packets. When these are 150 mixed with flows consisting of large packets (e.g. HTTP, FTP), delay 151 variance increases and absolute delay suffers as these small packets 152 wait in the queue behind even a single large packet being transmitted on 153 the link. Because of the jitter tolerance and adaptive nature of codecs 154 used for packet voice and video, just providing a controlled load 155 service would satisfy most of the need for IP Telephony and other 156 realtime applications which are expected to run over low-bitrate 157 connections. 159 Another consideration in handling of packets over low speed links occurs 160 when looking at the end-to-end issues. The low speed link is 161 usually just one hop on a longer path between endpoints. As such, it is 162 usually the limiting factor in performance. While this needs to be 163 considered in the host to router configuration, it becomes more critical 164 between edge devices and backbone routers where there is a multiuser 165 subnet as source and destination for traffic and a low-bitrate link to 166 the router. To ensure some performance bounds end-to-end, guaranteed 167 service should be considered over these links even if it cannot be 168 offered end to end in the network. 170 4. Network Element Data Handling Requirements 172 The ISSLOW Network Service element may be implemented in hardware or 173 software. As described in [1] and [2], for systems which can perform 174 bit-oriented transmission control, the suspend/resume approach optimizes 175 the available bandwidth by minimizing header overhead associated with 176 MLPPP fragmentation. For systems which provide frame-oriented 177 transmission control, the fragmentation approach can be implemented with 178 no hardware changes. Choice of suspend/resume versus fragmentation 179 should be made based on the hardware's capability to handle the new HDLC 180 framing described in [1] and the system overhead associated with byte by 181 byte scanning (required by suspend/resume). 183 To provide controlled load or guaranteed service with the suspend/resume 184 approach, when a packet for an IntServ admitted flow (QoS packet) 185 arrives during transmission of a best effort packet and continued 186 transmission of the best effort packet would violate delay constraints 187 of the QoS service flows, the best effort packet is preempted, the QoS 188 packet/fragments are added to the transmission, and the best effort 189 packet transmission is then resumed: usually all in one transmission. 190 The receiving station separates the best effort packet from the embedded 191 QoS fragments. It is also conceivable that one IntServe Flow's packet 192 might suspend another flow's packet if the delivery deadline of the new 193 packet is earlier than the current packet. 195 For systems which use fragmentation, since suspend/resume is not 196 possible, all packets longer than the maximum tolerable delay for an 197 IntServ packet are fragmented prior to transmission so that a short 198 packet for another flow can be interleaved between fragments of a large 199 packet and still meet the transmission deadline for the IntServ flow. 201 Note that the fragmentation discussed in this document refers to 202 multilink PPP (MLPPP) fragmentation and associated MCMLPPP modifications 203 as described in [1], not IP or other layer 3 fragmentation. MLPPP 204 fragmentation is local to the PPP link, and does not affect end-to-end 205 (IP) MTU. 207 4.01 Rate and Delay 209 ISSLOW assumes that the nature of point to point links is such that 210 rate, transmission time and delay are fixed and consistent. The rate of 211 the link is determined at connection time, and the devices on the link 212 (adapters, modems, DSU/CSUs, etc) exhibit fixed delay characteristics. 213 Unfortunately this is not always true. 215 POTS modems can have varying rates, but the rate for a particular 216 POTS modem connection tends to converge over time to a particular 217 value as the modems adjust to line conditions. Implementations 218 may need to adjust their admission control policies to reflect 219 this convergence. Note that the value converged upon is frequently 220 higher (usually about 10%)than the initial reported rate for a 221 connection - this means that admission control will almost certainly 222 be overly conservative unless it takes this rate change into account. 224 In addition, tests with the V.42 protocol have shown that delay is also 225 not consistent. Unfortunately it does not converge to a stable value 226 like the rate. In fact, delay spikes may exceed the burst transmission 227 time which represents acceptable delay for Controlled Load (CL) Service. 228 Although the link delay term D is not used for CL admission or 229 scheduling, it may be useful to encorporate a bounded D term into 230 handling of CL flows over ISSLOW links. 232 4.02 Link Aggregation 234 Although certain link types, like ISDN, permit dynamic allocation of 235 Bandwidth across multiple links, it is assumed that the Admission 236 Control service will consider the impact of multiple physical links over 237 the point to point logical connection. 239 Note that because of the load balancing effect of Multilink PPP (MLPPP), 240 two 64 Kbps links should exhibit the delay and transmission 241 characteristics of a single 128 Kbps link. However, MLPPP 242 implementations may approach load balancing and fragmentation 243 differently. The mechanism used should be taken into consideration when 244 implementing the scheduler (especially token bucket) for packets, 245 fragments, and suspend/resume on top of existing MLPPP services to 246 ensure that adequate rate and delay characteristics are maintained. 248 4.1 Controlled Load versus Guaranteed Service 250 With most link layers, Guaranteed Service requires more tightly 251 controlled service by the Network Element, and in most cases, acceptance 252 of a Guaranteed Service request results in over-provisioning of link 253 level resources. Controlled Load (CL) Service is usually less 254 constrained and permits more flexibility in scheduling of packets for 255 the link. 257 Controlled Load requires that the delay associated with packet 258 transmission be 'closely equivalent to unloaded best effort service.' 259 Because ISSLOW operates over point to point links, unloaded best effort 260 service means that best effort packets will incur no more than burst 261 packet delay: M/r where M is the maximum packet size and r is the 262 transmission rate. Thus maximum permitted delay for a Controlled Load 263 packet (CLmDELAY) is bounded by M/r + P/r where P is the size of the 264 outgoing packet. 266 4.2 Controlled Load and Guaranteed Service Data Handling 268 Upon arrival of a QoS flow's packet, the ISSLOW Network Element 269 determines if the packet is conformant. If it is not, Policing is 270 applied (see Policing). Conformant means: 272 1) The flow does not exceed the associated TSpec peak rate (RSpec rate 273 for Guaranteed Service: rT+b with T=time period). 274 2) The packet does not cause a token bucket overflow. 276 If the packet is conformant, it is compressed as required, fragmented 277 (if necessary), and scheduled. If there is no conflicting best effort 278 traffic, the packet is queued along with the rest of conformant QoS 279 traffic and scheduled with respect to any other IntServ flows such that 280 its transmission deadline is met. 282 For the suspend/resume implementation to achieve controlled load, any 283 packets being transmitted whose transmission would violate 284 the CLmDELAY are suspended. Otherwise, the QoS packet/fragments are 285 scheduled ahead of any queued best effort traffic. 287 For CL Fragmentation implementations, the packet/fragment is scheduled 288 ahead of any best effort packets. Note that all best effort packets 289 must be divided into fragments less than or equalto the smallest MRU 290 (or associated fragment size) of all the QoS flows. This incurs at 291 most one fragment delay for the QoS traffic: closely equivalent to 292 unloaded best effort service. 294 For Guaranteed Service for both Fragmentation and suspend/resume, the 295 scheduler determines if continued transmission of the best effort packet 296 being transmitted would cause delay greater than the acceptable delay. 297 If so, the best effort packet is preempted or, in the case of 298 fragmentation, the QoS packet is scheduled ahead of the rest of the 299 best effort packets' fragments. 301 4.3 Controlled Load and Guaranteed Service Class Mapping 303 To provide consistent signalling across point to point links, it 304 is important to identify and characterize the flows consistently 305 on each end of the link. Ideally, both ends would use similar 306 scheduling mechanisms as well. The coordination of flow identification 307 and scheduling can be achieved easily with the new MLPPP 308 class mappings [1]. 310 Depending on the sequence number option chosen in the MLPPP negotiation, 311 there are either 2 bits (short sequence numbers) or 4 bits (long 312 sequence numbers) available for class identification. 314 Following the model of other working subgroups, traffic classes should be 315 mapped as follows: 317 Traffic Type MLPPP Class (short) MLPPP Class (long) 319 Best Effort 0 0 320 non-conformant 0 1 321 Controlled Load 1 4 322 Guaranteed (10ms) 2 5 323 Guaranteed (100ms) 3 6 324 5. Invocation Information 326 To invoke Controlled Load and Guaranteed Services, both traffic 327 characteristics and the flow itself must be identified to the Network 328 Element. Several methods can be employed to identify the flows. For 329 RSVP, filtering can be used to identify the flows. For non-RSVP 330 implementations, mechanisms such as the FlowID field in IP Version 6, or 331 the TOS field in IP version 4 can be used. As described above, the 332 Network Element can then use the specified values to apply the 333 appropriate QoS and to map the flows to a particular class. 335 A number of major router and switch vendors currently support use of 336 the TOS bits to signal priority and class of service. As a result, 337 applications and host proxies have been developed to enable users and 338 network managers to apply policies requesting differential services via 339 TOS. Use of these bits is the easiest way to identify flows without 340 the overhead of filtering. 342 It is therefore strongly recommended that the Network Service Element 343 support mapping of the IP Precedence bits of the TOS field to MLPPP 344 classes described in [1] as follows: 346 IP Precedence Value Multiclass - short seq Multiclass - long seq 348 0 0 0 349 1 0 1 350 2 or 3 0 2 or 3 351 4 1 4 352 5 2 5 353 6 or 7 3 6 or 7 355 Note that use of the TOS field or of the FlowID field does not preclude 356 prefix elision. The Network Service Element can map the TOS or FlowID 357 to a MLPPP class, elide the prefix before transmission, and the prefix 358 (with TOS or FlowID) will be reapplied by the receiver. 360 If the Network Service Element is running on a system that doesn't 361 support application or proxy use of the TOS or FlowID fields, then 362 filtering must be applied and: 364 As described in [4], Controlled Load Service is invoked by specifying 365 the flow's traffic characteristics through a TSpec (see [5]). 367 As described in [5], Guaranteed Service is invoked by specifying the 368 flow's TSpec and a requested reservation via an RSpec (see [6]). 370 6. Exported Information. 372 For Controlled Load Service, there is no requirement to export 373 information. 375 For Guaranteed service, both C and D terms for delay computations must 376 be made available for export through the Adspec or other means. See 377 Sections 9.1 (Admission Control) for guidelines on computing the C and D 378 terms. 380 See [4] and [5] for additional information on Exported Information. 382 7. Policing 384 Policing is applied to non-conformant QoS traffic and to best effort 385 traffic whose transmission would violate the Controlled Load or 386 Guaranteed Service constraints. This document does not designate a 387 specific packet scheduling implementation. Ideally, best effort traffic can be 388 serviced through separate queues and a weighted queuing mechanism, or when a 389 conflict with QoS traffic arises, best-efforts traffic can simply be discarded. 391 Both Controlled Load and Guaranteed Services permit scheduling of non- 392 conformant traffic as well as the option to discard non-conformant 393 packets. See [4] and [5] for additional information on policing options 394 for Controlled Load and Guaranteed Services. 396 8. Ordering and Merging 398 Refer to [4] and [5] for TSpec and RSpec ordering and merging 399 guidelines. 401 9. Guidelines for Implementors 403 9.1 Bit and Byte Stuffing Considerations 405 Certain kinds of low bandwidth links present special challenges in providing 406 controlled load and guaranteed service even when the ISSLOW protocols are 407 used. These challenges are documented here as a caution to implementers to 408 prevent use of overly optimistic admission control policies. 410 One important consideration in provisioning any PPP link is reductions in 411 available link rate due to bit stuffing. Typical bit stuffing algorithms 412 can result in as much as 20% additional overhead. Thus, admission control 413 algorithms for guaranteed service over links where bit stuffing can take place 414 should take the RSpec rate of all flows and multiply by 1.2 in determining 415 whether a new flow can be admitted or not. Admission control algorithms for 416 controlled load reservations may use a similar algorithm using the TSpec peak 417 rate or may attempt to measure the actual degree of expansion occurring on a 418 link due to bit stuffing. This characterization can then be used to adjust 419 the calculated remaining link capacity. Such algorithms must be used 420 cautiously, in that the degree of bit stuffing occurs may vary significantly, 421 both in an inter- and intra-flow fashion. 423 Byte stuffing is also found on many PPP links, most frequently on POTS modems 424 when using the v.42 protocol. Byte stuffing poses a difficult problem to 425 admission control, particularly in the case of guaranteed service, due to 426 its highly variable nature. In the worse case, byte stuffing can result in 427 a doubling of frame sizes. As a consequence, a strict implementation of 428 admission control for guaranteed load on byte stuffed PPP links should double 429 RSpec of link traffic in making flow admission decisions. As with bit 430 stuffing, implementations of controlled load service admission control 431 algorithms for links with byte stuffing may attempt to determine average 432 packet expansion via observation or may use the theoretical worst case values. 434 In addition to PPP bit- and byte stuffing, other protocols used in POTS 435 modems also have ramifications on link capacity. The v.34 protocol, for 436 instance, is adaptive to link conditions, and is able to recalibrate its 437 transmission rate multiple times over the duration of a connection. 438 Typically this re-calibration will result in a small (~10%) increase in 439 transmission rate over the initial connection within the first minute of 440 a call. It is important to note, however, that other results are possible 441 as well, including decreases in available bandwidth. Admission control 442 algorithms must take such changes into consideration as they occur, and 443 implementations must be designed to gracefully handle the pathological case 444 where link rate actually drops below the currently reserved capacity of a link. 446 The v.42 protocol is another potential troublesome area in implementing 447 integrated services over low bandwidth links. This protocol, which provides 448 link layer reliability via retransmission, can result in frames experiencing 449 unpredictable delays in transiting such a link. Retransmissions also 450 implicitly steal link bandwidth from other traffic. These delays and 451 reductions in link bandwidth make it extremely difficult to honor a 452 guaranteed service reservation. On a link that is actually lightly or 453 moderately loaded, a controlled load service can to some extent accept 454 such events as part of the behavior of a lightly loaded link. Unfortunately, 455 as actual link utilization increases, v.42 retransmissions have the 456 potential of stealing larger and larger fractions of available link bandwidth; 457 making even controlled load service difficult to offer at high link utilization 458 when retransmissions occur. 460 Finally, the framing method must be factored into the overhead associated with 461 link level tramsmission. If fragmentation is used, the overhead associated with 462 fragment headers must be included in the admission control calculations below. 463 If suspend/resume is used, the additional framing overhead for inserted packets 464 must also be calculated. 466 9.2 Compression Considerations 468 The ISSLOW specification supports several PPP options. When deciding 469 whether to admit a flow, Admission Control must compute the impact of 470 the following on MTU size, rate, and fragment size: 472 Header compression: Van Jacobson or Casner-Jacobsen. 473 Prefix Elision. 474 CCP. 475 CRTP. 476 Fragment header option used. 477 Fragmentation versus suspend/resume approach. 479 If any of the compression options are implemented for the connection, 480 the actual transmission rate, and thus the bandwidth required of the 481 link, will be reduced by the compression method(s) used. 483 Prefix elision can take advantage of mapping flows to MLPPP classes 484 to elide prefixes which cannot be compressed at higher layers. By 485 establising agreement across the link, the sender may elide a prefix for 486 a certain class of traffic and upon receiving packets in that class, the 487 receiver can restore the prefix. 489 Both compression gain and elision gain must be included as described in 490 the admission control section below. 492 9.3 Admission Control 494 Admission Control must decide whether to admit a flow based on rate and 495 delay. Assume the following: 497 LinkRate is the rate of the link. 498 MTU is the maximum transmission unit from a protocol. 499 MRU is the maximum receive unit for a particular link. 500 CMTU is the maximum size of the MTU after compression is applied. 501 eMTU is the maximum effective size of the MTU after fragmentation. 502 FRAG is the fragment size including MLPPP header/trailers. 503 Header is the size of the header/trailers/framing for MLPPP/Fragments. 504 pHeader is the additional header/framing overhead associated with 505 suspend/resume. This should include FSE and worst case stuffing 506 overhead. 507 pDelay is the delay associated with suspend/resume packets. 508 b is the bucket depth in bytes 509 R is the requested Rate. 510 D is the fixed overhead delay for the link (Modem, DSU, etc). 511 C is the delay associated with transmission and fragmentation. 512 eRate is the effective rate after compression and fragmentation. 514 The D term may be configured by an administrative tool once the network 515 is installed; it may be computed using the Adspec or other realtime 516 measurement means; or it may be available from hardware during link 517 setup and/or PPP negotiation. 519 Admission Control must compute CMTU, eMTU, and eRate for Controlled Load 520 Service, and it must compute CMTU, eMTU, eRate, and C for Guaranteed 521 Service: 523 To determine whether the requested rate is available, Admission Control 524 must compute the effective rate of the request (eRate) - worst case - as 525 follows: 527 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 529 eMTU = (#_of_Fragments) * FRAG 531 eRate = eMTU/CMTU * R 533 Admission Control should compare the eRate of the request against the 534 remaining bandwidth available to determine if the requested rate can be 535 delivered. 537 For Controlled Load Service, a flow can be admitted as long as there is 538 sufficient bandwidth available (after the above computation) to meet the 539 rate requirement, and if there is sufficient buffer space (sum of the 540 token bucket sizes does not exceed the buffer capacity). While some 541 statistical multiplexing could be done in computing admissability, the 542 nature of the low-bitrate links could make this approach risky as any 543 delay incurred to address a temporary overcommitment could be difficult 544 to amortize. 546 Guaranteed Service requires delay computations. These computation are 547 based on the standard formula for delay: 549 Delay = b/R + C/R + D 551 Note that for suspend/resume, an additional term is required: 553 pDelay = b/R + C/R + D + pHeader/R. 555 This term exists because of the additional overhead associated with the 556 suspend/resume headers created when suspending a packet. In the worse 557 case, every transmission of a QoS packet could require suspension of a 558 best effort packet and thus incur the overhead. In most networks, this 559 term will be nominal at most. However, on some low-bitrate links, the 560 overhead may be worth computing. 562 Since MLPPP includes fragmentation, the C term is not fixed and must be 563 represented by the worse case fragmentation as computed in the effective 564 MTU size: 566 C = eMTU. 568 Note that because ISSLOW runs on point to point links, Guaranteed 569 Service can be offered over a link without any negotiated agreement from 570 the next hop. However, if these services are used in conjunction with 571 RSVP, the C and D values above should be used in the Adspec. 573 9.4 Fragment Scheduling Considerations 575 As described in Section 4, large packets should be fragmented to a size 576 sufficiently small to allow higher priority flows to get a hold of the 577 line quickly enough to not violate their reservation constraints. As 578 such, the upper bound for fragment sizes should be no larger than the 579 smallest MTU of all QoS flows. While a very small fragment size 580 is desirable from the point of view of efficient link utilization, the 581 overhead associated with highly granular fragmentation makes it 582 necessary to strike a balance between these considerations. While this 583 document will not specify a particular scheduling algorithm, the 584 following example should help illustrate the issue: 586 Assume we have three different priority flows, A, B, and C. 587 A is higher priority than B, B higher than C 588 (and of course it is transitive). Packets from flow C take 589 100ms, flow B takes 30ms, and flow A takes 30ms to transmit. B's 590 required maximum latency is 70ms, while A's is 50ms. The above scenario 591 results in flowsB and C needing to be segmented into 20ms long fragments - 592 that way a lower priority frame will hold the link at most 593 20ms before A gets to the link, taking another 30ms to transit, 594 totaling 50ms - all well and good. B has a problem, however - 595 in the scenario where a fragment from C is just starting 596 to transmit the link when packets from A and B arrive (call 597 this time 0). The fragment from C will transmit until time 20ms. 598 After that, the A packet will transmit - finishing by time 50ms, 599 just in time. At this point, the fragment from B starts to 600 transmit - taking 30ms more, finishing by time 80ms (thus violating 601 its reservation). 603 The important point above the scenario is not that it is possible 604 to underprovision a link, but that a link can be underutilized 605 by using too large a fragment size - in the above case, a 10ms 606 fragment size would have allowed both A and B to honor their 607 reservations, a 20ms size does not. 609 10. Evaluation Criteria 611 For Controlled Load Service, the ISSLOW network element must ensure that 612 the service requested via the TSpec is delivered to the requesting QoS 613 flow such that the PPP link appears to be a 'lightly loaded link. 615 As a baseline, it is suggested that performance measurements on 616 throughput, delay, and packet error measurements be performed on an 617 unloaded link with just the QoS flow using various packet sizes. The 618 baseline should measure performance for both conformant and non- 619 conformant traffic when for overloading the link with a single flow. 620 Once these measurements are complete, measurements of the 621 Controlled Load Service should be performed as follows: 623 1) Request QoS flows in the presence of best effort traffic and ensure 624 that the QoS flows' performance approximate the unloaded baseline 625 measurements. 627 2) Request QoS flows whose aggregate throughput would exceed the link 628 capacity. Admission Control should deny these service requests or admit 629 them as best effort only. 631 3) Generate traffic on a QoS flow which exceeds its TSpec commitment. 632 Ensure recovery of the flow once the traffic becomes conformant. 634 For Guaranteed Service: 636 1) Ensure that Admission Control will deny service requests or convert 637 them to best effort when link capacity or delay bounds would be 638 exceeded. 640 2) On a best-efforts loaded link, ensure that the number of lost packets 641 does not exceed those established in the baseline measurements. 643 3) On a best-efforts loaded link, ensure that delay and rate commitments 644 can be met for QoS flows. 646 4) With multiple QoS flows, ensure that an admission of additional QoS 647 flows does not cause a violation in rate, error rate, or delay 648 constraints of any QoS flow. 650 11. Security Considerations 652 Security considerations for PPP links are the subject of other working 653 groups. However, with respect to providing quality of service over PPP 654 links, it is important to note that relying on observed average packet expansion 655 during admission control, due to bit- or byte stuffing 656 introduces a potential vulnerability to denial of service attacks. An adversary 657 could intentionally send traffic that will result in worst case bit- or byte 658 stuffing packet expansion, which could in turn result in quality of service 659 guarantees not being met for other flows. This potential denial of service 660 attack argues strongly for using a worst case expansion factor in admission control 661 calculations, even for controlled load service. 663 12. References 665 [1] C. Bormann "The Multi-Class Extension to Multilink PPP" 666 Internet Draft, July 1997, 668 [2] C. Bormann "PPP in a real-time oriented HDLC-like framing" 669 Internet Draft, July 1997, 671 [3] rfc2216 -- Network Element Service Specification Template. S. 672 Shenker, J. Wroclawski. September 1997 674 [4] rfc2211 -- Specification of the Controlled-Load Network 675 Element Service. J. Wroclawski. September 1997 677 [5] rfc2212 -- Specification of Guaranteed Quality of Service. S. 678 Shenker, C. Partridge, R. Guerin. September 1997 680 [6] rfc2215 -- General Characterization Parameters for Integrated 681 Service Network Elements. S. Shenker, J. Wroclawski. September 1997. 683 13 Author's Address: 685 Steve Jackowski 686 Deterministic Networks, Inc. 687 245M Mt Hermon Rd, #140 688 Scotts Valley, CA 95060 689 stevej@DeterministicNetworks.com 690 (408)813-6294 692 David M. Putzolu 693 Intel Architecture Labs (IAL) 694 JF3-206-H10 695 2111 NE 25th Avenue 696 Hillsboro, OR 97124-5961 697 David.Putzolu@intel.com 698 (503) 264-4510