idnits 2.17.1 draft-ietf-issll-isslow-svcmap-07.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 3) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 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 46 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 37 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: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (April 14, 1999) is 9142 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) == Unused Reference: '7' is defined on line 556, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-05 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-05 == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-04 == Outdated reference: A later version (-01) exists of draft-davie-intserv-compress-00 -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2509 (ref. '10') (Obsoleted by RFC 3544) 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-DRAFT Steve Jackowski/Deterministic Networks 2 Expires: October 1999 David Putzolu/Intel Architecture Labs 3 Eric Crawley/Argon Networks 4 Bruce Davie/Cisco Systems 5 April 14, 1999 7 Integrated Services Mappings for Low Speed Networks 8 draft-ietf-issll-isslow-svcmap-07.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC 2026. 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 not appropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Abstract 31 A set of companion documents describe an architecture for providing 32 integrated services over low-bitrate links, such as modem lines, ISDN 33 B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the 34 architecture are: a set of real-time encapsulation formats for 35 asynchronous and synchronous low-bitrate links, a header compression 36 architecture optimized for real-time flows, elements of negotiation 37 protocols used between routers (or between hosts and routers), and 38 announcement protocols used by applications to allow this negotiation 39 to take place. 41 This document defines the service mappings of the IETF Integrated 42 Services for low-bitrate links, specifically the controlled load [5] 43 and guaranteed [6] services. The approach takes the form of a set of 44 guidelines and considerations for implementing these services, along 45 with evaluation criteria for elements providing these services. 47 1. Introduction 49 In addition to the "best-effort" services the Internet is well-known 50 for, other types of services ("integrated services") are being 51 developed and deployed in the Internet. These services support special 52 handling of traffic based on bandwidth, latency, and other 53 requirements that cannot usually be met using "best-effort" service. 55 This document defines the mapping of integrated services "controlled 56 load" [5] and "guaranteed" [6] services on to low-bandwidth links. 57 The architecture and mechanisms used to implement these services on 58 such links are defined in a set of companion documents. The mechanisms 59 defined in these documents include both compression of flows (for 60 bandwidth savings) [4,10] and a set of extensions to the PPP protocol 61 which permit fragmentation [2] or suspension [3] of large packets in 62 favor of packets from flows with more stringent service requirements. 64 1.1. Specification Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119. 70 2. Issues for Providing Controlled and Guaranteed Service 72 Unlike other link layers, the links referred to in this document 73 operate only over low speed point to point connections. Examples of 74 the kinds of links addressed here include dial-up lines, ISDN 75 channels, and low-speed (1.5Mbps or less) leased lines. Such links 76 can occur at different positions within the end-to-end path: 78 - host to directly connected host. 79 - host to/from network access device (router or switch). 80 - Edge device (subnet router or switch) to/from router or switch. 81 - In rare circumstances, a link from backbone router to backbone 82 router. 84 These links often represent the first or last wide area hop in a true 85 end to end service. Note that these links may be the most bandwidth 86 constrained along the path between two hosts. 88 The services utilized in mapping integrated services to these links 89 are only provided if both endpoints on the link support the 90 architecture and mechanisms referenced above. Support for these 91 mechanisms is determined during the PPP negotiation. The non-shared 92 nature of these links, along with the fact that point-to-point links 93 are typically dual simplex (i.e., the send and receive channels are 94 separate) allows all admission control decisions to be made locally. 96 As described in [2] and [3], for systems that can exert real time 97 control of their transmission at a finer grain than entire HDLC 98 frames, the suspend/resume approach optimizes the available bandwidth 99 by minimizing header overhead associated with MLPPP pre-fragmentation 100 and can provide better delay. However, this comes at the expense of 101 preparing all outgoing data and scanning all incoming data for 102 suspend/resume control information. The fragmentation approach can be 103 implemented without additional scanning of the data stream (beyond 104 bit-/byte-stuffing, which may be in hardware) and is applicable to 105 systems which provide only frame-oriented transmission control. 106 Choice of suspend/resume versus fragmentation should be made based on 107 the level of transmission control, the element's capability to handle 108 the HDLC-like framing described in [2], and the system overhead 109 associated with byte by byte scanning (required by suspend/resume). 111 To provide controlled load or guaranteed service with the 112 suspend/resume approach, when a packet for an admitted flow (QoS 113 packet) arrives during transmission of a best effort packet and 114 continued transmission of the best effort packet would violate delay 115 constraints of the QoS service flows, the best effort packet is 116 preempted, the QoS packet/fragments are added to the transmission, and 117 the best effort packet transmission is then resumed: usually all in 118 one transmission. The receiving station separates the best effort 119 packet from the embedded QoS packet's fragments. It is also 120 conceivable that one QoS flow's packet might suspend another flow's 121 packet if the delivery deadline of the new packet is earlier than the 122 current packet. 124 For systems which use fragmentation, any packets longer than the 125 maximum tolerable delay for packets from enhanced service flows are 126 fragmented prior to transmission so that a short packet for another 127 flow can be interleaved between fragments of a larger packet and still 128 meet the transmission deadline for the flow requiring enhanced 129 services. 131 Note that the fragmentation discussed in this document refers to 132 multilink PPP (MLPPP) fragmentation and associated MCMLPPP 133 modifications as described in [2], not IP or other layer 3 134 fragmentation. MLPPP fragmentation is local to the PPP link, and does 135 not affect end-to-end (IP) MTU. 137 2.1 Calculating "Acceptable Delay" for Int-serv flows 139 A router which provides Controlled Load or Guaranteed Service over a 140 low speed serial link needs to have some notion of the "acceptable 141 delay" for packets that belong to int-serv flows. If using 142 fragmentation, a router needs to know what size to fragment packets 143 to; if using suspend/resume, it needs to know when it is appropriate 144 to suspend one packet to meet the delay goals of another. 146 Unfortunately, there is no hard and fast way for a single delay bound 147 to be determined for a particular flow; while the end-points of a flow 148 have enough information to determine acceptable end-to-end delay 149 bounds and to make reservation requests of the network to meet those 150 bounds, they do not communicate a "per-hop" delay to routers. 152 In the case of Guaranteed Service, one approach is to let the network 153 operator configure parameters on the router that will directly affect 154 its delay performance. We observe that guaranteed service allows 155 routers to deviate from the ideal fluid flow model and to advertise 156 the extent of the deviation using two error terms C and D, the 157 rate-dependent and rate-independent error terms. A network operator 158 can configure parameters of the low speed link in such a way that D is 159 set to a value of her choice. 161 If link-level fragmentation is used, the router controlling a 162 low-speed link can be configured with a certain fragment size. This 163 will enable a component of the error term D to be calculated based on 164 the time to send one fragment over the link. (Note that D may have 165 other components such as the speed of light delay over the link.) 166 Details of the calculation of D are described below. Similarly, if 167 suspend/resume is used, the router may be configured with a delay 168 parameter, which would enable it to decide when it was appropriate to 169 suspend a packet. 171 For Controlled Load, there are no error terms, and the router must 172 decide how best to meet the requirements of the admitted reservations 173 using only the information in their TSpecs. Since the definition of 174 Controlled Load states that a CL flow with Tspec rate r should receive 175 treatment similar to an unloaded network of capacity r, CL packets 176 should not generally experience end-to-end delays significantly 177 greater than b/r + propagation delays. Clearly a router connected to a 178 low speed link should not introduce a delay greater than b/r due to 179 transmission of other fragments; ideally it should introduce 180 substantially less delay than b/r, since other hops on the end-to-end 181 path may introduce delay as well. However, this may be difficult for 182 flows with very small values of b. 184 It is expected that implementors will make their own tradeoffs as to 185 how low to make the delay for Controlled Load flows. Similarly, it may 186 not be possible or desirable to configure the parameters affecting D 187 to arbitrarily small values, since there is a cost in overhead in 188 fragmenting packets to very small sizes. Conversely, if D is too 189 large, some applications may find that they cannot make a reservation 190 that will meet their delay objectives. 192 For the remainder of this document, we assume that a router has some 193 notion of the acceptable delay that it may introduce before beginning 194 transmission of a packet. This delay is in addition to any delay that 195 a packet might be subjected to as a result of the "ideal" queuing 196 algorithm that the router uses to schedule packets. 198 3. Controlled Load and Guaranteed Service Class Mapping 200 Supporting integrated services over PPP links which implement MCML or 201 RTF can be accomplished in several ways. Guidelines for mapping these 202 services to PPP links and to the classes provided by the 203 suspend/resume and fragmentation mechanisms are presented below. Note 204 that these guidelines assume that some sort of signaling protocol is 205 used to indicate desired quality of service to both the sender and 206 receiver of a flow over a PPP link. 208 3.1 Predefined Class Mappings 210 A relatively simple method of class mapping that MAY be used is one 211 where class values correspond to predefined levels of service. In 212 this arrangement, all admitted flows are grouped into one of several 213 buckets, where each bucket roughly corresponds to the level of service 214 desired for the flows placed in it. An example set of mappings appears 215 below: 217 MCML Short MCML Long RTF Service 219 0b00 0b0000 0b000 Best Effort 220 NA 0b0001 0b001 Reserved 221 0b01 0b0010 0b010 Delay Sensitive, no bound 222 NA 0b0011 0b011 Reserved 223 NA 0b0100 0b100 Reserved 224 0b10 0b0101 0b101 Delay Sensitive, 500ms bound 225 NA 0b0110 0b110 Delay Sensitive, 250ms bound 226 0b11 0b0111 0b111 Network Control 228 Table 1: Example Mappings of Classes to Services 230 Note that MCML has two formats, short sequence numbers, and long 231 sequence numbers, that allow for 2 and 4 bits of class identification. 232 RTF allows for 3 bits of class identification in all formats. 234 Using a default-mapping method of assigning classes to flows in a 235 fixed fashion comes with certain limitations. In particular, all flows 236 which fall within a particular bucket (are assigned to a particular 237 class) will be scheduled against each other at the granularity of 238 packets, rather than at the finer grained level of fragments. This 239 can result in overly conservative admission control when the number of 240 available classes is small such as in MCML short sequence number 241 format. 243 3.2 Predefined Class Mappings and Prefix Elision 245 In the case where fewer reservations are expected than the total 246 number of classes negotiated for a PPP link, it is possible to assign 247 individual flows to fixed class numbers. This assignment is useful in 248 the case where the protocol identifier associated with one or more 249 flows is known at LCP negotiation time and the bandwidth of the 250 connection is relatively small. If these conditions hold true, then 251 for those flows that are known, a specific class can optionally be 252 assigned to them and the prefix elision PPP option can be used for 253 those classes to achieve a small bandwidth savings. 255 3.3 Dynamic Class Mappings 257 In the case where predefined class mappings are not satisfactory, an 258 implementor MAY map class values to individual packets rather than 259 assigning flows to fixed classes. This can be done due to the fact 260 that the classes that MCML and RTF provide can be viewed purely as 261 PPP-specific segmentation/fragmentation mechanisms. That is, while the 262 class number MUST remain constant on an intra-packet basis, it MAY 263 vary on an inter-packet basis for all flows transiting a PPP 264 link. Actual assignment of particular flows to fixed classes is 265 unnecessary, as the class numbers are NOT REQUIRED to have any meaning 266 other than in the context of identifying the membership of 267 fragments/segments as part of a single packet. This point is 268 sufficiently important that an example is provided below. 270 Consider a PPP link using the MCML short sequence number fragment 271 format (that is, four classes are provided). Assume that in addition 272 to carrying best effort traffic, this link is carrying five guaranteed 273 service flows, A, B, C, D, and E. Further assume that the link 274 capacity is 100kbit/s and the latency is 100ms. Finally, assume the BE 275 traffic is sufficient to keep the pipe full at all times and that GS 276 flows A-E are each 10kbit/s and all have delay bounds of 145ms. 278 Time(ms) Action 279 0 BE traffic is queued up 280 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 281 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 282 9 8kbit packet from flow A arrives 283 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 284 11 8kbit packet from flow B arrives 285 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 286 13 8kbit packets from flows C, D, and E arrive 287 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 288 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 289 18 2kbit fragment from A sent, cls 1 290 20 2kbit fragment from B sent, cls 2 291 22 2kbit fragment from A sent, cls 1 292 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 293 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 294 27 8kbit packet from flow A arrives 295 28 2kbit fragment from B sent, cls 2 296 30 2kbit fragment from C sent, cls 3 297 32 2kbit fragment from E sent, cls 1 298 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 299 36 2kbit fragment from E sent, cls 1 300 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 301 (etc.) 302 This example shows several things. First, multiple flows MAY share the 303 same class, particularly in the case where there are more flows than 304 classes. More importantly, there is no reason that a particular flow 305 must be assigned to a fixed class - the only requirement is that each 306 packet, when fragmented, MUST have the same class value assigned to 307 all fragments. Beyond this requirement the link scheduler may assign 308 individual to changing class numbers as necessary to meet reservation 309 requirements. 311 One suggestion to implementers of integrated services on MCML and RTF 312 links using dynamic mappings is that all BE traffic SHOULD be 313 logically separated from QoS traffic, and mapped to a fragmentable 314 (MCML classes 0-3 in short sequence number fragment format, 0-15 in 315 long sequence number fragment format) or suspendable (RTF classes 0-6) 316 class. Since BE traffic will in most implementations not be scheduled 317 for transmission except when a link is empty (that is, no CL or GS 318 traffic is ready for transmission), implementors MAY choose to make 319 use of class number 0 for BE traffic. 321 3.4 Non-Conformant Traffic 323 Treatment of non-conformant QoS traffic is largely determined by the 324 appropriate service specifications, but the detailed implementation in 325 the context of this draft allows for some flexibility. Policing of 326 flows containing non-conformant traffic SHOULD always be done at the 327 level of granularity of individual packets rather than at a finer 328 grained level. In particular, in those cases where a network element 329 scheduling flows for transmission needs to drop non-conformant 330 traffic, it SHOULD drop entire packets rather than dropping individual 331 fragments of packets belonging to non-conformant traffic. In those 332 cases where a network element forwards non-conformant traffic when 333 link bandwidth is available rather than dropping the traffic, the 334 implementation SHOULD fragment packets of such traffic as if it were 335 best effort traffic. 337 Whether BE and non-conformant traffic are treated differently in 338 regards to transmission (e.g., BE is given priority access over 339 non-conformant traffic to the link) or whether within each type of 340 traffic special treatment is afforded to individual flows (e.g., WFQ, 341 RED, etc.) is service dependent. 343 4. Guidelines for Implementors 345 4.1. PPP Bit and Byte Stuffing Effects on Admission Control 347 An important consideration in performing admission control for PPP 348 links is reductions in effective link rate due to bit 349 stuffing. Typical bit stuffing algorithms can result in as much as 20% 350 additional overhead. Thus, admission control implementations for 351 guaranteed service over links where bit stuffing is used SHOULD take 352 the RSpec rate of all flows and multiply by 1.2 in determining whether 353 a new flow can be admitted or not. Admission control implementations 354 for controlled load reservations may use a similar algorithm using the 355 TSpec peak rate or may attempt to measure the actual degree of 356 expansion occurring on a link due to bit stuffing. This 357 characterization can then be used to adjust the calculated remaining 358 link capacity. Such measurements must be used cautiously, in that the 359 degree of bit stuffing that occurs may vary significantly, both in an 360 inter- and intra-flow fashion. 362 Byte stuffing is also used on many PPP links, most frequently on POTS 363 modems when using the v.42 protocol. Byte stuffing poses a difficult 364 problem to admission control, particularly in the case of guaranteed 365 service, due to its highly variable nature. In the worse case, byte 366 stuffing can result in a doubling of frame sizes. As a consequence, a 367 strict implementation of admission control for guaranteed load on byte 368 stuffed PPP links SHOULD double the RSpec of link traffic in making 369 flow admission decisions. As with bit stuffing, implementations of 370 controlled load service admission control algorithms for links with 371 byte stuffing MAY attempt to determine average packet expansion via 372 observation or MAY use the theoretical worst case values. 374 4.2. Compression Considerations 376 The architecture for providing integrated services over low bandwidth 377 links uses several PPP options to negotiate link configuration as 378 described in [4, 8, 10]. When deciding whether to admit a flow, 379 Admission Control MUST compute the impact of the following on MTU 380 size, rate, and fragment size: 382 Header compression: Van Jacobson or Casner-Jacobson [4,8,10]. 383 Prefix Elision. 384 CCP. 385 Fragment header option used. 386 Fragmentation versus suspend/resume approach. 388 If any of the compression options are implemented for the connection, 389 the actual transmission rate, and thus the bandwidth required of the 390 link, will be reduced by the compression method(s) used. 392 Prefix elision can take advantage of mapping flows to MLPPP classes to 393 elide prefixes which cannot be compressed at higher layers. By 394 establishing agreement across the link, the sender may elide a prefix 395 for a certain class of traffic and upon receiving packets in that 396 class, the receiver can restore the prefix. 398 Both compression gain and elision gain MUST be included as described 399 in the admission control section below. Note that the ability to 400 perform compression at higher layers (e.g. TCP or RTP/UDP) may depend 401 on the provision of a hint by the sender, as described in [9]. 403 4.3. Admission Control 405 Admission Control MUST decide whether to admit a flow based on rate 406 and delay. Assume the following: 408 LinkRate is the rate of the link. 409 MTU is the maximum transmission unit from a protocol. 410 MRU is the maximum receive unit for a particular link. 411 CMTU is the maximum size of the MTU after compression is applied. 412 eMTU is the effective size at the link layer of an MTU-sized packet after 413 link layer fragmentation and addition of the fragment headers. 414 FRAG is the fragment size including MLPPP header/trailers. 415 Header is the size of the header/trailers/framing for MLPPP/Fragments. 416 pHeader is the additional header/framing overhead associated with 417 suspend/resume. This should include FSE and worst case stuffing 418 overhead. 419 pDelay is the time take to suspend a packet already "in flight", 420 e.g. due to the delay to empty the output FIFO. 421 b is the bucket depth in bytes 422 R is the requested Rate. 423 Dlink is the fixed overhead delay for the link (Modem, DSU, 424 speed-of-light, etc). 425 eRate is the effective rate after compression and fragmentation. 427 The Dlink term MAY be configured by an administrative tool once the 428 network is installed; it may be determined by real-time measurement 429 means; or it MAY be available from hardware during link setup and/or 430 PPP negotiation. Refer to Appendix A for more considerations on PPP 431 link characteristics and delays. 433 Admission Control MUST compute CMTU, eMTU, and eRate for Controlled 434 Load Service, and it MUST compute CMTU, eMTU, eRate, and D for 435 Guaranteed Service: 437 To determine whether the requested rate is available, Admission 438 Control MUST compute the effective rate of the request (eRate) - 439 worst case - as follows: 441 #_of_Fragments = CMTU div (FRAG-Header) [Integer divide] 442 Last_Frag_Size = CMTU mod (FRAG-Header 444 If Last_Frag_Size != 0 445 eMTU = (#_of_Fragments) * FRAG + Last_Frag_Size + Header 446 Else 447 eMTU = (#_of_Fragments) * FRAG 449 eRate = eMTU/CMTU * R [floating point divide] 451 Admission Control SHOULD compare the eRate of the request against the 452 remaining bandwidth available to determine if the requested rate can 453 be delivered. 455 For Controlled Load Service, a flow can be admitted as long as there 456 is sufficient bandwidth available (after the above computation) to 457 meet the rate requirement, and if there is sufficient buffer space 458 (sum of the token bucket sizes does not exceed the buffer capacity). 459 While some statistical multiplexing could be done in computing 460 admissibility, the nature of the low-bitrate links could make this 461 approach risky as any delay incurred to address a temporary 462 overcommitment could be difficult to amortize. 464 4.4 Error Term Calculations 466 Guaranteed Service requires the calculation of C and D error terms. C 467 is a rate-dependent error term and there are no special considerations 468 affecting its calculation in the low-speed link environment. The D 469 term is calculated from the inherent link delay (Dlink) plus the 470 potential worst case delay due to transmission of another fragment or 471 suspend/resume overhead. Thus, D should be calculated as 473 D = Dlink + FRAG/LinkRate 475 in the case of a fragementing implementation and 477 D = Dlink + pHeader + pDelay 479 for a suspend/resume implementation. 481 4.5 Scheduling Considerations 483 We may think of the link scheduler as having two parts, the first of 484 which schedules packets for transmission before passing them to the 485 second part of the scheduler -- the link level scheduler -- which is 486 responsible for fragmenting packets, mapping them to classes, and 487 scheduling among the classes. 489 In the dynamic class mapping mode of Section 3.3, when deciding which 490 class to assign a packet to, the link level scheduler should take 491 account of the sizes of other packets currently assigned to the same 492 class. In particular, packets with the tightest delay constraints 493 should not be assigned to classes for which relatively large packets 494 are in the process of being transmitted. 496 In either the dynamic or the static class mapping approach, note that 497 the link-level scheduler SHOULD control how much link bandwidth is 498 assigned to each class at any instant. The scheduler should assign 499 bandwidth to a class according to the bandwidth reserved for the sum 500 of all flows which currently have packets assigned to the class. Note 501 that in the example of Section 3.3, when packets from flows A and E 502 were assigned to the same class (class 1), the scheduler assigned more 503 bandwidth to class 1, reflecting the fact that it was carrying traffic 504 from reservations totalling 20kbit/s while the other classes were 505 carrying only 10kbit/s. 507 5. Security Considerations 509 General security considerations for MLPPP and PPP links are addressed 510 in RFC 1990 and RFC 1661, respectively. Security considerations 511 relevant to RSVP, used as the signaling protocol for integrated 512 services, are discussed in RFC 2209. 514 A specific security consideration relevant to providing quality of 515 service over PPP links appears when relying on either observed or 516 theoretical average packet expansion during admission control due to 517 bit- or byte-stuffing. Implementations based on these 518 packet-expansion values contain a potential vulnerability to denial of 519 service attacks. An adversary could intentionally send traffic that 520 will result in worst case bit- or byte stuffing packet expansion. This 521 in turn could result in quality of service guarantees not being met 522 for other flows due to overly permissive admission control. This 523 potential denial of service attack argues strongly for using a worst 524 case expansion factor in admission control calculations, even for 525 controlled load service. 527 Beyond the considerations documented above, this document introduces 528 no new security issues on top of those discussed in the companion 529 ISSLL documents [1], [2] and [3] and AVT document [4]. Any use of 530 these service mappings assumes that all requests for service are 531 authenticated appropriately. 533 6. References 535 [1] C. Bormann, "Providing integrated services over low-bitrate 536 links", Work in Progress (draft-ietf-issll-isslow-05.txt), April 537 1999. 539 [2] C. Bormann, "The Multi-Class Extension to Multi-Link PPP", 540 Work in Progress (draft-ietf-issll-isslow-mcml-05.txt), 541 April 1999. 543 [3] C. Bormann, "PPP in a real-time oriented HDLC-like framing", 544 Work in Progress (draft-ietf-issll-isslow-rtf-04.txt), 545 April 1999. 547 [4] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for 548 Low-Speed Serial Links", RFC 2508, February 1999. 550 [5] J. Wroclawski, "Specification of the Controlled-Load Network 551 Element Service", RFC 2211, September 1997. 553 [6] C. Partridge, R. Guerin, "Specification of Guaranteed Quality 554 of Service", RFC 2212, September 1997. 556 [7] S. Shenker, J. Wroclawski, "General Characterization Parameters 557 for Integrated Service Network Elements", RFC 2215, 558 September 1997. 560 [8] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links", 561 RFC 1144. 563 [9] B. Davie et al. "Integrated Services in the Presence of 564 Compressible Flows", Work in Progress 565 (draft-davie-intserv-compress-00.txt), Feb. 1999. 567 [10] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP", 568 RFC 2509, February 1999. 570 7. Authors' Addresses: 572 Steve Jackowski 573 Deterministic Networks, Inc. 574 245M Mt Hermon Rd, #140 575 Scotts Valley, CA 95060 576 USA 577 +1 (408) 813 6294 578 stevej@DeterministicNetworks.com 580 David Putzolu 581 Intel Architecture Labs (IAL) 582 JF3-206-H10 583 2111 NE 25th Avenue 584 Hillsboro, OR 97124-5961 585 USA 586 +1 (503) 264 4510 587 David.Putzolu@intel.com 589 Eric S. Crawley 590 Argon Networks, Inc. 591 25 Porter Road 592 Littleton, MA 01460 593 USA 594 esc@argon.com 595 +1 (978) 486-0665 597 Bruce Davie 598 Cisco Systems, Inc. 599 250 Apollo Drive 600 Chelmsford, MA, 01824 601 USA 602 bdavie@cisco.com 603 +1 (978) 244 8921 605 Acknowledgements 607 This document draws heavily on the work of the ISSLL WG of the IETF. 609 Appendix A. Admission Control Considerations for POTS Modems 611 The protocols used in current implementations of POTS modems can 612 exhibit significant changes in link rate and delay over the duration 613 of a connection. Admission control and link scheduling algorithms used 614 with these devices MUST be prepared to compensate for this variability 615 in order to provide a robust implementation of integrated services. 617 Link rate on POTS modems is typically reported at connection 618 time. This value may change over the duration of the connection. The 619 v.34 protocol, used in most POTS modems, is adaptive to link 620 conditions, and is able to recalibrate transmission rate multiple 621 times over the duration of a connection. Typically this will result in 622 a small (~10%) increase in transmission rate over the initial 623 connection within the first minute of a call. It is important to note, 624 however, that other results are possible as well, including decreases 625 in available bandwidth. Admission control algorithms MUST take such 626 changes into consideration as they occur, and implementations MUST be 627 able to gracefully handle the pathological case where link rate 628 actually drops below the currently reserved capacity of a link. 630 Delay experienced by traffic over POTS modems can vary significantly 631 over time. Unlike link rate, the delay often does not converge to a 632 stable value. The v.42 protocol is used in most POTS modems to 633 provide link-layer reliability. This reliability, which is implemented 634 via retransmission, can cause frames to experience significant delays. 635 Retransmissions also implicitly steal link bandwidth from other 636 traffic. These delays and reductions in link bandwidth make it 637 extremely difficult to honor a guaranteed service reservation. On a 638 link that is actually lightly or moderately loaded, a controlled load 639 service can to some extent accept such events as part of the behavior 640 of a lightly loaded link. Unfortunately, as actual link utilization 641 increases, v.42 retransmissions have the potential of stealing larger 642 and larger fractions of available link bandwidth; making even 643 controlled load service difficult to offer at high link utilization 644 when retransmissions occur.