idnits 2.17.1 draft-morita-tsvwg-pps-01.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: ---------------------------------------------------------------------------- ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 810 has weird spacing: '...ing for probe...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 2003) is 7498 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) -- Looks like a reference, but probably isn't: '1' on line 15 -- Looks like a reference, but probably isn't: '2' on line 60 -- Looks like a reference, but probably isn't: '3' on line 340 -- Looks like a reference, but probably isn't: '4' on line 340 -- Looks like a reference, but probably isn't: '5' on line 560 -- Looks like a reference, but probably isn't: '6' on line 560 -- Possible downref: Non-RFC (?) normative reference: ref. 'A1' -- Possible downref: Non-RFC (?) normative reference: ref. 'A2' -- Possible downref: Non-RFC (?) normative reference: ref. 'A3' -- Possible downref: Non-RFC (?) normative reference: ref. 'A4' -- Possible downref: Non-RFC (?) normative reference: ref. 'A5' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSV working group 3 Internet Draft Naotaka MORITA 4 Document: draft-morita-tsvwg-pps-01.txt NTT Corporation 5 Gunnar KARLSSON 6 KTH 7 Expires: April 2004 October 2003 9 Framework of Priority Promotion Scheme 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The Priority Promotion Scheme (PPS) is a new scheme for traffic 33 control; more specifically, PPS involves applying a kind of admission 34 control to achieve end-to-end QoS for a series of packets on a 35 packet-based network. The main targets are interactive multimedia 36 services such as VoIP, video chat, and video conferencing. The 37 scheme is based on end-to-end measurement of network resources by end 38 systems. Before a session is established or even during a session, 39 the source end system senses, measures, or probes the availability of 40 network resources by sending out packets with priority one level 41 lower than that of normal packets. The result is modification of the 42 DiffServ Code Point (DSCP) value of the succeeding IP packets: the 43 priority is raised or promoted to firmly establish the session, 44 lowered to leave resources with existing sessions, or otherwise 45 adjusted so that the amount of packets does not exceed the available 46 capacity. The network, i.e., output links of the routers or L2 47 switches is only assumed to support the per-class form of priority 48 control that accompanies the DiffServ architecture. Having all end 49 systems follow the above behavior achieves end-to-end QoS without the 50 maintenance of per-flow state in each item of network equipment. 52 This document describes the reasons for the end-to-end measurement- 53 based approach and the general network architecture of PPS. 55 Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC-2119 [2]. 61 Table of Contents 63 1. Introduction...................................................3 64 2. The target service type - interactive multimedia...............3 65 3. Motivation for the focus on an end-system-oriented measurement- 66 based approach....................................................5 67 4. Basic procedure for the Priority Promotion Scheme..............6 68 4.1 Basic procedure for end systems............................6 69 4.2 Router behavior............................................7 70 4.3 Variation of measurement-based mechanisms..................7 71 4.4 Monitoring of terminal behavior............................8 72 4.5 Accommodation of variable-bit-rate sources.................9 73 5. Service models provided by the PPS.............................9 74 5.1 Admission control.........................................10 75 5.2 Quality improvement.......................................10 76 5.3 Available bit rate........................................10 77 5.4 Bit-rate increase.........................................10 78 6. The feasibility of probe-based admission control..............11 79 7. Functional architecture of the Priority Promotion Scheme......11 80 8. Requirements of the Priority Promotion Scheme.................11 81 8.1 Routers...................................................11 82 8.2 End systems...............................................12 83 8.3 SIP proxies...............................................13 84 8.4 Edge routers..............................................13 85 8.5 Media monitoring servers..................................13 86 9. Security Considerations.......................................14 87 10. IANA Considerations..........................................14 88 Acknowledgements.................................................14 89 Authors' Addresses...............................................14 90 References.......................................................14 91 Appendix: Probe-Based Admission Control (PBAC) - Current 92 experimental results and obervations.............................16 94 1. Introduction 96 Emerging services such as VoIP, video chat, and video conferencing 97 require session-based QoS. A number of schemes for providing the 98 required QoS control have been put forward, but they either require 99 per-flow management of routers within the network or handle the 100 provision of QoS on a per-class basis, which requires the allocation 101 of large amounts of resources. In this document, a framework for a 102 new QoS scheme is proposed. The scheme is suitable for session-based 103 interactive multimedia and adds less complexity to the network than 104 previous approaches, while delivering per-flow QoS. 105 Karlsson [3] [4] originally proposed the basic concept. Here, we 106 clarify the requirements for routers, introduce enhancements to 107 session control using SIP, and show some alternative ways to 108 implement the required monitoring of end-system behavior. We refer 109 to this scheme as the "Priority Promotion Scheme". 111 One of the key functions of the Priority Promotion Scheme is the 112 behavior of routers. We introduce the MF-PHB (Measurable Forwarding 113 Per Hop Behavior) as a new per-hop behavior that provides the 114 required functionality. Whether or not MF-PHB is feasible on given 115 items of existing equipment will have to be verified. This framework 116 is intended as a guide for device manufacturers, network 117 administrators, and operators who need a way to provide QoS for 118 interactive multimedia services. It is not intended, in its current 119 state, for use by the majority of networks in the Internet. We make 120 this proposal now because we feel that the only way to achieve a 121 long-term solution for inter-domain QoS is to start putting intra- 122 domain solutions into practice and then incrementally expand the 123 scope of the work as more experience in deployment is gained. 125 In this document, we introduce a framework for Priority Promotion. 126 We describe the target service category, which we refer to as 127 "interactive multimedia services", in section 2. In section 3, we 128 explain our motivation in focusing on an end-system-oriented 129 measurement-based approach. The basic procedures of the Priority 130 Promotion Scheme are then explained in section 4. In section 5, 131 specific variant applications of the Priority Promotion Scheme are 132 presented to show the scheme's potential. The feasibility of a 133 measurement-based approach is presented in the appendix to this 134 document and section 6 states why the arguments in the appendix are 135 applicable to the PPS. The functional architecture of the scheme is 136 described in section 7. Finally, the requirements for individual 137 functional entities are summarized in section 8. MF-PHB (Measurable 138 Forwarding) that is necessary to realize PPS is defined in [5] and 139 the verification scenarios of MF-PHB is in [6]. 141 2. The target service type - interactive multimedia 142 The major targets of the Priority Promotion Scheme are multimedia and 143 interactive communications services provided through software tools 144 running on PCs and operated by human beings. We call such services 145 interactive multimedia (IMM) services. Typical examples of IMM are 146 VoIP, video chat, and video conferencing. Several characteristics 147 differentiate IMM services from existing data services. Web browsing 148 and, in many cases, file retrieval are based on client/server models 149 and the data transfers speeds required are not in general very high. 150 In contrast to this, IMM services are any-to-any and require 151 relatively high speeds in the range from less than 1 Mbps to several 152 Mbps. These IMM-inherent characteristics may cause large 153 fluctuations in traffic patterns and may not be predictable in 154 advance. 156 Other important characteristics of IMM services are the QoS 157 requirements: that is, the requirements for bandwidth guarantees and 158 short delays. The latter is because of the real-time nature of these 159 services. The former is because typical codecs are sensitive to 160 fluctuations in bandwidth, which lead to degradation of the QoS. 161 While several codecs adjust their information rates to suit the 162 available bandwidth, they impose higher processing loads on the end 163 systems; this approach also necessarily incurs noticeable and 164 possibly annoying fluctuation in the perceived quality. This implies 165 that once a session has been established, the bandwidth has to be 166 guaranteed until the end of the session. In other words, the session 167 should not be established unless the required bandwidth is available. 168 Note that one desirable extended interpretation of this concept is to 169 allow increases, but never decreases, in the bandwidth available to a 170 session. That is, improvement is acceptable but deterioration is not. 171 This is why we have included "promotion" in the name of the scheme. 173 Finally, a session of an IMM service is set up on-demand and may last 174 for time of the order of minutes to tens of minutes. 176 When we take the above-described characteristics and requirements of 177 IMM into account, we see that explicit admission control on a per- 178 flow basis is necessary. A common argument is that simple over- 179 provisioning is capable of meeting these requirements. As was stated 180 above, however, IMM combines the characteristics of relatively large 181 bandwidth requirements and strict QoS needs in general with 182 unpredictable traffic patterns. Therefore, we need a form of 183 session-based admission control to deliver QoS for IMM services. 185 It should be emphasized that admission control has a completely 186 different goal from the existing TCP core functionality. The goal of 187 admission control is to provide bandwidth guarantees with the 188 appropriate QoS for a certain maximum number of sessions. For 189 example, if the network is able to carry 100 Mbps and 100 users 190 request sessions with guarantees of 1 Mbps, nearly 100 sessions 191 should be established. If 1000 users request the same 1-Mbps 192 guarantees, only around 100 sessions should be established. This is 193 quite different from existing data services provided through the TCP. 194 The idea of the TCP is to share network resources in a "fair" manner 195 among the sessions requested at any time. If the network is able to 196 carry 100 Mbps and 100 users request sessions, 100 sessions should be 197 established, each with roughly 1 Mbps throughput. If 1000 users 198 request sessions, all 1000 should be established, each with a 199 throughput around 0.1 Mbps. This is not suitable for IMM services. 201 The SIP provides one suitable way to control IMM services. Although 202 we focus on the SIP in this description, session-control protocols 203 for the PPS are not restricted in this way. 205 The application of a QoS policy which includes differentiation based 206 on the identity of the callers or callees in sessions has to be 207 studied as a separate issue. Issues include competition between VIP 208 calls and ordinary calls, or between preferential calls and ordinary 209 calls in times of disaster. If such a policy that caters for such 210 situations is to be applied along with simple admission control based 211 on resource availability, policy credential information from the SIP 212 or another signaling method may have to be incorporate into the PPS 213 framework. 215 3. Motivation for the focus on an end-system-oriented measurement-based 216 approach 218 As IP-based networks proliferate, overall network configurations 219 become increasingly complex. In terms of bandwidth available in the 220 access network, DSL alone includes many variants. 12-Mbps ADSL is 221 quite popular in Japan and higher-speed ADSL services will be 222 deployed in the near future, but the actual throughput is completely 223 dependent on conditions such as the distance from the central office 224 and interference among the lines. 226 Another point is the variations in the network configurations of 227 customers, including broadband routers. The broadband routers 228 initially offered for use with higher-speed access lines may not be 229 capable of providing the same maximum throughput as is stated in the 230 catalogue. A customer's PC may impose similar restrictions. 231 Furthermore, wireless access introduces further complications in 232 terms of the access environment. The network to which the customer 233 is connected adds a lot of variables. 235 In such a complicated situation, end-to-end guarantees of QoS are 236 difficult to achieve and the role of the end system becomes more 237 important, because only the end system is able to see the actual 238 conditions of communication. In the Priority Promotion Scheme, the 239 end systems measure, monitor, or probe levels of network resources so 240 that they are able, if possible, to set up and maintain media streams 241 with required levels of QoS. We focus on an end-to-end approach 242 because only the end systems are able to judge the overall relevant 243 network situation. 245 We refer to the terminal points of the media stream, i.e. PCs or 246 residential gateways and routers, as end systems. 248 4. Basic procedure for the Priority Promotion Scheme 250 The Priority Promotion Scheme (PPS) is a new scheme for traffic 251 control; specifically, the PPS achieves end-to-end QoS for 252 interactive multimedia services by exercising admission control for 253 series of packets on a packet-based network. The scheme is based on 254 end-to-end measurement of network resources through coordination of 255 the end systems. 257 In this context, "priority" means priority or precedence at the 258 packet level as represented by the DiffServ Code Point (DSCP) in the 259 IP layer. If we apply the PPS in Layer 2, the priority is 260 represented by the user_priority field specified in 802.1D and Q. If 261 MPLS is used as an underlying transport, EXP field corresponds to the 262 code. 264 4.1 Basic procedure for end systems 266 PPS largely relies on end-system behavior for sending the probe 267 packets, which test the availability of network resources, and for 268 decisions on whether or not the succeeding (higher priority) packets 269 can in fact be sent. 271 Before a session is established and even, under certain conditions, 272 during sessions, the source-end system senses, measures, or probes to 273 detect the availability of network resources. This is done by sending 274 packets with priority one level lower than that of the non-probe 275 packets, i.e. those for established streams. Probe packets are given 276 lower priority so that existing flows of packets are maintained and 277 packet loss is confined to the probe packets; this gives a sharper 278 focus to the loss characteristics. 280 Criteria for successful receipt at the destination-end system can 281 include loss, delay, and delay jitter. The authors believe that loss 282 will usually be the crucial parameter, but are willing to enlarge the 283 scope of measurement to include the other two characteristics. 285 The conditions of receipt determine how the DSCP value for the 286 succeeding IP packets is adjusted: the priority is raised or promoted 287 to firmly establish the session, lowered to leave resources with 288 existing sessions, or otherwise adjusted to control the amount of 289 packets such that the traffic fits into the available capacity. 291 The RTCP can be used to carry the report from the destination end 292 system. Whether or not the probing packets can carry real media data 293 depends on the required duration of measurement. If measurement will 294 take more than a couple of seconds, the probe packets should carry 295 real media so that the customer does not have to wait for completion 296 of the measurement period. 298 4.2 Router behavior 300 The PPS in principle requires that the network, i.e. each output link 301 of a router or Layer 2 switch, support per-class priority control. 302 Prioritization allows the end systems to measure remaining resources 303 without affecting existing streams. In addition to the simple 304 priority control required by the PPS in itself, existing classes 305 (Per-Hop Behaviors or PHBs) such as EF, AF, and BE should be 306 supported. That is, we have to implement an extension to the 307 DiffServ architecture. To clarify the requirements specific to the 308 PPS, we propose Measurable Forwarding as a new PHB (MF-PHB). A 309 detailed description of the MF-PHB has already been given [5]. 310 Whether or not current DiffServ implementations are capable of 311 supporting this new PHB for the PPS without elaboration of the queue 312 configuration is not clear. However, having all end systems behave 313 in the way described above and all network elements implement the MF- 314 PHB ensures that the end-to-end QoS is achieved without having to 315 maintain per-flow states in individual items of network equipment. 317 A great advantage of the PPS is that it avoids persistent contention 318 among real-time streams. Note that we are talking about scheduling 319 priority in the DiffServ scheduler as opposed to a policy perspective 320 on call control preference or drop preference in a common queue. 322 4.3 Variation of measurement-based mechanisms 324 Measurement-based approaches have many basic variants. Any of the 325 end systems - the media proxy or home gateway, the edge router at the 326 ingress point of the network, or the border gateway - might be 327 assigned the role of measurement and decision entity. 329 The items for measurement from which we identify the remaining 330 bandwidth are packet loss and/or delay. Explicit congestion 331 notification initiated by the network may also provide supplementary 332 information. 334 For the sake of simplicity, we would like to focus on an approach 335 that is 1) end-system oriented, 2) loss-rate-based, 3) includes no 336 mechanism for explicit indication from the network. 338 As we have previously noted, the above concept is not new. It was 339 originally proposed by Karlsson as probe-based admission control 340 (PBAC) [3][4]. Based on Karlsson's proposal, we would like to extend 341 the measurement-based approach to allow for various service models, 342 to clarify the behavior required of routers, and to take into account 343 monitoring of the correctness of end-terminal behavior. 345 4.4 Monitoring of terminal behavior 347 How we monitor, check, or audit the behavior of end systems is an 348 important issue for a commercial service. Since the Priority 349 Promotion Scheme is strongly reliant on the behavior of end systems, 350 incorrect behavior, whether accidental or intentional, will affect 351 the QoS for other customers. 353 Here, the items to be monitored include whether or not flows have 354 been given permission to enter or access the network, whether flows 355 are at the correct priority level, and whether flows are at the bit 356 rates indicated by probing or signaled by SIP. These are the 357 behaviors in the direction from source to destination. The behavior 358 in the direction from the destination to the source should also be 359 correct, and feedback reports on e.g. correctness of the conditions 360 of receipt might be included to monitor this. Furthermore, the 361 source behavior in response to such reports should be correct in 362 terms of not promoting priority when the report indicates bad 363 conditions. One of the benefits of the PPS is the allocation of 364 resource-management functions to the end systems, since this reduces 365 the burden on the network. If we implement functions of the kind 366 just described to monitor the correctness of the behavior of end- 367 systems, however, we place another burden on the network. There is a 368 tradeoff between the extent to which we should protect the network 369 and the costs of doing so. 371 The site of monitoring is another issue we face in designing the 372 network. One solution is to install checking mechanisms of the kind 373 described above in every edge router and have them monitor every 374 session. This is perfect in terms of protecting the network from all 375 kinds of incorrect behavior, but would cost too much. 377 Another practical solution is to introduce two-stage monitoring of 378 end-system behavior. The intention here is to classify items for 379 monitoring as either primary or secondary and having them checked at 380 the appropriate places. Primary monitoring may be implemented at the 381 edge routers and is triggered by session initiation. Secondary 382 monitoring might be done by a dedicated media-monitoring server. The 383 primary monitor checks every PPS-controlled media stream it handles. 384 Examples of items to check include whether the flow has been given 385 permission to enter the network, whether the flow rate is no greater 386 than the probed bit rate, and the correctness of the usage of the 387 DSCPs. The secondary monitor checks the details of end-system 388 behavior. Whether or not the two monitoring stages are really used 389 will depend on the specific network environment, but both should be 390 available to allow flexibility in implementation. 392 4.5 Accommodation of variable-bit-rate sources 394 Any measurement-based form of admission control is more suitable with 395 constant bit rate (CBR) sources than with variable bit rate (VBR) 396 sources. CBR sources to which silence suppression is not applied are 397 often used in public voice communications in Japan. For interactive 398 multimedia, on the other hand, it is important that we take VBR into 399 account. 401 Another approach is possible, relying on declared traffic parameters 402 and deterministic capacity allocation rather than results of 403 measurement. The admission control system gets the declared 404 parameters, estimates the equivalent bandwidth, and then judges 405 whether or not admission is possible. The drawbacks here are the 406 difficulty of deriving truly representative parameters for each of 407 the many popular codecs and of estimating the total required 408 bandwidth when a new flow is offered. 410 VBR has quite different implications for a measurement-based approach 411 such as PPS. PPS requires no parameters, no estimation, and no 412 calculation. In addition, utilization of bandwidth is ideal because 413 measurement is of actual traffic. There is, however, a trade off. 414 The PPS depends on the usage of resources at the time of measurement. 415 Measurement for a particular session may occur when the flows already 416 present are at relatively low rates. The new session may then suffer 417 loss of QoS when the volume of flows returns to typical levels. 419 The tuning of the PPS to support VBR sources thus has to reflect 420 statistical variation, which can be done by probing over a longer 421 time or by sending the probing packets at a higher rate than the non- 422 probing packets. A new (elastic) mode of PHB provides a way of 423 avoiding such mechanisms and is introduced in the definition of the 424 MF-PHB[5]. 426 Investigations with VBR sources including ON/OFF source have already 427 been done by Prof. Karlsson as is indicated by the Appendix of the 428 document. 430 5. Service models provided by the PPS 432 The Priority Promotion Scheme can be viewed as a kind of admission 433 control. However, it is not limited to the kind of 434 connection/session admission control we imagine if we think of the 435 legacy telephone network. The probing can even be handled by the 436 media packets themselves. In this section, we examine the possible 437 service models provided by the PPS. 439 5.1 Admission control 441 Admission control alone is suitable for conventional service models 442 such as legacy switched services. The measurement is simply used for 443 admission control when the session is established. If the trial 444 fails, the session is not established. The user may retry, but the 445 terminal behavior does not specify the extent to which this is 446 possible. PPS is quite effective in this role as long as the 447 duration of probing is less than a couple of seconds. 449 5.2 Quality improvement 451 The case of PPS where the media packets are used for probing is 452 particularly applicable to quality improvement. The source starts by 453 sending media packets at probe level. If the conditions of receipt 454 are poor, the source stops sending the media packets at probe level, 455 and recommences sending them as packets of another class. After a 456 while, the source returns to probing; if this succeeds, the packets 457 are sent as packets of the higher (non-probing) MF-PHB class. 459 5.3 Available bit rate 461 In the available-bit-rate service model, the transmitter uses the 462 information on network conditions received in response to probing to 463 estimate the actual available bandwidth, selects the closest 464 bandwidth lower than the available bandwidth, and then sends the 465 media at the higher MF-PHB priority level. The transmission may be 466 made to fit the available bit rate by sending the video data with 467 less size or resolution than was originally desired or sending speech 468 data alone rather than a mix of video and speech. The quality of the 469 session is then maintained. 471 A further possible application of this approach is to send media data 472 at the full rate but only assign the higher MF-PHB priority to the 473 core part of the flow, which fits the available bit rate; the other 474 parts are sent but assigned to another class. This approach should 475 work well with hierarchical coding (in MPEG for example, I frames 476 would be sent with high priority and P or B frames with low priority). 478 5.4 Bit-rate increase 480 This is an extension to the available-bit-rate service model. If 481 initial probing indicated that the requested bit rate is not 482 available, the source sends at the lower rate than requested but 483 retries probing from time to time. When the requested rate becomes 484 available, the source starts sending media packets at the requested 485 rate. 487 6. The feasibility of probe-based admission control 489 Karlsson has already investigated the characteristics of probe-based 490 admission control (PBAC). Although the overall system architecture 491 of PBAC is slightly different from the PPS, the basic dynamics are 492 the same and the analysis of PBAC is applicable to the PPS. A 493 summary of the analysis is thus given in the Appendix of this 494 document. 496 7. Functional architecture of the Priority Promotion Scheme 498 Figure 1 shows the functional architecture of the Priority Promotion 499 Scheme. The main functional elements are the two end systems, i.e. 500 the source and destination, the source-side edge router, the core 501 routers, the SIP proxy, and the media-monitoring server. 503 SIP proxy (Media-monitoring server) 504 |------| |------| 505 /---------| |------------| | 506 / |------| |------| 507 / | // 508 / | // 509 |------| |------| |------| |------| |------| 510 | |=========| Edge |======| Core |======| Edge |======| | 511 |------| |------| |------| |------| |------| 512 End system End system 513 (Source) (Destination) 515 Figure 1. Functional architecture of the Priority Promotion Scheme 517 8. Requirements of the Priority Promotion Scheme 519 In this section, we describe the requirements for the various 520 functional entities. 522 8.1 Routers 524 Although the end systems play an important role in the Priority 525 Promotion Scheme, the scheme places a few other requirements on the 526 network. Specifically, the queuing mechanism or PHB (per-hop 527 behavior) for the PPS creates new requirements for network elements. 528 The Priority Promotion Scheme is intended to work with the existing 529 Diffserv PHBs, as was indicated in the introduction. However, to 530 clearly explain how the scheme would be implemented in this context, 531 we have to define a new PHB. We refer to this as measurable 532 forwarding (MF). The essential requirements for MF are as follows. 534 - MF has two sub-classes, MF-High (MF-H) and MF-Middle (MF-M). 535 - MF-H and MF-M share the same capacity. 536 - MF-H takes priority over MF-M. 538 In other words, we have a total amount of MF-H and MF-M traffic as a 539 limit rather than separate limits for the two sub-classes. However, 540 since MF-M traffic will always defer to MF-H traffic, MF-M traffic 541 may experience markedly higher levels of jitter and loss than MF-H, 542 while one would expect MF-H traffic to experience very low levels of 543 jitter and loss. 545 Another view of MF is that, if a given amount of MF-M traffic for a 546 particular stream passes through a router, at least the same amount 547 of MF-H traffic for that stream must also be able to pass through. 548 In the absence of other DiffServ classes, configuring existing 549 commercially available routers to implement the MF-PHB should be 550 feasible. Further requirements are as follows. 552 1) The MF must co-exist with other PHBs, such as the EF, AF, and BE. 553 Existing implementations may not be capable of satisfying this 554 extended requirement. 555 2) MF should take priority over AF and BE. This is because the 556 target services are IMM services, where real-time variations in 557 traffic characteristics are crucially important. 559 The more detailed definition of MF-PHB and scenarios for its 560 verification are available in [5][6]. 562 8.2 End systems 564 The transmitter should send trial packets before or at the beginning 565 of a session. 567 The receiver should record the results of trial-packet reception and 568 report this information to the transmitter. 569 The RTCP would be the best candidate to handle reporting of the 570 results of reception. Some improvements might be necessary to reduce 571 the measurement period and to make quick decisions. Actually, the 572 minimum measurement period is the key factor that determines the 573 usability of the Priority Promotion Scheme. This determines whether 574 or not the scheme is applicable to admission control, as was 575 described in section 5. 577 The transmitter then decides on the next action. 578 - If the conditions of reception are good, the transmitter sends the 579 remaining packets with the higher priority. 580 - If the conditions are not good, the transmitter gives up sending 581 monitor packets and either 1) sends the remaining packets with 582 another class such as BE, 2) stops sending any media data and, after 583 a while, starts sending monitoring packets again, or 3) terminates 584 the session. 586 According to the service models described in section 5, further 587 actions are necessary. 589 Synchronization between the two directions of the media stream 590 remains a subject for further study. 592 8.3 SIP proxies 594 In principle, SIP is not directly related to the Priority Promotion 595 Scheme. However, for commercial applicability, the operator would 596 have to be able to monitor the service subscription of the customer 597 before establishing the call. Furthermore, if the edge router is 598 capable of monitoring user streams, an SIP proxy can send commands to 599 an edge router, requesting that it check on a particular end system's 600 behavior. 602 The specific signaling sequence may depend on the selected service 603 model. 605 If the policy is applied as was described in section 5, signaling is 606 where the policy credentials are exchanged. 608 8.4 Edge routers 610 As noted above, in some networks an SIP server might be available and 611 is able to instruct edge routers to monitor the behavior of end 612 systems. An edge router might monitor the following items. 614 - Packet-transmission rates: the transmitter should not send packets 615 at rates above the peak bit rate offered in the monitoring phase. 616 - Continuous sending of packets: if the transmitter pauses in the 617 sending of packets, the other end systems overestimate the remaining 618 network resources and incorrectly send higher-priority packets. 619 Transmitters should thus not pause during sending. 621 8.5 Media monitoring servers 623 In addition to primary monitoring by the edge routers, more detailed 624 monitoring may be required. The typical items to be monitored are as 625 follows: 626 - the accuracy of packet-reception information from receivers, and 627 the correctness of reactions of transmitters to this information; and 628 - if the received information indicates poor conditions, the 629 transmitter stops sending high-priority packets; if a next trial is 630 allowed, a certain time interval should be maintained between the 631 initial trial and the next trial. 633 9. Security Considerations 635 To be described. 637 10. IANA Considerations 639 To be described. 641 Acknowledgements 643 The authors would like to thank Fred Baker, David Oran, Glenn Reitsma 644 and other technical experts at Cisco for some insightful suggestions. 646 Authors' Addresses 648 Naotaka Morita 649 Network Service Systems Laboratories 650 NTT Corporation 651 9-11, Midori-Cho 3-Chome, 652 Musashino-Shi, Tokyo 653 150-8585 Japan 654 E-mail: morita.naotaka@lab.ntt.co.jp 656 Gunnar KARLSSON 657 KTH, Royal Institute of Technology 658 Department of Microelectronics & Information Technology 659 Laboratory of Communication Networks 660 Isafjordsgatan 39 661 P.O.Box Electrum 229 662 SE-164 40 Kista, Sweden 663 E-mail: gk@imit.kth.se 665 References 667 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 668 RFC 2026, October 1996. 670 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 671 Levels", BCP 14, RFC 2119, March 1997. 673 3 Karlsson, K., "Providing Quality for Internet Video Services," in 674 Proc. of the CNIT/IEEE 10th International Tyrrhenian Workshop on 675 Digital Communications, Ischia, Italy, September 15-18, 1998. 677 4 Fodor, (nee Elek), V., Karlsson, G., and Roenngren, R., "Admission 678 Control Based on End-to-End Measurements," in Proc. IEEE INFOCOM, 679 Tel-Aviv, Israel, March 26-30, 2000. 681 5 Morita, N., " Measurable Forwarding: A New per-Hop Behavior 682 (PHB) ," Internet draft, October 2003. 684 6 Morita, N., " Verification scenarios for Measurable Forwarding PHB 685 (Per-Hop Behavior)," Internet draft, October 2003. 687 Appendix: Probe-Based Admission Control (PBAC) - Current experimental 688 results and obervations 690 1. System definitions 692 . Complete semantic definition of the probe-based admission control 693 [A1, A2]. 695 . Multicast application of PBAC [A3]. The quality of service scheme 696 for multicast traffic is based on admission control for both 697 senders and receivers. The admission control is well suited to 698 multicast sessions with a single multimedia stream or with several 699 layered streams. 701 . Simple security model to verify the end host identities and secure 702 the probe phase and the admission decision [A4]. The scheme 703 verifies the end user's identities and secures the transmission 704 during the probing phase. 706 2. Analytical models 708 . Approximate mathematical model that relates probe and data packet 709 loss rate, queue buffer sizes and achieved link utilization for 710 the double queue system [A5]. The analysis is based on the 711 following steps: First, computation of the probability of a single 712 probe packet being successfully transmitted; second, computation 713 of the acceptance probability as a binomial distribution; third, 714 computation of the link utilization as a birth--death Markov 715 chain; and fourth, computation of the data packet loss for a 716 particular source type and the probe/data loss relationship. 718 . Numerical results with figures for probe packet loss probability, 719 acceptance probability as a function of the load on the system, 720 link utilization and data packet loss probabilities. The results 721 agree with the simulations and prove that the considered probe-- 722 based admission control leads to a stable link utilization and has 723 a clear upper bound on the packet loss probability. 725 3. Performance evaluation 727 All the performance figures have been obtained with the NS-2 728 simulator. Different source types and source rates have been used: 729 sources with exponential and Pareto on--off holding times and traces 730 of real MPEG-2 encoded videos, with peak rates from 64 kb/s to 10 731 Mb/s. The sources are listed in Table 1. The following issues have 732 been investigated: 734 . Performance and comparison of the proposed queuing schemes for the 735 controlled load service, a double queue system with two priorities 736 and a single queue system with a discard threshold for probe 737 packets [A2]. Both queue systems can be used with a proper buffer 738 and threshold dimensioning. 740 . The validity of the assumption of a normal distribution of the 741 probe packet loss for the admission decision [A2]. Histograms of 742 the probe packet loss prove the assumption valid. 744 . Stress test with short sessions and sessions that keep silent for 745 long periods of time [A2]. None of this special sessions have a 746 serious effect unless they represent a substantial percentage of 747 the link capacity (over 15 %). The performance of the system under 748 heavy stress (many simultaneous probes or sessions that keep 749 silent for periods of time longer than some probe lengths) is 750 stable. In general, as the situation worsens, the admission 751 control is conservative, allowing less ongoing sessions, but never 752 failing to keep the data packet loss under the threshold for 753 maximum session peak rates of less than 5% of the link capacity. 755 . Relationship between probe packet loss and session data loss for 756 different source types and peak rates [A1, A2]. Basically all 757 source types show between half to one order of magnitude 758 difference. All the figures show that there is a nearly linear 759 relationship between the probe and the data packet loss. 761 . Effect of multiple links scenarios with cross traffic [A1]. The 762 simulations prove that the bottleneck link dominates the behavior. 764 . Blocking and data packet loss probabilities and their relation to 765 the probe length and the location of a multicast receiver [A3]. 766 The simulations prove that receivers in different branches of the 767 multicast tree have different blocking probabilities, depending on 768 the link loads on the different multicast branches. 770 . Performance evaluation of an implementation of the security model 771 proposed in [A4] with commodity hardware, focusing in the trade 772 off between security level and setup delay. The simple solution 773 does not require any change in the network nodes, just a 774 cryptographic interface in the access gateways and the end nodes. 776 Table 1: Parameters of the different test sources 778 Source On Time Off Time Peak Rate 779 Exponential 20 and 325ms 35.5 and 650ms 64kb/s to 10Mb/s 780 Pareto (fi=1.5) 20 and 325ms 35.5 and 650ms 64kb/s to 10Mb/s 781 Mixed 20 and 325ms 35.5 and 650ms 64kb/s to 10Mb/s 782 Video Traces 360kb/s 783 (64kb/s average) 785 4. On-going work 787 . Software implementation of PBAC for Linux. A library to provide 788 the probing features is being developed, which will enable 789 software generators or end applications to perform the probing 790 before transmitting. The queuing system will be implemented using 791 the QoS capabilities of the Linux kernel (iproute2 (1)). 793 . A possible policing and metering tool for PBAC is under 794 investigation using Netramet (2). 796 References 797 [A1] Viktoria Elek, G. Karlsson, and R. Roenngren, "Admission control 798 based on end-to-end measurements," in Proc. of the 19th Infocom, (Tel 799 Aviv, Israel), pp. 623--630, IEEE, March 2000. 801 [A2] I. Mas Ivars and G. Karlsson, "PBAC: Probe--based admission 802 control," in Proc. of QofIS 2001, vol. 2156 of LNCS, (Coimbra, 803 Portugal), pp. 97--109, Springer, September 2001. 805 [A3] I. Mas Ivars, V. Fodor, and G. Karlsson, "Probe--based admission 806 control for multicast," in Proc. of the 10th IWQoS, (Miami Beach, 807 Florida), pp. 99--105, IEEE, May 2002. 809 [A4] M. Conte, I. Mas Ivars, V. Fodor, and G. Karlsson, "Policy 810 enforcing for probe--based admission control," in Proc. of NTS 16, 811 (Espoo, Finland), pp. 45--55, Helsinki University of Technology, 812 August 2002. 814 [A5] I. Mas Ivars, V. Fodor, and G. Karlsson, "The performance of 815 endpoint admission control based on packet loss," in Proc. of QofIS 816 2003, vol. 2856 of LNCS, (Stockholm, Sweden), Springer, October 2003. 818 (1) ftp://ftp.inr.ac.ru/ip-routing/ 819 (2) http://www.auckland.ac.nz/net/NeTraMet/