idnits 2.17.00 (12 Aug 2021) /tmp/idnits40367/draft-ng-opes-irmlqos-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: ---------------------------------------------------------------------------- == There are 65 instances of lines with non-ascii characters in the document. == 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 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. ** The abstract seems to contain references ([2], [3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2001) is 7615 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) == Outdated reference: A later version (-03) exists of draft-beck-opes-irml-02 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '7') ** Obsolete normative reference: RFC 1889 (ref. '8') (Obsoleted by RFC 3550) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C. W. Ng 3 Document: draft-ng-opes-irmlqos-01.txt P. Y. Tan 4 Expires: August 2002 H. Cheng 5 Panasonic Singapore Labs 6 July 2001 8 Quality of Service Extension to IRML 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 RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference 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 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The Intermediary Rule Markup Language (IRML) [2] is an XML-based 34 language that can be used to describe service-specific execution 35 rules for network edge intermediaries under the Open Pluggable Edge 36 Services (OPES) framework, as described in [3] and [4]. This memo 37 illustrates examples of employing the IRML for Quality of Service 38 (QoS) policing and control, and proposes a QoS sub-system extension 39 to IRML for better QoS support in the OPES framework. 41 Table of Contents 43 1. Introduction....................................................3 44 1.1. Terms Used....................................................3 45 2. Example Services for QoS Policing in OPES Services..............3 46 2.1. Adaptation of HTML Contents...................................3 47 2.2. Dynamic Adaptation of Streaming Contents......................4 48 2.3. QoS Policy Control............................................4 49 2.4. Load-Balancing................................................5 50 3. Requirements for QoS Sub-System.................................5 51 4. QoS Sub-System of IRML..........................................6 52 4.1. QoS Policy Properties.........................................6 53 4.2. Network Status Properties.....................................6 54 4.3. Intermediary Load Properties..................................8 55 4.4. Overriding ômatchesö and ônon-matchesö Attributes in QoS Sub- 56 System.......................................................8 57 4.5. The ôcontextö Attribute.......................................9 58 5. Examples.......................................................10 59 6. References.....................................................12 60 7. Author's Address...............................................13 61 1. Introduction 63 The Intermediary Rule Markup Language (IRML) [2] is an XML-based 64 language that can be used to describe service-specific execution 65 rules for network edge intermediaries under the Open Pluggable Edge 66 Services (OPES) framework, as described in [3] and [4]. This memo 67 specifies a Quality of Service (QoS) subs-system in the IRML, and 68 illustrates examples of employing the IRML for QoS policing and 69 control. 71 This memo begins in Section 2 by illustrating a few scenarios where 72 QoS policing and control can be incorporated into the OPES 73 intermediary. From there, a set of preliminary requirements for QoS 74 sub-system extension to the IRML is drafted in Section 3. Section 4 75 defines the set of QoS parameters used in the ôpropertyö and 76 ôvariableö elements in the proposed QoS sub-system, and Section 5 77 presents some examples illustrating possible use of the QoS sub- 78 system. 80 1.1. Terms Used 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 84 this document are to be interpreted as described in RFC-2119 [5]. 86 2. Example Services for QoS Policing in OPES Services 88 2.1. Adaptation of HTML Contents 90 By far, Hyper Text Markup Language (HTML) pages are the most common 91 content transported by the Hyper Text Transfer Protocol (HTTP). 92 These HTML contents are usually static, making them ideal candidate 93 to be cached at the network edge. However, with increasing number 94 of "thin" clients, it is virtually impossible to have a HTML page 95 that is suitable to be viewed for all the possible browsers. 96 Adaptation of HTML pages to suit the clientÆs browser is widely 97 employed (through means of server-side includes such as PHP or 98 client-side JavaScripts). One excellent example would be the 99 adaptation of HTML to WML (Wireless Markup Language) pages. 101 Adaptation of HTML pages can also be employed to suit the user or 102 access-provider QoS requirements. For example, it might be 103 necessary to remove redundant information when translating HTML 104 pages to WML for a mobile phone client with a very limited bandwidth 105 (and limited screen size). It will also be helpful to replace the 106 tags in the original HTML page to their ALT text equivalence. 107 For another client who is using a Personal Digital Assistant (PDA) 108 with a Wideband-CDMA connection, the translated WML may include more 109 of the original HTML contents and some pictures. 111 Bandwidth is not the only consideration. For the example of the PDA 112 client quoted above, when the channel condition is poor, it might be 113 desirable to reduce the amount of text in the translated WML to 114 ensure a more speedy delivery. 116 Such HTML adaptation is not only limited to the wireless scenario. 117 For a client with a wired connection to the Internet, it is 118 sometimes necessary to sub-sample the embedded images in the HTML 119 pages to reduce their size so as to meet the maximum delay 120 requirements imposed by the user or access-provider. This can occur 121 when the allocated bandwidth is small, or when the connection is 122 congested (e.g. the user is downloading a couple of files 123 simultaneously). 125 2.2. Dynamic Adaptation of Streaming Contents 127 Streaming of audio-visual (AV) contents over the Internet has become 128 increasing popular over the years. AV streaming poses different 129 technical challenges as compared to HTML delivery, with stricter QoS 130 requirements, such as maximum delay and constant/variable bit-rates. 131 When the transport technologies employed within the network core are 132 best-effort delivery in nature, it is very difficult to guarantee 133 the required quality of service. Thus, to maintain the perceived QoS 134 by the user, it is often necessary to dynamically adapt the AV 135 stream to the fluctuating network connection conditions [6]. 136 Ideally such adaptation services should be placed near the end-user, 137 so as to reduce the errors in estimating the network conditions at 138 the network edge. This also allows for intermediary to cache the AV 139 contents, and directing the contents to the adaptation service 140 depending on the QoS requirements and channel conditions. 142 The use of OPES intermediaries to adapt the AV contents requires 143 that the QoS parameters, such as allocated/requested bandwidth and 144 channel conditions, be made available to the rule decision engine. 146 2.3. QoS Policy Control 148 Often, the OPES services will reside on an intermediary box that is 149 provided by the access provider. Thus one major application of the 150 IRML is to implement policy rules based on the Service Level 151 Agreement (SLA) between the access provider and the end-user. QoS is 152 one important aspect of SLA. 154 To illustrate, consider the following scenario where an end-user has 155 a service policy of 64kbps bandwidth. Suppose the end-user is in 156 the middle of watching a movie at 56kbps when a 16kbps voice-over-IP 157 (VoIP) stream arrives. Instead of simply rejecting the VoIP 158 connection, with IRML services, the access provider (or even the 159 end-user) can now specify policy rules to perform any of following 160 more desirable actions: 162 (a) adapts the VoIP stream to the remaining bandwidth, 164 (b) adapts the movie stream to give room for the VoIP stream (e.g. 165 mute the audio from the movie), or 167 (c) adapts both the movie and VoIP streams. 169 2.4. Load-Balancing 171 The OPES framework in [3] allows for the adaptation services to be 172 performed remotely on a separate, dedicated server, such as an ICAP 173 server. This allows for scalability. However, when the number of 174 connections is small, it might not be desirable to perform remote 175 callout, as the overhead incurred will add transmission delays. IRML 176 can be employed to redirect content adaptation to a remote server 177 when the load on the intermediary is high, and to use a local 178 proxylet when the load is low. Such decision can only be done if 179 IRML is extended to environment properties, such as server load. 181 In addition to serverÆs processing load, such decision may based on 182 the end-userÆs QoS requirement as well. For instance, when the 183 server load is moderate, it might process adaptation services for 184 end-users with stricter QoS requirements, and invoke remote 185 adaptation services for end-users with lower QoS requirements. 187 3. Requirements for QoS Sub-System 189 In consideration to the example services illustrated in the previous 190 sections, a preliminary set of requirements for the QoS sub-system 191 extension to the IRML can be outlined as follow: 193 - It SHOULD enable rule modules to match the end-user QoS policy 194 requirements against pre-defined labels. Such QoS policy 195 requirements MAY include, but not limited to, the allocated 196 bandwidth to the end-user, the requested bandwidth for the 197 current connection, and the required delay bound, if any. 199 - It SHOULD enable rule modules to match the transmission 200 statistics of the end-user connection with the intermediary 201 against pre-defined labels. 203 - It SHOULD enable rule modules to match the current system load of 204 the intermediary against pre-defined labels. The system load MAY 205 be inferred from percentage load, and/or the number of 206 connections the intermediary is handling. 208 The above set of requirements is not exhaustive. Further research 209 work needs to be carried out to evaluate the applicability of these 210 requirements, and append additional requirements if deem 211 appropriate. 213 4. QoS Sub-System of IRML 215 In order to extend QoS-aware services in the OPES intermediary, it 216 is proposed that a QoS sub-system be specified to extend the 217 recognized property names of the "property" and ôvariableö elements 218 in IRML to include various QoS-related properties. These values 219 include static configuration parameters like QoS policy parameters, 220 and dynamic parameters like network conditions values and processing 221 load of the intermediaries. Note that to utilize these parameters, 222 the ôpropertyö or ôvariableö elements MUST specify a ôsub-systemö 223 attribute of ôQoSö. 225 Furthermore, since these parameters have numerical values, the QoS 226 sub-system also override the ômatchesö and ônon-matchesö attributes 227 of the ôpropertyö element to handle basic arithmetic comparison 228 instead of regular expression. These will be described in the 229 following sub-sections. 231 4.1. QoS Policy Properties 233 The following are the proposed QoS policy parameters to that are 234 defined for the "property" element in the QoS sub-system. These 235 values are access control parameters, thus the rule engine can 236 obtain their values via an interface to an access control module. 237 Specification of such interface/module is out of scope. 239 Property Name Value 240 -------------------------------------------------------------------- 241 "allocated-bandwidth" the allocated bandwidth for the end-user 242 "requested-bandwidth" the requested bandwidth for this connection 243 "available-bandwidth" the amount of bandwidth available for the 244 end-user 245 "delay-bound" the maximum delay requested 247 4.2. Network Status Properties 249 The following are the proposed network status parameters that are 250 defined for the "property" element of the QoS sub-system. These 251 dynamic values reflect the current network link status. The rule 252 engine can obtain these values either via an interface to a traffic 253 monitoring module, or a Simple Network Management Protocol (SMNP) 254 agent [7]. In the case of RTP connections, the values of these 255 parameters can also be extracted from the RTCP sender/receiver 256 reports [8]. Specification of such interface/module is out of scope. 258 Property Name Value 259 -------------------------------------------------------------------- 260 "r-octets-count" the accumulated number of octets received 261 by the end-user 262 "s-octets-count" the accumulated number of octets received 263 by the intermediary 264 "r-packets-count" the accumulated number of packets received 265 by the end-user 266 "s-packets-count" the accumulated number of packets received 267 by the intermediary 268 "r-packets-lost" the total number of packets not received by 269 the end-user 270 "s-packets-lost" the total number of packets not received by 271 the intermediary 272 "r-fraction-lost" the fraction of packets lost reported by 273 the end-user since the previous report 274 "s-fraction-lost" the fraction of packets lost reported by 275 the intermediary since the previous report 276 "r-jitter" the inter-arrival jitter reported by the 277 end-user 278 "s-jitter" the inter-arrival jitter reported by the 279 intermediary 281 Because the rule engine should be stateless, it might be necessary 282 for the module providing the values of the QoS parameters to provide 283 additional information about the difference in the parameters values 284 after a specific interval. 286 Property Name Value 287 -------------------------------------------------------------------- 288 "r-octets-diff" the difference in accumulated number of 289 octets received by the end-user of two most 290 recent consecutive reports 291 "s-octets-diff" the difference in the accumulated number of 292 octets received by the intermediary of two 293 most recent consecutive reports 294 "r-packets-diff" the difference in the accumulated number of 295 packets received by the end-user of two 296 most recent consecutive reports 297 "s-packets-diff" the difference in the accumulated number of 298 packets received by the intermediary of two 299 most recent consecutive reports 300 "r-packets-lost-diff" the difference in the total number of 301 packets not received by the end-user of two 302 most recent consecutive reports 303 "s-packets-lost-diff" the difference in the total number of 304 packets not received by the intermediary of 305 two most recent consecutive reports 306 4.3. Intermediary Load Properties 308 The following are the proposed server load parameters that are 309 defined for the "property" element in the QoS sub-system. These 310 values are system environment parameters, thus the rule engine can 311 obtain their values via an interface to a system module. 312 Specification of such an interface/ module is out of scope. 314 Property Name Value 315 -------------------------------------------------------------------- 316 "system-processing-load" the current processing load in percentage 317 of the intermediary 318 "system-connections" the current number of established end- 319 user connections 321 4.4. Overriding ômatchesö and ônon-matchesö Attributes in QoS Sub- 322 System 324 Since the QoS parameters defined for the ôpropertyö element are all 325 numerical in nature, the ômatchesö and ônon-matchesö attributes of 326 the ôpropertyö element are overridden in the QoS sub-system to 327 handle arithmetic comparison instead of regular expression. In QoS 328 sub-system, the ômatchesö and ônon-matchesö handle two types of 329 arithmetic comparisons: (1) arithmetic relation between the QoS 330 property and a specified numerical constant, and (2) the membership 331 of the QoS property in a specified numerical range. 333 Comparison between QOS property and specified numerical constant can 334 be constructed using the ô<ö, ô>ö, ô>=ö, and ô<=ö operators. For 335 example, the following rule 337 341 will be evaluated to be true if the current system load of the 342 intermediary is less than 40%, and evaluated to be false otherwise. 344 Membership of the QoS parameter in a specified numerical range can 345 be constructed using the ô[min,max]ö, ô[min,max)ö, ô(min, max]ö, and 346 ô(min,max)ö mathematical symbols. For example, the following rule 348 352 will be evaluated to be true if the bandwidth allocated is greater 353 or equal to 128kbps and less than 256kbps. 355 The table below shows the evaluation results when a QoS property is 356 evaluated with various ômatchesö attributes. In the table, ôAö and 357 ôBö represents numerical constants (which can include a decimal 358 point). 360 ômatchesö Attribute Evaluation Result 361 -------------------- --------------------------------- 362 ôAö True if the QoS parameter is greater than A; 367 false otherwise. 368 ô>=Aö True if the QoS parameter is greater than or 369 equal to A; false otherwise. 370 ô[A,B]ö True if the QoS parameter is greater than or 371 equal to A, and less than or equal to B; false 372 otherwise. 373 ô[A,B)ö True if the QoS parameter is greater than or 374 equal to A, and less than B; false otherwise. 375 ô(A,B]ö True if the QoS parameter is greater than A 376 and less than or equal to B; false otherwise. 377 ô(A,B)ö True if the QoS parameter is greater than A 378 and less than B; false otherwise. 380 The ônon-matchesö attribute, when specified instead of ômatchesö, 381 will be evaluated to be true when the arithmetic comparison is 382 evaluated to be false, and vice versa. 384 4.5. The ôcase-sensitiveö Attribute 386 Though the ôpropertyö element in the standard IRML has an optional 387 ôcase-sensitiveö attribute, they are not used in the QoS sub-system. 388 This is a direct consequence of overriding the ômatchesö and ônon- 389 matchesö attributes to handle arithmetic comparison instead of 390 regular expression. Use of the ôcase-sensitiveö attribute is ignored 391 in the QoS sub-system. 393 4.6. The ôcontextö Attribute 395 The current specification of the QoS sub-system does not define the 396 interpretation of the ôcontextö attribute. It may be possible to use 397 this attribute to identify the interface/module by which the value 398 of the QoS parameter is extracted, such as ôSNMPö or ôRTCPö. Until 399 its appropriate interpretation can be revealed after further 400 analysis, the use of the ôcontextö attribute is ignored by the QoS 401 sub-system. 403 5. Examples 405 The first example below illustrates the case where the adaptation of 406 HTML page to WML page is performed with consideration to the 407 allocated bandwidth of the client. 409 410 411 413 414 415 416 opes://localhost/html2wml?target=tiny 417 418 419 420 422 423 424 425 opes://localhost/html2wml?target=small 426 427 428 429 431 432 433 434 opes://localhost/html2wml?target=large 435 436 437 438 440 The second example illustrates the scenario where an adaptation 441 service is carried out locally or remotely based on the system 442 processor load of the OPES intermediary. It also illustrates the 443 adaptations of video stream based on the connection status. 445 446 448 450 451 452 454 455 456 opes://video.adpat.server/video-adpat 457 458 459 460 461 =80ö 462 sub-system=öQoSö> 463 464 465 467 468 469 opes://localhost/video-adpat 470 471 472 473 474 476 The third example shows the adaptation of different content format 477 for different traffic conditions gathered from the network 478 monitoring module for a specific network node or a group of network 479 nodes in delivering Audio-Visual content. Access to the types of 480 content format is based on the different network conditions supplied 481 by the network monitoring module. The rule for accessing the type of 482 content format is being specified based on the type of property 483 used. 485 486 487 488 489 490 491 opes://stillimage.server/jpeg-only 492 493 494 495 496 497 498 499 501 502 503 opes:// videoFEC.correct.server/video-FEC< 504 505 506 507 508 509 510 512 6. IAB Considerations 514 This proposal is an extension to the IRML Specifications [2]. It is 515 to the authorsÆ best knowledge that there exists no inconsistency 516 between this memo and the IRML Specification in regards to IABÆs 517 architectural and policy considerations. 519 7. Security Considerations 521 All security considerations in [2] are applicable to the QoS sub- 522 system. There is no security issue to the authorsÆ best knowledge 523 that is specific to the QoS sub-system. 525 8. References 527 [1] Bradner, S., "The Internet Standard Process û Revision 3", BCP 9, 528 RFC 2026, October 1996. 530 [2] Beck, A., Hoffman, M., "IRML: A Rule Specification Language for 531 Intermediary Services", Work In Progress, draft-beck-opes-irml- 532 02.txt, November 2001. 534 [3] Tomlinson, G., Orman, H., Condry, M., Kempf, J., "Extensible Proxy 535 Services Framework", Work In Progress, draft-tomlinson-epsfw- 536 00.txt, 2000. 538 [4] Beck, A., Hoffman, M., Condry, M., "Example Services for Network 539 Edge Proxies", Work In Progress, draft-beck-opes-esfnep-01.txt, 540 November 2000. 542 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 543 Levels", BCP 14, RFC 2119, March 1997. 545 [6] Wu., D., Hou, Y. T., Zhang, Y., "Scalable Video Coding and 546 Transport over Broad-band Wireless Networks", Proc. IEEE, vol. 89, 547 no. 1, pg 6-20, Jan 2001. 549 [7] Case, J.D., Fedor, M., Schoffstall, M.L., Davin, C., ôSimple 550 Network Management Protocol (SNMP)ö, RFC 1157, May 1990. 552 [8] Schulzrine, H., Casner, S., Frederick, R., Jabcobson, V., "RTP: A 553 Transport Protocol for Real-Time Applications", RFC 1889, January 554 1996. 556 9. Author's Address 558 Chan-Wah Ng 559 Panasonic Singapore Laboratories Pte Ltd 560 Blk 1022 Tai Seng Ave #04-3530 561 Tai Seng Industrial Estate 562 Singapore 534415 563 Phone: (+65) 550 5420 564 Email: cwng@psl.com.sg 566 PekûYew TAN 567 Panasonic Singapore Laboratories Pte Ltd 568 Blk 1022 Tai Seng Ave #04-3530 569 Tai Seng Industrial Estate 570 Singapore 534415 571 Phone: (+65) 550 5470 572 Email: pytan@psl.com.sg 574 Hong CHENG 575 Panasonic Singapore Laboratories Pte Ltd 576 Blk 1022 Tai Seng Ave #04-3530 577 Tai Seng Industrial Estate 578 Singapore 534415 579 Phone: (+65) 550 5477 580 Email: hcheng@psl.com.sg