idnits 2.17.1 draft-ietf-issll-isslow-svcmap-06.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 12 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 36 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 (February 24, 1999) is 9185 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) -- Looks like a reference, but probably isn't: 'CRTP' on line 389 == Unused Reference: '7' is defined on line 557, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-04 ** Downref: Normative reference to an Informational draft: draft-ietf-issll-isslow (ref. '1') == Outdated reference: A later version (-06) exists of draft-ietf-issll-isslow-mcml-04 == Outdated reference: A later version (-05) exists of draft-ietf-issll-isslow-rtf-03 == Outdated reference: A later version (-01) exists of draft-davie-intserv-compress-00 -- Possible downref: Normative reference to a draft: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Steve Jackowski/Deterministic Networks 2 Expires: August 1999 David Putzolu/Intel Architecture Labs 3 Eric Crawley/Argon Networks 4 Bruce Davie/Cisco Systems 5 February 24, 1999 7 Integrated Services Mappings for Low Speed Networks 8 draft-ietf-issll-isslow-svcmap-06.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all 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 50 well-known for, other types of services (``integrated services'') are 51 being developed and deployed in the Internet. These services support 52 special handling of traffic based on bandwidth, latency, and other 53 requirements that cannot usually be met using ``best-effort'' 54 service. 56 This document defines the mapping of integrated services ``controlled 57 load'' [5] and ``guaranteed'' [6] services on to low-bandwidth links. 58 The architecture and mechanisms used to implement these services on 59 such links are defined in a set of companion documents. The 60 mechanisms defined in these documents include both compression of 61 flows (for bandwidth savings) [4] and a set of extensions to the PPP 62 protocol which permit fragmentation [2] or suspension [3] of large 63 packets in favor of packets from flows with more stringent service 64 requirements. 66 1.1. Specification Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119. 72 2. End-to-end Behavior 74 Unlike other link layers, the links referred to in this document 75 operate only over low speed point to point links or connections. 76 Examples of the kinds of links addressed here include dial-up lines, 77 ISDN channels, and low-speed (1.5Mbps or less) leased lines. In this 78 context, 'end to end' simply means between two points. In typical 79 environments, this will include: 81 - host to directly connected host. 82 - host to/from network access device (router or switch). 83 - Edge device (subnet router or switch) to/from router or switch. 84 - In rare circumstances, a link from backbone router to backbone 85 router. 87 Thus, the endpoints are two network elements as described above. The 88 Controlled Load and Guaranteed services for the links addressed here 89 are applied between these elements and often represent the first or 90 last wide area hop in a true end to end service. It is important to 91 note that these links can be the most ``bandwidth constrained'' along 92 the path between two hosts. 94 The services utilized in mapping integrated services to these links 95 are only provided if both endpoints on the link support the 96 architecture and mechanisms referenced above. Support for these 97 mechanisms is determined during the PPP negotiation. The non-shared 98 nature of these links, along with the fact that point-to-point links 99 are typically dual simplex (i.e., the send and receive channels are 100 separate) allows all admission control decisions to be made locally. 102 3. Issues for Providing Controlled and Guaranteed Service 104 As described in [2] and [3], for systems which can perform 105 bit-oriented transmission control, the suspend/resume approach 106 optimizes the available bandwidth by minimizing header overhead 107 associated with MLPPP fragmentation. However, this comes at the 108 expense of scanning all incoming data looking for suspend/resume 109 control information. For systems which provide frame-oriented 110 transmission control, the fragmentation approach can be implemented 111 without scanning the incoming data stream. Choice of suspend/resume 112 versus fragmentation should be made based on the element's capability 113 to handle the new HDLC framing described in [2] and the system 114 overhead associated with byte by byte scanning (required by 115 suspend/resume). 117 To provide controlled load or guaranteed service with the 118 suspend/resume approach, when a packet for an admitted flow (QoS 119 packet) arrives during transmission of a best effort packet and 120 continued transmission of the best effort packet would violate delay 121 constraints of the QoS service flows, the best effort packet is 122 preempted, the QoS packet/fragments are added to the transmission, 123 and the best effort packet transmission is then resumed: usually all 124 in one transmission. The receiving station separates the best effort 125 packet from the embedded QoS packet's fragments. It is also 126 conceivable that one QoS flow's packet might suspend another flow's 127 packet if the delivery deadline of the new packet is earlier than the 128 current packet. 130 For systems which use fragmentation, any packets longer than the 131 maximum tolerable delay for packets from enhanced service flows are 132 fragmented prior to transmission so that a short packet for another 133 flow can be interleaved between fragments of a larger packet and 134 still meet the transmission deadline for the flow requiring enhanced 135 services. 137 Note that the fragmentation discussed in this document refers to 138 multilink PPP (MLPPP) fragmentation and associated MCMLPPP 139 modifications as described in [2], not IP or other layer 3 140 fragmentation. MLPPP fragmentation is local to the PPP link, and 141 does not affect end-to-end (IP) MTU. 143 3.1 Calculating "Acceptable Delay" for Int-serv flows 145 A router which provides Controlled Load or Guaranteed Service over a 146 low speed serial link needs to have some notion of the "acceptable 147 delay" for packets that belong to int-serv flows. If using 148 fragmentation, a router needs to know what size to fragment packets 149 to; if using suspend/resume, it needs to know when it is appropriate 150 to suspend one packet to meet the delay goals of 151 another. Unfortunately, there is no hard and fast way for a single 152 delay bound to be determined for a particular flow; while the 153 end-points of a flow have enough information to determine acceptable 154 end-to-end delay bounds and to make reservation requests of the 155 network to meet those bounds, they do not communicate a "per-hop" 156 delay to routers. 158 In the case of Guaranteed Service, one approach is to let the network 159 operator configure parameters on the router that will directly affect 160 its delay performance. We observe that guaranteed service allows 161 routers to deviate from the ideal fluid flow model and to advertise 162 the extent of the deviation using two error terms C and D, the 163 rate-dependent and rate-independent error terms. A network operator 164 can configure parameters of the low speed link in such a way that D 165 is set to a value of her choice. 167 If link-level fragmentation is used, the router controlling a 168 low-speed link can be configured with a certain fragment size. This 169 will enable a component of the error term D to be calculated based on 170 the time to send one fragment over the link. (Note that D may have 171 other components such as the speed of light delay over the link.) 172 Details of the calculation of D are described below. Similarly, if 173 suspend/resume is used, the router may be configured with a delay 174 parameter, which would enable it to decide when it was appropriate to 175 suspend a packet. 177 For Controlled Load, there are no error terms, and the router must 178 decide how best to meet the requirements of the admitted reservations 179 using only the information in their TSpecs. Since the definition of 180 Controlled Load states that a CL flow with Tspec rate r should 181 receive treatment similar to an unloaded network of capacity r, CL 182 packets should not generally experience end-to-end delays 183 significantly greater than b/r + propagation delays. Clearly a router 184 connected to a low speed link should not introduce a delay greater 185 than b/r due to transmission of other fragments; ideally it should 186 introduce substantially less delay than b/r, since other hops on the 187 end-to-end path may introduce delay as well. However, this may be 188 difficult for flows with very small values of b. 190 It is expected that implementers will make their own tradeoffs as to 191 how low to make the delay for Controlled Load flows. Similarly, it 192 may not be possible or desirable to configure the parameters 193 affecting D to arbitrarily small values, since there is a cost in 194 overhead in fragmenting packets to very small sizes. Conversely, if D 195 is too large, some applications may find that they cannot make a 196 reservation that will meet there delay objectives. 198 For the remainder of this document, we assume that a router has some 199 notion of the acceptable delay that it may introduce before beginning 200 transmission of a packet. This delay is in addition to any delay that 201 a packet might be subjected to as a result of the "ideal" queuing 202 algorithm that the router uses to schedule packets. 204 4. Controlled Load and Guaranteed Service Class Mapping 206 Supporting integrated services over PPP links which implement MCML or 207 RTF can be accomplished in several ways. Guidelines for mapping 208 these services to PPP links and to the classes provided by the 209 suspend/resume and fragmentation mechanisms are presented below. 211 4.1 Predefined Class Mappings 213 A relatively simple method of class mapping that MAY be used is one 214 where class values correspond to predefined levels of service. In 215 this arrangement, all admitted flows are grouped into one of several 216 buckets, where each bucket roughly corresponds to the level of 217 service desired for the flows placed in it. An example set of 218 mappings appears below: 220 MCML Short MCML Long RTF Service 222 0b00 0b0000 0b000 Best Effort 223 0b01 0b0001 0b001 Reserved 224 0b10 0b0010 0b010 Delay Sensitive, no bound 225 NA 0b0011 0b011 Reserved 226 NA 0b0100 0b100 Reserved 227 NA 0b0101 0b101 Delay Sensitive, 500ms bound 228 NA 0b0110 0b110 Delay Sensitive, 250ms bound 229 0b11 0b0111 0b111 Network Control 231 Table 1: Example Mappings of Classes to Services 233 Note that MCML has two formats, short sequence numbers, and long 234 sequence numbers, that allow for 2 and 4 bits of class 235 identification. RTF allows for 3 bits of class identification in all 236 formats. 238 Using a default-mapping method of assigning classes to flows in a 239 fixed fashion comes with certain limitations. In particular, all 240 flows which fall within a particular bucket (are assigned to a 241 particular class) will be scheduled against each other at the 242 granularity of packets, rather than at the finer grained level of 243 fragments. This can result in overly conservative admission control 244 when the number of available classes is small such as in MCML short 245 sequence number format. 247 4.2 Predefined Class Mappings and Prefix Elision 249 In the case where fewer reservations are expected than the total 250 number of classes negotiated for a PPP link, it is possible to assign 251 individual flows to fixed class numbers. This assignment is useful in 252 the case where the protocol identifier associated with one or more 253 flows is known at LCP negotiation time and the bandwidth of the 254 connection is relatively small. If these conditions hold true, then 255 for those flows that are known, a specific class can optionally be 256 assigned to them and the prefix elision PPP option can be used for 257 those classes to achieve a small bandwidth savings. 259 4.3 Dynamic Class Mappings 261 In the case where predefined class mappings are not satisfactory, an 262 implementer MAY map class values to individual packets rather than 263 assigning flows to fixed classes. This can be done due to the fact 264 that the classes that MCML and RTF provide can be viewed purely as 265 PPP-specific segmentation/fragmentation mechanisms. That is, while 266 the class number MUST remain constant on an intra-packet basis, it 267 MAY vary on an inter-packet basis for all flows transiting a PPP 268 link. Actual assignment of particular flows to fixed classes is 269 unnecessary, as the class numbers are NOT REQUIRED to have any 270 meaning other than in the context of identifying the membership of 271 fragments/segments as part of a single packet. This point is 272 sufficiently important that an example is provided below. 274 Consider a PPP link using the MCML short sequence number fragment 275 format (that is, four classes are provided). Assume that in addition 276 to carrying best effort traffic, this link is carrying five 277 guaranteed service flows, A, B, C, D, and E. Further assume that the 278 link capacity is 100kbit/s and the latency is 100ms. Finally, assume 279 the BE traffic is sufficient to keep the pipe full at all times and 280 that GS flows A-E are each 10kbit/s and all have delay bounds of 281 145ms. 283 Time(ms) Action 284 0 BE traffic is queued up 285 0 2kbit fragment from 10kbit packet of BE traffic sent, cls 0 (...) 286 8 2kbit fragment from BE sent, cls 0 (10kbit BE packet done) 287 9 8kbit packet from flow A arrives 288 10 2kbit fragment from A sent, cls 1 (8kbit flow A packet start) 289 11 8kbit packet from flow B arrives 290 12 2kbit fragment from B sent, cls 2 (8kbit flow B packet start) 291 13 8kbit packets from flows C, D, and E arrive 292 14 2kbit fragment from C sent, cls 3 (8kbit flow C packet start) 293 16 2kbit fragment from D sent, cls 0 (8kbit flow D packet start) 294 18 2kbit fragment from A sent, cls 1 295 20 2kbit fragment from B sent, cls 2 296 22 2kbit fragment from A sent, cls 1 297 24 2kbit fragment from A sent, cls 1 (8kbit flow A packet done) 298 26 2kbit fragment from E sent, cls 1 (8kbit flow E packet start) 299 27 8kbit packet from flow A arrives 300 28 2kbit fragment from B sent, cls 2 301 30 2kbit fragment from C sent, cls 3 302 32 2kbit fragment from E sent, cls 1 303 34 2kbit fragment from B sent, cls 2 (8kbit flow B packet done) 304 36 2kbit fragment from E sent, cls 1 305 38 2kbit fragment flow A sent, cls 2 (8kbit flow A packet start) 306 (etc.) 308 This example shows several things. First, multiple flows MAY share 309 the same class, particularly in the case where there are more flows 310 than classes. More importantly, there is no reason that a particular 311 flow must be assigned to a fixed class - the only requirement is that 312 each packet, when fragmented, MUST have the same class value assigned 313 to all fragments. Beyond this requirement the link scheduler may 314 assign individual to changing class numbers as necessary to meet 315 reservation requirements. 317 One suggestion to implementers of integrated services on MCML and RTF 318 links using dynamic mappings is that all BE traffic SHOULD be 319 logically separated from QoS traffic, and mapped to a fragmentable 320 (MCML classes 0-3 in short sequence number fragment format, 0-15 in 321 long sequence number fragment format) or suspendable (RTF classes 322 0-6) class. Since BE traffic will in most implementations not be 323 scheduled for transmission except when a link is empty (that is, no 324 CL or GS traffic is ready for transmission), implementers MAY choose 325 to use of class number 0 for BE traffic. 327 4.4 Non-Conformant Traffic 329 Treatment of non-conformant QoS traffic is largely determined by the 330 appropriate service specifications, but the detailed implementation 331 in the context of this draft allows for some flexibility. Policing 332 of flows containing non-conformant traffic SHOULD always be done at 333 the level of granularity of individual packets rather than at a finer 334 grained level. In particular, in those cases where a network element 335 scheduling flows for transmission needs to drop non-conformant 336 traffic, it SHOULD drop entire packets rather than dropping 337 individual fragments of packets belonging to non-conformant traffic. 338 In those cases where a network element forwards non-conformant 339 traffic when link bandwidth is available rather than dropping the 340 traffic, the implementation SHOULD fragment packets of such traffic 341 as if it were best effort traffic. 343 Whether BE and non-conformant traffic are treated differently in 344 regards to transmission (e.g., BE is given priority access over 345 non-conformant traffic to the link) or whether within each type of 346 traffic special treatment is afforded to individual flows (e.g., WFQ, 347 RED, etc.) is service dependent. 349 5. Guidelines for Implementers 351 5.1. PPP Bit and Byte Stuffing Effects on Admission Control 353 An important consideration in performing admission control for PPP 354 links is reductions in effective link rate due to bit 355 stuffing. Typical bit stuffing algorithms can result in as much as 20% 356 additional overhead. Thus, admission control implementations for 357 guaranteed service over links where bit stuffing is used SHOULD take 358 the RSpec rate of all flows and multiply by 1.2 in determining whether 359 a new flow can be admitted or not. Admission control implementations 360 for controlled load reservations may use a similar algorithm using the 361 TSpec peak rate or may attempt to measure the actual degree of 362 expansion occurring on a link due to bit stuffing. This 363 characterization can then be used to adjust the calculated remaining 364 link capacity. Such measurements must be used cautiously, in that the 365 degree of bit stuffing that occurs may vary significantly, both in an 366 inter- and intra-flow fashion. 368 Byte stuffing is also used on many PPP links, most frequently on POTS 369 modems when using the v.42 protocol. Byte stuffing poses a difficult 370 problem to admission control, particularly in the case of guaranteed 371 service, due to its highly variable nature. In the worse case, byte 372 stuffing can result in a doubling of frame sizes. As a consequence, a 373 strict implementation of admission control for guaranteed load on 374 byte stuffed PPP links SHOULD double the RSpec of link traffic in 375 making flow admission decisions. As with bit stuffing, 376 implementations of controlled load service admission control 377 algorithms for links with byte stuffing MAY attempt to determine 378 average packet expansion via observation or MAY use the theoretical 379 worst case values. 381 5.2. Compression Considerations 383 The architecture for providing integrated services over low bandwidth 384 links uses several PPP options to negotiate link configuration as 385 described in [4, 8]. When deciding whether to admit a flow, 386 Admission Control MUST compute the impact of the following on MTU 387 size, rate, and fragment size: 389 Header compression: Van Jacobson or Casner-Jacobson [CRTP]. 390 Prefix Elision. 391 CCP. 392 Fragment header option used. 393 Fragmentation versus suspend/resume approach. 395 If any of the compression options are implemented for the connection, 396 the actual transmission rate, and thus the bandwidth required of the 397 link, will be reduced by the compression method(s) used. 399 Prefix elision can take advantage of mapping flows to MLPPP classes 400 to elide prefixes which cannot be compressed at higher layers. By 401 establishing agreement across the link, the sender may elide a prefix 402 for a certain class of traffic and upon receiving packets in that 403 class, the receiver can restore the prefix. 405 Both compression gain and elision gain MUST be included as described 406 in the admission control section below. Note that the ability to 407 perform compression at higher layers (e.g. TCP or RTP/UDP) may depend 408 on the provision of a hint by the sender, as described in [9]. 410 5.3. Admission Control 412 Admission Control MUST decide whether to admit a flow based on rate 413 and delay. Assume the following: 415 LinkRate is the rate of the link. 416 MTU is the maximum transmission unit from a protocol. 417 MRU is the maximum receive unit for a particular link. 418 CMTU is the maximum size of the MTU after compression is applied. 419 eMTU is the maximum effective size of the MTU after fragmentation. 420 FRAG is the fragment size including MLPPP header/trailers. 421 Header is the size of the header/trailers/framing for MLPPP/Fragments. 422 pHeader is the additional header/framing overhead associated with 423 suspend/resume. This should include FSE and worst case stuffing 424 overhead. 425 pDelay is the delay associated with suspend/resume packets. 426 b is the bucket depth in bytes 427 R is the requested Rate. 428 Dlink is the fixed overhead delay for the link (Modem, DSU, 429 speed-of-light, etc). 430 eRate is the effective rate after compression and fragmentation. 432 The Dlink term MAY be configured by an administrative tool once the 433 network is installed; it may be determined by real-time measurement 434 means; or it MAY be available from hardware during link setup and/or 435 PPP negotiation. Refer to Appendix A for more considerations on PPP 436 link characteristics and delays. 438 Admission Control MUST compute CMTU, eMTU, and eRate for Controlled 439 Load Service, and it MUST compute CMTU, eMTU, eRate, and D for 440 Guaranteed Service: 442 To determine whether the requested rate is available, Admission 443 Control MUST compute the effective rate of the request (eRate) - 444 worst case - as follows: 446 #_of_Fragments = (CMTU + FRAG)/(FRAG-Header) 447 eMTU = (#_of_Fragments) * FRAG 448 eRate = eMTU/CMTU * R 450 Admission Control SHOULD compare the eRate of the request against the 451 remaining bandwidth available to determine if the requested rate can 452 be delivered. 454 For Controlled Load Service, a flow can be admitted as long as there 455 is sufficient bandwidth available (after the above computation) to 456 meet the rate requirement, and if there is sufficient buffer space 457 (sum of the token bucket sizes does not exceed the buffer capacity). 458 While some statistical multiplexing could be done in computing 459 admissibility, the nature of the low-bitrate links could make this 460 approach risky as any delay incurred to address a temporary 461 overcommitment could be difficult to amortize. 463 5.4 Error Term Calculations 465 Guaranteed Service requires the calculation of C and D error terms. C 466 is a rate-dependent error term and there are no special 467 considerations affecting its calculation in the low-speed link 468 environment. The D term is calculated from the inherent link delay 469 (Dlink) plus the potential worst case delay due to transmission of 470 another fragment or suspend/resume overhead. Thus, D should be 471 calculated as 473 D = Dlink + FRAG/LinkRate 475 in the case of a fragmenting implementation and 477 D = Dlink + pHeader + pDelay 479 for a suspend/resume implementation. 481 5.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 4.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 currently assigned to the class. Note that in the 501 example of Section 4.3, when packets from flows A and E were assigned 502 to the same class (class 1), the scheduler assigned more bandwidth to 503 class 1, reflecting the fact that it was carrying traffic from 504 reservations totaling 20kbit/s while the other classes were carrying 505 only 10kbit/s. 507 6. 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 519 of service attacks. An adversary could intentionally send traffic 520 that will result in worst case bit- or byte stuffing packet 521 expansion. This in turn could result in quality of service guarantees 522 not being met for other flows due to overly permissive admission 523 control. This potential denial of service attack argues strongly for 524 using a worst case expansion factor in admission control 525 calculations, even for 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 7. References 535 [1] C. Bormann, ``Providing integrated services over low-bitrate 536 links'', Work in Progress (draft-ietf-issll-isslow-04.txt), 537 August 1998. 539 [2] C. Bormann, ``The Multi-Class Extension to Multi-Link PPP'', 540 Work in Progress (draft-ietf-issll-isslow-mcml-04.txt), 541 August 1998. 543 [3] C. Bormann, ``PPP in a real-time oriented HDLC-like framing'', 544 Work in Progress (draft-ietf-issll-isslow-rtf-03.txt), 545 August 1998. 547 [4] S. Casner, V. Jacobson, ``Compressing IP/UDP/RTP Headers for 548 Low-Speed Serial Links'', Work in Progress (draft-ietf-avt- 549 crtp-05.txt), July 1998. 551 [5] J. Wroclawski, ``Specification of the Controlled-Load Network 552 Element Service'', RFC 2211, September 1997. 554 [6] C. Partridge, R. Guerin, ``Specification of Guaranteed Quality 555 of Service'', RFC 2212, September 1997. 557 [7] S. Shenker, J. Wroclawski, ``General Characterization Parameters 558 for Integrated Service Network Elements'', RFC 2215, 559 September 1997. 561 [8] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," 562 RFC 1144. 564 [9] B. Davie et al. "Integrated Services in the Presence of 565 Compressible Flows", Work in Progress 566 (draft-davie-intserv-compress-00.txt), Feb. 1999. 568 8. Authors' Addresses: 570 Steve Jackowski 571 Deterministic Networks, Inc. 572 245M Mt Hermon Rd, #140 573 Scotts Valley, CA 95060 574 USA 575 +1 (408) 813 6294 576 stevej@DeterministicNetworks.com 578 David Putzolu 579 Intel Architecture Labs (IAL) 580 JF3-206-H10 581 2111 NE 25th Avenue 582 Hillsboro, OR 97124-5961 583 USA 584 +1 (503) 264 4510 585 David.Putzolu@intel.com 587 Eric S. Crawley 588 Argon Networks, Inc. 589 25 Porter Road 590 Littleton, MA 01460 591 USA 592 esc@argon.com 593 +1 (978) 486-0665 595 Bruce Davie 596 Cisco Systems, Inc. 597 250 Apollo Drive 598 Chelmsford, MA, 01824 599 USA 600 bdavie@cisco.com 601 +1 (978) 244 8921 603 Acknowledgements 605 This document draws heavily on the work of the ISSLL WG of the IETF. 607 Appendix A. Admission Control Considerations for POTS Modems 609 The protocols used in current implementations of POTS modems can 610 exhibit significant changes in link rate and delay over the duration 611 of a connection. Admission control and link scheduling algorithms 612 used with these devices MUST be prepared to compensate for this 613 variability in order to provide a robust implementation of integrated 614 services. 616 Link rate on POTS modems is typically reported at connection 617 time. This value may change over the duration of the connection. The 618 v.34 protocol, used in most POTS modems, is adaptive to link 619 conditions, and is able to recalibrate transmission rate multiple 620 times over the duration of a connection. Typically this will result 621 in a small (~10%) increase in transmission rate over the initial 622 connection within the first minute of a call. It is important to 623 note, however, that other results are possible as well, including 624 decreases in available bandwidth. Admission control algorithms MUST 625 take such changes into consideration as they occur, and 626 implementations MUST be able to gracefully handle the pathological 627 case where link rate actually drops below the currently reserved 628 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.