idnits 2.17.1 draft-wang-diff-serv-usd-00.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-25) 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 10) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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 is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 247 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Nov 1997) is 9658 days in the past. Is this intentional? 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: '1' is defined on line 389, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 396, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Zheng Wang 3 Internet Draft Bell Labs Lucent Technologies 4 Expiration: May 1998 Nov 1997 6 User-Share Differentiation (USD) 7 Scalable bandwidth allocation for differentiated services 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the 1id-abstracts.txt listing contained in the 23 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 24 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 25 current status of any Internet Draft. 27 Table Of Contents 29 1. Introduction ........................................ 2 30 2. Objective ........................................... 2 31 3. Related Proposals ................................... 3 32 4. User-Share Differentiation (USD) .................... 4 33 4.1. Overview .......................................... 5 34 4.2. Per-User Traffic Isolation ........................ 5 35 4.3. Flexible Aggregation .............................. 6 36 4.4. Bottleneck Sharing ................................ 6 37 4.5. Application Marking ............................... 7 38 4.6. Implementation and Deployment ..................... 8 39 5. Standardization Issues .............................. 8 40 6. Acknowledgments ..................................... 9 41 7. References .......................................... 9 42 1. Introduction 44 In this memo, we present a new differentiated service scheme called 45 ''User-Share Differentiation (USD)''. The USD scheme is based on the 46 principle of link sharing. The scheme allows ISPs to differentiate 47 traffic flows on a per-user basis, providing minimum bandwidth guar- 48 antee and share-based bandwidth sharing. We first look at the objec- 49 tives of differentiated services, and the problems with the current 50 proposals, then present the details of the USD scheme. Finally we 51 examine the implementation and standardization issues 53 2. Objective 55 The current Internet is built on the best-effort model where all 56 packets are treated as independent datagrams and are serviced on a 57 FIFO basis. The best effort model does not provide any form of traf- 58 fic isolation inside the network and the sharing of the resources 59 essentially depends on how much users ask for. Therefore the cooper- 60 ation of the end systems (such as TCP congestion control mechanisms) 61 is vital to make the system work. In today's Internet, however, such 62 dependence on the end systems' cooperation is increasingly becoming 63 unrealistic. Inevitably, some people start to exploit the weakness of 64 the current best effort model to gain more resource (e.g., Netscape 65 browsers allow users to open multiple TCP connections). Another prob- 66 lem with the best effort model is that it is difficult to make any 67 guarantee, either explicit (e.g., x bps bandwidth) or relative (e.g., 68 a service package 5 times better than another package) as all traffic 69 is aggregated into a single flow. 71 The problems with the best effort model have been long recognized. 72 For the last a couple of years, QoS provision has been one of the 73 hottest areas in networking research, and various aspects of the 74 issue have been extensively studied including traffic analysis, 75 admission control, resource reservation, scheduling, QoS routing, and 76 operating system support. The architectures of various proposed 77 solutions differ in details. Nevertheless, the underlying model is 78 similar. Generally, applications make resource reservation on an 79 end-to-end session basis. In the internet community, RSVP and INT- 80 SERV are examples of protocols and service models based on this end- 81 to-end approach. However, research and experience have shown a number 82 of difficulties in deploying end-to-end reservation in the global 83 Internet. The lacking of accounting support, the high administrative 84 overheads, and the complexity of inter-ISP settlement make it diffi- 85 cult for end-to-end reservation to be widely deployed. There are also 86 scalability concerns for fine granularity classification and per- 87 session signaling. 89 The best effort model and the end-to-end model represent the two 90 extremes of the spectrum. The best effort model does no traffic iso- 91 lation at all whilst the end-to-end model provides isolation on the 92 finest granularity (an end-to-end session identified by the 5-tuple). 93 The solution may, therefore, lie somewhere in between the two 94 extremes. For differentiated services, the general approach is to 95 deal with the problem of QoS provision through long-term contract- 96 based service allocation rather than per-session reservation. The key 97 to achieve that is to choose a proper level of granularity for traf- 98 fic isolation that satisfies users' and ISPs' needs, and is also 99 scalable in a global Internet. We also need a solution that can offer 100 immediate help to ISPs, and impose minimum conditions on ISPs' busi- 101 ness models and network infrastructures, yet is flexible to allow 102 further development as the Internet evolves. 104 3. Related Proposals 106 A number of proposals that have been put forward for differentiated 107 services fall into two groups: drop priority based and delay priority 108 based. In this section, we discuss some of the problems with the 109 related proposals. 111 Profile-Based Tagging 113 The profile-based tagging scheme uses drop priority in conjunction 114 with an admission control mechanism. In the scheme, a user and its 115 ISP agree on a profile, and the traffic flowing into the ISP is 116 checked at the entry points [2]. When the traffic exceeds the pro- 117 file, the packets are let through but tagged. When there is conges- 118 tion inside the network, the routers start to discard tagged packets 119 first. 121 One issue is how to determine a profile for a user. When a network 122 does not have uniform bandwidth provisioning, profiles are likely to 123 be destination-specific. For example, suppose that an ISP has a link 124 to a neighbor ISP with a capacity 600 Mbps and a link to the Internet 125 backbone with a capacity of 100 Mbps. If a user is communicating 126 with another user in the neighbor ISP, the user can have a rate limit 127 of 6 Mbps but only 1 Mbps if the user's traffic goes through the 128 backbone access link. In this case, a profile of either 6 Mbps or 1 129 Mbps is not appropriate for the user. When an ISP have multiple bot- 130 tleneck links with different bandwidth provision, it is difficult to 131 choose a fixed profile for a user. 133 Another problem is to do with reserve traffic, i.e., the traffic that 134 comes from the server towards the user, as it is the case in most 135 web-based traffic. With reverse traffic, tagging packets at the 136 user-ISP boundary has little effects. 138 The profile-based tagging only provides limited protection against 139 mis-behaving source. Since profile-based tagging essentially creates 140 two classes: tagged and un-tagged, the network deals with the tagged 141 packets in a FIFO fashion. A misbehaving source can still gain more 142 bandwidth by injecting excessive traffic. The problem can be aggra- 143 vated when the fixed profiles are significantly over (or below) the 144 level appropriate for the congested links. In such a case, the major- 145 ity of the packets are not tagged (or tagged). Thus the tagging pro- 146 vides little information to enforce differentiation, and network 147 behavior will be close to simple FIFO best effort. 149 Delay Priority Differentiation 151 In a delay priority based scheme, users are classified into two or 152 more classes 1, 3]. When the traffic enters the network, the packets 153 will be set with appropriate delay priority. Under congestion, the 154 packets with higher priority are transmitted prior to the ones with 155 lower priority. 157 Delay priority schemes represent an extreme form of resource alloca- 158 tion, where lower priority classes suffer all the consequences of 159 congestion. Unless the priority traffic only accounts for a very 160 small percentage of the link capacity, lower class traffic may expe- 161 rience significant deterioration under congestion, and may be com- 162 pletely starved from any bandwidth. In fact, TCP has the tendency to 163 grab as much bandwidth as it can. Because the congestion is invisible 164 to the upper class, the network will no longer to provide any conges- 165 tion signal for the upper class traffic. The TCP windows in upper 166 class flows may grow to take up all bandwidth and starve the lower 167 class traffic completely. 169 Delay priority schemes provide isolation between different classes. 170 Within a single class, however, there is no traffic isolation and 171 therefore there is no protection against misbehaving users. Like the 172 profile-based tagging, delay priority schemes also have problems with 173 reverse traffic where setting priority has to be done close to the 174 sources rather than the users. 176 4. User-Share Differentiation (USD) 178 In this section, we present User-Share Differentiation (USD), a scal- 179 able bandwidth allocation scheme for differentiated services, and 180 discuss the key design principles behind the scheme. 182 4.1. Overview 184 In USD, we treat the problem of service allocation as a form of 185 resource sharing: an ISP as a pool of bandwidth resources shared by 186 multiple users. The sharing of the bandwidth resource is controlled 187 with two parameters, user and share. A user is the entity to which 188 the resource is allocated and the share quantifies the amount of 189 resource allocated to a user. 191 At the time when a user subscribes to its ISP for Internet services, 192 the ISP determines the share for the user based on what the user has 193 asked for or the package the user selects. The USD scheme can guar- 194 antee that: 196 1) The user will have a minimum mount of bandwidth on all or some of 197 the links in the ISP 199 2) For the bandwidth over the minimum amount, the user shares the 200 bandwidth with other users in proportion to its allocated share 202 For example, suppose that user A and B ask for 2 Mbps and 10 Mbps mini- 203 mum bandwidth respectively, and the ISP allocates share of 1000 and 5000 204 to the two users in return. The USD scheme guarantees that user A and B 205 have 2 Mbps and 10 Mbps minimum bandwidth, and for bandwidth over the 206 minimum, the allocation to user A and B follows the ratio of 1:5. 208 We now discuss the key design decisions behind the USD scheme. 210 4.2. Per-User Traffic Isolation 212 As we discussed early, the objective of the differentiated services 213 is to find a granularity that meets users' and ISP's needs and is 214 also scalable. When there is contention of resources, we must deter- 215 mine a rule for allocating limited resources to multiple users. In a 216 commercial Internet, we believe that the rule has to be based on the 217 contracts between the ISP and its users. 219 In USD, we choose "user" as the basic working unit that defines the 220 granularity. A user is the entity with whom the service contract is 221 signed, and it can be a dial-up customer, or one corporate network or 222 a group of individual customers or networks. In USD, all traffic 223 originated from or destined to a user is aggregated into a single 224 flow. 226 The per-user granularity within an ISP strikes a good balance between 227 aggregation and isolation. It provides real traffic isolation 228 between different users yet it does not have to deal with individual 229 sessions/flows within the per-user aggregated flow. Thus, the alloca- 230 tion can be done at the subscription time and on a long-term basis. 232 The USD scheme creates a hierarchical management structure. Inside 233 an ISP's network, the traffic which belongs to a user is guaranteed 234 by the ISP according to the user-ISP contract. Within its share of 235 the bandwidth, the user manages its own sessions/flows and decides 236 how the resources should be utilized. 238 Per-user traffic isolation provides full protection against mis- 239 behaving users. If a mis-behaving user ignores the congestion signal, 240 and continues to send traffic at high rates, it can only hurt itself. 241 It gives a strong incentive for users to deploy intelligent control 242 congestion mechanisms and make the best use of its allocated share of 243 bandwidth. 245 4.3. Flexible Aggregation 247 As the definition of a user changes when traffic goes across ISP 248 boundaries, the level of traffic aggregation also changes accord- 249 ingly. For example, dial-up customers typically are users of a retail 250 ISP, and the retail ISP in turn becomes a user of a backbone ISP. 251 Within the retail ISP, traffic from or to a dial-up user is aggre- 252 gated whilst in the backbone only the retail ISP is visible. Such 253 variable level of aggregation ensures a great deal of scalability. In 254 general, when packets are close to the source ISP, the sender's allo- 255 cation has most influence and when the packets move close to the des- 256 tination, the receiver's allocation becomes more important. 258 Incorporating the concept of user into traffic isolation provides a 259 very flexible tool for ISPs to choose the level of traffic aggrega- 260 tion they want. Note that a user can represent one dial-up customer, 261 or one corporate network or a group of individual customers or net- 262 works. While the maximum granularity is per customer, ISPs can 263 achieve different levels of aggregation by creating user classes. 264 For example, an ISP may create 3 user classes: premium users, basic 265 users and best-effort users. The USD scheme will allow the ISP to 266 guarantee bandwidth allocation to the three classes. 268 4.4. Bottleneck Sharing 270 As we discussed in the previous section, admission control at the 271 user-ISP boundaries does not work very well since a fixed profile can 272 not cater for multiple bottlenecks with different sizes. Essentially, 273 each user needs to have multiple profiles for different bottlenecks. 274 For this reason, we believe that bandwidth allocation should be done 275 at the bottleneck links instead of the edges. In USD, we use share- 276 based allocation scheme that works both for minimum bandwidth alloca- 277 tion and proportional bandwidth sharing. 279 To allocate bandwidth of a single link to multiple users, we can 280 describe the allocation with actual bandwidth or as relative sharing. 281 For example, suppose that an ISP has 4 users A, B, C and D, sharing 282 an access link of 30 Mbps. The agreed allocation is 4 Mbps, 6 Mbps, 283 8 Mbps and 12 Mbps respectively. This allocation can be described 284 with the actual bandwidth, 4 Mbps, 6 Mbps, 8 Mbps and 12 Mbps. 285 Alternatively, the allocation can also be expressed with relative 286 sharing, 2:3:4:6. When the bandwidth is allocated in proportion to 287 the relative sharing, the two representation leads to the same band- 288 width allocation. 290 However, the relative sharing representation has a number of advan- 291 tage. First of all, it can guarantee the same minimum bandwidth 292 allocation as an explicit allocation does. In addition to that, it 293 allows the bandwidth above the minimum to be shared in proportion to 294 the minimum allocation. For example, suppose that user A and B in the 295 previous example are not using their allocated bandwidth during a 296 period. Now user C and D can share the extra bandwidth in proportion 297 to their relative ratio. The final allocation to user C and D 298 becomes 12 Mbps and 18 Mbps. Most importantly, the relative sharing 299 representation allows proportional allocation on multiple bottle- 300 necks. 302 More importantly, the relative sharing representation works works 303 well with multiple bottlenecks with different bandwidth provision. 304 For example, suppose the ISP of the 4 users has another link with 600 305 Mbps bandwidth. the 4 users who have shares of 2, 3, 4, and 6 will 306 have minimum guaranteed bandwidth automatically scaled up to 80 Mbps, 307 120 Mbps, 160 Mbps and 240 Mbps respectively. 309 The relative sharing can be viewed as a flexible profile as it scales 310 up and down according to the bandwidth available whilst guaranteeing 311 the minimum bandwidth. In practice, the unit of share can be defined 312 as certain bandwidth so that the share for a user can be easily 313 derived from the minimum bandwidth allocated. For example, if we 314 define the unit of share is 1 Kbps, a user with 4 Mbps minimum band- 315 width has a share of 4000. 317 4.5. Application Marking 319 As we discussed before, USD provides traffic isolation on a per-user 320 basis, and does not manage flows/sessions within the per-user aggre- 321 gated flow. However, a user or an application may indicate 322 preferences or the nature of the packets through application marking. 323 For example, a user may prioritize its traffic or an application may 324 mark some packets as important thus should be last dropped. 326 It is important to note that the use of packet marking here is very 327 different from that in profile-based tagging and priority-based 328 schemes, where packet marking is used for admission control and traf- 329 fic isolation. The in/out profile bit or the delay class are primar- 330 ily used to enforce the contractual agreement. When packets enter a 331 new ISP, packets may be re-tagged or re-classified based on the new 332 contractual agreement. 334 In application marking, the drop priority or the delay priority 335 reflect only users' preferences and application characteristics and 336 allow the network make application-friendly actions. How the packets 337 are marked are entirely decided by the users and the applications, 338 and the marking is meaningful only among the flows of the same user. 340 Traffic isolation and application marking can be viewed as two levels 341 of traffic management in USD. Traffic isolation guarantees bandwidth 342 sharing among different users, and the application marking allows a 343 user to manage its own traffic flows. 345 4.6. Implementation and Deployment 347 To support USD, routers need to implement a scheduler that is capable 348 of enforcing proportional bandwidth sharing. There is a wide range of 349 scheduling algorithms that can provide such functions. Examples of 350 such schedulers include Class-Based Queuing (CBQ) [4], a scheduling 351 algorithm originally designed for hierarchical link sharing, Weighted 352 Fair Queuing (WFQ), one of the most studied scheduling algorithms in 353 recent years [9]. Although the original WFQ is expensive to imple- 354 ment, several variations of WFQ have been proposed that support band- 355 width sharing in similar fashion but are optimized for software and 356 hardware implementation [5, 6, 7, 8]. Some of the algorithms can emu- 357 late WFQ closely with O(1) complexity [8]. A complete analysis of 358 those algorithms and buffer management can be found in [5, 10]. 360 USD enforces bandwidth sharing locally on the bottleneck links. Thus 361 it does not require any changes to the end systems and any admission 362 control at the user-ISP boundaries. Consequently, USD can be 363 deployed an incremental fashion. In fact, routers can be upgraded to 364 support USD individually and each upgrade gives incremental improve- 365 ment to the whole network. For example, when USD is installed on the 366 router connected to the access link to the backbone, bandwidth allo- 367 cation is enforced immediately for all traffic that going through the 368 access link. 370 Moreover, USD only needs to be deployed at the points in the network 371 that are heavily congested. Once bandwidth sharing is enforced at 372 those points, other links may not require further policing. 374 5. Standardization Issues 376 Very little of USD needs to be standardized. One addition to the cur- 377 rent system is the distribution of user IDs and its associated shares 378 to the routers. This can be achieved through network management such 379 as SNMP. Therefore, we need to agree on a common MIB for network man- 380 agement systems to install user-specific shares on the routers. 382 6. Acknowledgments 384 I would like to thank G. Armitage, T. V. Lakshman, S. Mithal, D. 385 Stiliadis, B. Suter for their feedback and discussion. 387 7. References 389 [1] K. Kilkki, "Simple Integrated Media Access," Internet 390 Draft, June 1997, 392 [2] D. Clark, J. Wroclawski, "An Approach to Service Allocation 393 in the Internet," Internet Draft, July 1997, 394 396 [3] P. Ferguson, "Simple Differential Services: IP TOS and 397 Precedence, Delay Indication, and Drop Preference," 398 Internet Draft, Nov 1997, 400 [4] S. Floyd, and V. Jacobson, "Link-sharing and Resource Management 401 Models for Packet Networks," IEEE/ACM Transactions on Networking, 402 Vol. 3 No. 4, August 1995. 404 [5] D. Stiliadis, "Traffic Scheduling in Packet Switched Networks: 405 Analysis, Design and Implementation," Ph.D. Thesis, UC Santa 406 Cruz, June 1996, 407 410 [6] S. Golestani, "A self-clocked fair queuing scheme for broadband 411 applications," IEEE INFOCOM'94, pp. 636-646, April, 1994. 413 [7] J. Bennett and H. Zhang, "WF2Q: Worst-acse fair weighted fair 414 queuing," IEEE INFOCOM'96, March 1996. 416 [8] M. Shreedhar and G. Varghese, "Efficient Fair Queueing using 417 Deficit Round Robin," ACM SIGCOMM'95, Sept 1995. 418 420 [9] A. K. Parekh, R. G. Gallager, "A generalized processor sharing 421 apporach to flow control - the single node case", IEEE 422 INFOCOM'92, Vol 2, pp 915-924, May 1992. 424 [10] B. Suter, T. V. Lakshman, D. Stiliadis, A. Choudhury, "Efficient 425 Active Queue Management for Internet Routers", submitted to INTEROP, 426 November 1997 428 Authors' Address: 430 Zheng Wang 431 Bell Labs Lucent Technologies 432 101 Crawfords Corner Road 433 Holmdel, NJ 07733 434 Email: zhwang@dnrc.bell-labs.com