idnits 2.17.1 draft-balabanian-intserv-mpeg4-dmif-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-19) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 9 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 465: '... the network. p MUST be greater than ...' RFC 2119 keyword, line 467: '...then p MUST be set to infinity....' RFC 2119 keyword, line 651: '...the path MUST be determined and added ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 464 has weird spacing: '... source may i...' == Line 507 has weird spacing: '...ich the recei...' == Line 568 has weird spacing: '...ich the recei...' == Line 747 has weird spacing: '...t state which...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 818 looks like a reference -- Missing reference section? '2' on line 821 looks like a reference -- Missing reference section? '3' on line 824 looks like a reference -- Missing reference section? '4' on line 827 looks like a reference -- Missing reference section? '6' on line 834 looks like a reference -- Missing reference section? '12' on line 706 looks like a reference -- Missing reference section? '8' on line 842 looks like a reference -- Missing reference section? '9' on line 845 looks like a reference -- Missing reference section? 'M' on line 607 looks like a reference -- Missing reference section? '7' on line 839 looks like a reference -- Missing reference section? '11' on line 758 looks like a reference -- Missing reference section? '5' on line 830 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services Working Group 2 Internet Draft Balabanian-Nortel 3 draft-balabanian-intserv-mpeg4-dmif-00.txt 4 Sept. 19, 1998 5 Expires: March 23, 1999 7 The Use of MPEG-4/DMIF and RSVP with Integrated 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 months 17 and may be updated, replaced, or made obsolete by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 ABSTRACT 31 This draft proposal explains how the ISO/IEC MPEG DMIF 32 (Delivery Multimedia Integration Framework) can be used to 33 carry MPEG-4 streams according to required media specific QoSs 34 using RSVP with Integrated Services. 36 Comments are solicited and should be addressed to the working 37 group's mailing list at int-serv@isi.edu and/or the authors. 39 1 Introduction 41 MPEG-4 is a recent standard from ISO/IEC for the coding of natural 42 and synthetic audio-visual data in the form of audiovisual objects 43 that are arranged into an audiovisual scene by means of a scene 44 description [1][2][3][4]. This draft proposal specifies how MPEG-4 45 QoS requirements for flows are mapped into RSVP with IETF Integrated- 46 Services in the instance of ISO/IEC MPEG multimedia delivery 47 integration framework (DMIF). This would allow the use of IP networks 48 as transports for MPEG-4 streams requiring some level of QoS. 50 This draft proposal provides a solution for discussion in IETF 51 IntServ and ISO/IEC MPEG technical communities in order to identify 52 issues in using of MPEG-4/DMIF with RSVP and incorporate the results. 54 This would lead to the finalization of the specification on how DMIF 55 can be used to carry MPEG-4 streams according to media specific QoSs 56 using RSVP with Integrated Services. 58 The MPEG-4 standards are versioned each beyond V1 contain 59 backward compatible extensions. MPEG-4 V1 is targeted to become ISO 60 International Standard on December 1998 and each subsequent version 61 will be displaced approximately by a year. MPEG-4 V2 is targeted for 62 February 2000. DMIF is part 6 of the MPEG-4 standard. 64 1.1 The DMIF Model 66 DMIF as an integration framework uses a uniform procedure at the DAI 67 interface to access the MPEG-4 content irrespective whether the content 68 is broadcast, stored on a local file or obtained through interaction 69 with a remote end-system. The model is shown in Figure 1 below. 71 ! +---+ +-----------+ +-----------+ +-----------+ 72 ! | | |Local DMIF | |Remote DMIF| |Remote App.| 73 +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst 74 | | ! | M | | | | emulated) | | emulated) |<-----source 75 |Local| ! | I | +-----------+ +-----------+ +-----------+ 76 | | ! | F | +-----------+ +-----------+ +-----------+ 77 |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File 78 | | ! | F | |for Local | |(locally | |(locally |<-----source 79 | | ! | i | | Files | | emulated) | | emulated) | 80 | | ! | l | +-----------+ +-----------+ +-----------+ 81 | | ! | t | +-----------+ ! +---+ / ---- \ 82 | | ! | e | |Local DMIF | ! |Sig| | --- ---- | 83 +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the 84 ! | | | Service | ! | | | ---- ----- |scope of DMIF 85 ! +---+ +-----------+ ! +---+ | ----- | 86 DAI DNI | ^ | 87 \_____ |________/ 88 | 89 | +---+!+------+!+------+ 90 | |Sig|!|Remote|!|Remote| 91 +->|map|!| DMIF |!| App. | 92 | |!|(real)|!|(real)| 93 +---+!+------+!+------+ 94 DNI DAI 96 Figure 1: The DMIF model covers broadcast, local file storage 97 and remote service with a uniform procedure for 98 application transparency 100 The specific instance of interest in this draft proposal is the 101 interaction with a remote end-system. For this case DMIF uses internal 102 (informative) DMIF-Network Interface(DNI)to map the controls obtained 103 from the application through DAI into the various signaling appropriate 104 to the various networks. The default end-to-end DMIF signaling (DS) 105 protocol which corresponds to DNI is specified in DMIF V1 [4]. 107 1.5.2 Establishing channels using DAI 109 Of interest in this draft proposal is the process by which a channel 110 is established. Figures 2 and 3 below show the flow of signals across 111 the DAI and the RSVP APIs, between a DMIF Receiver and its Sender. 113 a) Precondition for the procedure in Figure 2: 115 The MPEG-4 service has been initiated and the DMIF signaling channel 116 "DS_" between the originating and the target DMIF [4] has been 117 successfully established, after capability exchange. The receiver 118 application is in possession of the Elementary Stream Descriptors [1] 119 from which it selects the streams and obtains the media based QoS. 121 b) Channel establishment procedure 123 RSVP RSVP 124 API API 125 DMIF | IP | DMIF 126 DAI (Sndr) DNI| Network |DNI (Rcvr) DAI 127 I-----------I +---------------+ I----------I 128 I I | | I I 129 DA_ChannelAdd I 3 I | DS_ChannelAdd | I 2 1 I DA_ChannelAdd 130 <------------0<-----------------------------0<------((ES-Id,dir, 131 ((ES-Id,dir)) I I |((CAT,dir, | I I qos)) 132 I I | ,qos,ES-Id))| I I 133 I I | | I I 134 I I | | I I 135 ((rsp)) I I | | I I 136 4 ----->I I | | I I 137 I Maps I | | I I 138 I Channels I | | I I 139 I into I | | I I 140 I specific I | | I I 141 I RTP flows I | | I I 142 I I DN_TransMuxSetup| I I 143 I 5 ----------------------------> I 144 I ((resdcrptr,st-qos)) I I 145 I I ((resdcrptr,rsp)) I I 146 I <--------------------------- 6 I 147 I I | | I I 148 I I | Sender_TSpec | I I 149 I 7 int1----------------->I I 150 I I | ADSpec | I I 151 I I------------------>I I 152 I I | 0-0 | I I 153 I I | / \ | I I 154 I I | / \ | I I 155 I I |-0 \ | I I 156 I I | 0-- | I I 157 I I | FlowSpec | I I 158 I 8 I<----------------- int2 I 159 I reduce I | | I I 160 readjust<--- RTP to I | | I I 161 AL-PDU I new MTU I | | I I 162 to new I I | | I I 163 MTU I I | | I I 164 I I | | I I 165 I I | ((rsp)) | I I ((rsp)) 166 I --------------------------->0--------------> 167 I I | 9 | I 10 I 168 I-----------I +---------------+ I----------I 170 Figure 2: Establishment of downstream channels in MPEG-4 using DAI 171 Signaling(For brevity only the relevant parameters are shown) 173 Step 1: 174 The receiver application passes a DA_ChannelAdd() requesting channels 175 for Elementary Streams ES-Id1 through Es-Idn. Each ES-Id is associated 176 with direction and QoS. 178 Step 2: 180 DMIF generates Channel Association Tag CAT corresponding to each 181 ES-Id and sends the requests to the sender DMIF. 183 Step 3: 184 At the sender DMIF DA_ChannelAdd is passed to the application. 186 Step 4 187 The sender application may respond positively to each ES-Id request. 189 Step 5: 190 DMIF groups the channels into RTP flows [6][12] based on priority, QoS 191 parameter values and traffic load requested for each channel. The 192 pooling policy is outside the scope of DMIF. 194 After the proper grouping of channels into flows. The stream-QoS 195 (st-qos) is derived (for either a single or aggregate flows, see 196 section 2.3) in order to be able to meet the QoS requirements for the 197 aggregate channels. 199 UDP/IP ports are assigned to the streams at the sender DMIF and 200 a UDP/IP resourceDescriptors (resdcrptr) are sent along with the 201 stream-QoS to the receiver. 203 Step 6: 204 the receiver DMIF completes the local UDP/IP ports for the requested 205 streams in the UDP/IP resourceDescriptors in response to the 206 DN_TransMuxSetup. 208 Step 7: 209 The UDP/IP resourceDescriptors and the stream-QoS descriptors are 210 used to start RSVP PATH (int1) with Sender_Tspec and ADSpec. This 211 is received at the receiver DMIF and RESV message (int2) is generated 212 with the FlowSpec. The process of int1 and int2 is repeated regularly to 213 maintain the soft states in the IP network. 215 Step 8: 216 After receiving the first RESV message a DA_ChannelInf() (new proposed) 217 message is used to update the MTU size for the AL-PDUs of the 218 stream [6]. This allows the conformance of the stream to the Class of 219 Integrated Service requested. This message is repeated at every change 220 of the MTU value received in int2. 222 Step 9: 223 The response to the DS_ChannelAdd is sent after receiving the first 224 RESV message. 226 Step 10: 227 At the receiver DMIF the response to the DA_ChannelAdd is sent 228 indicate successful establishment of the channels with the 229 requested QoSs. 231 c) Decoder backchannel establishment procedure 233 To be added. 235 d) channel deleted procedures 237 To be added. 239 2 Media QoS mapping into RSVP with Integrate Services 241 2.1 Media Based QoS and Traffic Load 243 The following table provides the media QoS specified by the 244 content provider irrespective of the network used for 245 the transport of the media. No QoS values will be available 246 in DMIF V2 The only parameters being specified in V1 are 247 for characterizing the traffic load of the srtream (the 248 last 3 rows in the table below). 250 +=====================+=====================================+ 251 | Media | Meaning of the | 252 | QoS_QualifierTag | ES Media QoS | 253 +=====================+=====================================+ 254 | MAX_DELAY |Maximum delay per AU (microseconds) | 255 | (DMIF V2) |measured over 1 sec. | 256 +---------------------+-------------------------------------+ 257 | AVG_DELAY |Average delay per AU allowed | 258 | (DMIF V2) |(microseconds) measured over 1 min | 259 +---------------------+-------------------------------------+ 260 | Dejitter Buffer | Bytes reserved for the removal of | 261 | (DMIF V2) | transport jitter from the steam | 262 +---------------------+-------------------------------------+ 263 | LOSS_PROB |Probability of loss of any single AU | 264 | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | 265 +===========================================================+ 266 | MAX_AU_SIZE |Maximum size of an AU (Bytes) | 267 | (DMIF V1) | | 268 +---------------------+-------------------------------------+ 269 | MAX_AU_RATE |Maximum arrival rate of an AUs | 270 | (DMIF V1) |(AU-PDU/second) | 271 +---------------------+-------------------------------------+ 272 | AVG_RTP_SIZE |Average size of AUs (Bytes) | 273 | (DMIF V1) | | 274 +---------------------+-------------------------------------+ 275 2.2 Other media stream qualifiers 277 In addition to the traffic load in DMIF V1 the stream priority 278 is specified: 280 Priority: Indicates a 32 level value for the importance of the 281 stream related to other streams in the session. 283 2.3 Derivation of the Media QoS for the RTP-PDU stream 285 The Sync Layer in MPEG-4 fragments the Access Units into 286 SL-PDUs and adds synchronization information [1]. 288 The AL-PDUs in turn can be mapped to RTP-PDUs as follows [6]: 289 RTP-PDU 1:1 SL-PDU 290 RTP-PDU 1:N SL-PDU 291 2.3.1 The case RTP-PDU 1:1 SL-PDU 293 The table below shows the stream QoS for the case when a single ES is 294 mapped into the RTP PDU. Only the traffic load parameters(the last 3 295 rows in the table below) are specified in DMIF V1 targeted to be an 296 ISO/IEC International Standard in December 1998. 298 +=====================+=====================================+ 299 | RTP Stream | Derivation from the | 300 | QoS_QualifierTag | ES Media transport-QoS | 301 +=====================+=====================================+ 302 | MAX_DELAY of RTP PDU|Maximum delay per AU (microseconds) | 303 | (DMIF V2) |measured over 1 sec. | 304 +---------------------+-------------------------------------+ 305 | AVG_DELAY of RTP PDU|Average delay per AU allowed | 306 | (DMIF V2) |(microseconds) measured over 1 min | 307 +---------------------+-------------------------------------+ 308 | Dejitter Buffer | Adjusted for the overhead of the | 309 | for the RTP stream | RTP PDU | 310 | (DMIF V2) | | 311 +---------------------+-------------------------------------+ 312 | LOSS_PROB of RTP PDU|Probability of loss of any single AU | 313 | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | 314 +===========================================================+ 315 | MAX_RTP_SIZE |Maximum size of an AU (Bytes) | 316 | (DMIF V1) |Plus AL-PDU and RTP overhead | 317 +---------------------+-------------------------------------+ 318 | MAX_RTP_RATE |Maximum arrival rate of AUs | 319 | (DMIF V1) |(RTP-PDU/second) | 320 +---------------------+-------------------------------------+ 321 | AVG_RTP_SIZE |Average size of AUs (Bytes) | 322 | (DMIF V1) |Plus AL-PDU and RTP overhead | 323 +---------------------+-------------------------------------+ 324 2.3.2 The case RTP-PDU 1:N SL-PDU 326 The table below shows the stream QoS for the case when multiple ES are 327 aggregated into the RTP PDU. Only the traffic load parameters (the last 328 3 rows in the table below) are specified in DMIF V1 targeted to be an 329 ISO/IEC International Standard in December 1998. 331 +=====================+=====================================+ 332 | RTP Stream | Derivation from the | 333 | QoS_QualifierTag | ES Media QoS | 334 +=====================+=====================================+ 335 | MAX_DELAY of RTP PDU|Least Maximum delay per AU from | 336 | (DMIF V2) |among the N AL-PDUs(microseconds) | 337 | |measured over 1 sec. | 338 +---------------------+-------------------------------------+ 339 | AVG_DELAY of RTP PDU|Average delay per AU allowed | 340 | (DMIF V2) |(microseconds) measured over 1 min. | 341 +---------------------+-------------------------------------+ 342 | Dejitter Buffer | Total of dejitter buffers adjusted | 343 | for the RTP stream | for the overhead of the RTP PDU | 344 | (DMIF V2) | | 345 +---------------------+-------------------------------------+ 346 | LOSS_PROB of RTP PDU|Least Probability of loss of any | 347 | (DMIF V2) |single AU from the N AL-PDUs | 348 | |(Fraction (0.00 - 1.00) over 1 sec. | 349 +===========================================================+ 350 | MAX_RTP_SIZE |Sum of the MAX_AU_SIZEs of from | 351 | (DMIF V1) |each of the N AL-PDUs Plus AL-PDU | 352 | |and RTP overhead | 353 +---------------------+-------------------------------------+ 354 | MAX_RTP_RATE |Highest MAX_AU_RATE of AUs from each | 355 | (DMIF V1) |of the N AL-PDUs (RTP-PDU/second) | 356 +---------------------+-------------------------------------+ 357 | AVG_RTP_SIZE |Sum of Average size of AUs from | 358 | (DMIF V1) |each of the N AL-PDUs Plus | 359 | |AL-PDU and RTP overhead (Bytes) | 360 +---------------------+-------------------------------------+ 362 Note all the MPEG-4 streams chosen for aggregation over an RTP 363 stream belong to the same stream priority level identified by 364 the Sync Layer. 366 2.4 Choice of Integrated Service QoS service 368 Each elementary Stream is assigned one of the 32 levels of stream 369 priority [1]. 371 "streamPriority - indicates a relative measure for the priority 372 of this Elementary Stream. An Elementary Stream with a higher 373 streamPriority is more important than one with a lower 374 streamPriority. The absolute values of streamPriority are not 375 normatively defined."[1] 376 "streamPriority: Provides the priority of the channel. Lower 377 values mean lower priority." [4] 379 These priorities relate to the streams within one MPEG-4 session. 380 On top of these priorities one can superimpose the network 381 priority classes. These relate each individual stream to other 382 streams on the network. It is conceivable and even logical that 383 some mapping algorithms may map higher stream priority values 384 to a higher network priority classs. This policy matter is outside the 385 scope of DMIF. 387 The integrated service classes are described below: 389 Best Effort (the IP network default) 391 DMIF may monitor the channel's performance and request controlled- 392 load service from the network only when best-effort service is not 393 providing acceptable performance. This provides flexibility and 394 offers cost savings in environments where levels of service above 395 best-effort incur a charge. 397 The DMIF layer may choose based on a policy to monitor the 398 performance parameters as defined in [12] in order to take corrective 399 action and notify the user of the necessity for a corrective action. 401 Controlled-Load Service[8] 403 Tightly approximates the behavior visible to applications receiving 404 best-effort service *under unloaded conditions* from the same series 405 of network elements. 407 The controlled-load service is best suited to those applications 408 which can usefully characterize their traffic requirements, this 409 includes the "continuous media" data, such as digitized audio or 410 video. 412 This service is not isochronous and does not provide any explicit 413 information about transmission delay. MPEG-4 with end-to-end timing 414 mechanism can use it similar to the best-effort service. 416 Guaranteed Quality of Service[9] 418 Assures level of bandwidth that, when used by a policed flow, produces 419 a delay-bounded service with no queuing loss for all conforming 420 datagrams. 422 The choice of any one of the above classes could be made as follows: 424 1- If MAX_DELAY for the RTP PDU is specified then the attempt is 425 made to use a Guaranteed Quality Service. 426 2- If LOSS_PROB of RTP PDU is specified then the Controlled-Load 427 Service is attempted. 428 3- If MAX_DELAY is not specified and LOSS_PROB is not specified 429 then use the Best Effort 431 Only experience will dictate the best formula for mapping and could be 432 a differentiating factor between commercial mapping algorithm softwares. 434 2.5 Building the Sender_TSpec 436 The Sender_TSpec specifies the load which is used to ensure adequate 437 resources are present at network elements in case of Controlled-Load 438 and Guaranteed Services. 440 The Sender_TSpec parameters and their derivation from the RTP Media 441 QoS follows: 443 -- The token bucket has a bucket depth, b 445 b could be approximated as follows: 446 b >= T*MAX_RTP_RATE(MAX_RTP_SIZE - AVG_RTP_SIZE) 448 Where T is the time period. 450 [Author's note: How is the value of T obtained?] 451 [Author's note: DMIF is considering the use of T*(MAX_RTP_BITRATE- 452 AVG_RTP_BITRATE)/8] 454 -- Bucket rate, r 456 r could be approximated as follows: 457 r = MAX_RTP_RATE*AVG_RTP_SIZE 459 [Author's note: A better measure is required for this such as 460 AVG_RTP-BITRATE. This matter is under consideration in DMIF)] 462 -- The peak rate, p 464 The peak rate is the maximum rate at which the source may inject 465 bursts of traffic into the network. p MUST be greater than or equal to 466 the token bucket rate, r. If the peak rate is unknown or unspecified, 467 then p MUST be set to infinity. 469 p could be approximated as follows: 470 p = MAX_RTP_RATE*MAX_RTP_SIZE 472 [Author's note: A better measure is required for this such as 473 MAX_RTP-BITRATE. This matter is under consideration in DMIF] 474 -- The minimum policed unit, m 476 Document [4] does not specify MIN_AU_SIZE. If a parameter is designated 477 it can be used to derive the MIN_RTP_SIZE as follows: 479 Case of RTP-PDU 1:1 AL-PDU 480 MIN_RTP_SIZE = MIN_AU_SIZE Plus AL-PDU and RTP overhead 482 Case of RTP-PDU 1:N AL-PDU 483 MIN_RTP_SIZE = Sum of the MIN_AU_SIZEs from each of the N AL-PDUs 484 Plus AL-PDU and RTP overhead 486 m = MIN_RTP_SIZE IP datagram size 488 [Author's note: How critical is the specification of a minimum datagram 489 size? Will it result in discarding the datagram if a larger m is 490 used in calculating the violation of the rT+b bound, see 2.6.1?] 492 -- The maximum datagram size, M 494 M = MAX_RTP_SIZE IP datagram size 496 2.6 Forming the Receiver FlowSpec 498 Two cases are covered below, one for the controlled load service 499 and the other for the guaranteed service. 501 2.6.1 FLOWSPEC object when requesting Controlled-Load service 503 In this case the flow object contains the TSpec to which the 504 network shall respond in providing the QoS. 506 In MPEG-4/DMIF the sender makes available to a receiver a set of 507 Elementary Stream descriptors from which the receiver chooses 508 based on its capability to decode the stream when received. 510 Since this is done before the PATH message is received, the Sender 511 TSpec in the PATH therefore already reflects the receiver's choice. 512 As a result the corresponding parameter values may be copied into 513 the FLOWSPEC except for the M parameter which is replaced by 514 the PATH-MTU from the ADSpec in the PATH message. 516 The TSpec contains the following parameters. 518 -- The token bucket has a bucket depth, b 520 This value is kept the same as the one received in the 521 SENDER_TSPEC passed across the RSVP API 522 -- Bucket rate, r 524 This value is kept the same as the one received in the 525 SENDER_TSPEC passed across the RSVP API 527 -- The peak rate, p 529 This parameter may always be ignored by a Controlled-Load service 531 -- The minimum policed unit, m 533 This value is kept the same as the one received in the Sender TSpec 535 -- The maximum datagram size, M 537 The maximum packet size parameter [M] should be set to the value of 538 the smallest path MTU, which the receiver learns from information in 539 arriving RSVP ADSPEC objects (from different senders in case of 540 incasting not presently covered in [1]& [4]). Alternatively, if 541 the receiving application has built-in knowledge of the maximum packet 542 size in use within the RSVP session, and this value is smaller than 543 the smallest path MTU, [M] may be set to this value. Note that 544 requesting a value of [M] larger than the service modules along the 545 data path can support will cause the reservation to fail.[7] 547 The TSpec's token bucket parameters require that traffic must obey 548 the rule that over all time periods, the amount of data sent does 549 not exceed rT+b, where r and b are the token bucket parameters and 550 T is the length of the time period. For the purposes of this 551 accounting, links must count packets that are smaller than the 552 minimal policing unit m to be of size m. Packets that arrive at 553 an element and cause a violation of the the rT+b bound are considered 554 nonconformant. 556 A measure that is required in MPEG-4/DMIF for the acceptance of the path 557 in a controlled service is a value representing LOSS_PROB. These are not 558 presently covered in [8]. They therefore need to be monitored [12] along 559 with the MAX_DELAY and the AVG_DELAY as well as the Jitter using a 560 mechanism such as RTCP Reports. 562 2.6.2 FLOWSPEC Object when Requesting Guaranteed Service 564 In this case the FLOWSPEC object contains the Rspec in addition to 565 the TSpec to which the network shall respond in providing the QoS. 567 In MPEG-4/DMIF the sender makes available to a receiver a set of 568 Elementary Stream descriptors from which the receiver chooses 569 based on its capability for decoding the stream when received. 571 Since this is done before the PATH message is received, the Sender 572 TSpec in the PATH therefore already reflects the receiver's 573 choice. As a result the corresponding parameter values may be copied 574 into the FLOWSPEC except for the M parameter which is replaced by 575 the PATH-MTU from the ADSpec in the PATH message. 577 The TSpec contains the following parameters. 579 -- The token bucket has a bucket depth, b 581 This value is kept the same as the one received in the 582 SENDER_TSPEC passed across the RSVP API 584 -- Bucket rate, r 586 This value is kept the same as the one received in the 587 SENDER_TSPEC passed across the RSVP API 589 -- The peak rate, p 591 This parameter is used to optimize the buffer resources 592 in the network. 594 -- The minimum policed unit, m 596 This value is kept the same as the one received in the Sender TSpec 598 -- The maximum datagram size, M 600 The maximum packet size parameter [M] should be set to the value of 601 the smallest path MTU, which the receiver learns from information in 602 arriving RSVP ADSPEC objects (from different senders in case of 603 incasting not presently covered in the [1]& [4]). Alternatively, if 604 the receiving application has built-in knowledge of the maximum packet 605 size in use within the RSVP session, and this value is smaller than 606 the smallest path MTU, [M] may be set to this value. Note that 607 requesting a value of [M] larger than the service modules along the 608 data path can support will cause the reservation to fail.[7] 610 The network is not permitted to fragment datagrams as part of 611 guaranteed service. Datagrams larger than the MTU of a link are 612 policed as nonconformant which means that they will be policed 613 according to the Policing rules. 615 The network applies the rule that over all time periods, the amount 616 of data sent cannot exceed M+min[pT, rT+b-M], where r and b are the 617 token bucket parameters, M is the maximum datagram size, and T is the 618 length of the time period and p is the peak rate (note that when p is 619 infinite this reduces to the standard token bucket requirement). For 620 the purposes of this accounting, datagrams which are smaller than the 621 minimum policing unit are counted to be as size m. Datagrams which 622 arrive at an element and cause a violation of the the M+min[pT, rT+b-M] 623 bound are considered nonconformant. 625 Nonconforming datagrams are treated as best-effort datagrams or dropped. 626 All flow controls that are normally applied to best effort datagrams are 627 applied to that datagram too. 629 Datagrams bigger than the MTU of a network element are considered 630 nonconformant and classified as best effort (and will then either be 631 fragmented or dropped according to the element's handling of best 632 effort traffic). 634 The RSpec contains the following values. 636 -- Rate value, R 638 The R value is calculated to meet the value of the AVG_DELAY of 639 the RTP PDU from the stream-QoS (for a single flow or aggregate of 640 flows) using the formula in section 2.6.2.1. 642 -- Slack value, S 644 In order to derive the Slack in the RSpec the MAX_DELAY of the 645 RTP PDU is used from the stream-QoS. (for a single flow or aggregate of 646 flows). 648 Guaranteed service does not control the minimal or average delay of 649 datagrams, merely the maximal queuing delay. Furthermore, to 650 compute the maximum delay a datagram will experience, the latency of 651 the path MUST be determined and added to the guaranteed queuing 652 delay. (However, a conservative bound of the latency can be computed 653 by observing the delay (Minimum path latency in the ADSpec) experienced 654 by any one packet).[9] 656 The MAX_DELAY is reduced by the latency of the path and the resulting 657 value is termed the required Delay Dreq. 659 2.6.2.1 Calculating the delays and the slack 661 The steps below show the end-to-end queuing derivation and 662 subsequently the derivation of the Slack. 664 The maximum end-to-end queuing delay (as characterized by Ctot and 665 Dtot) and bandwidth (characterized by R) provided along a path will 666 be stable. That is, they will not change as long as the end-to-end 667 path does not change.[9] 669 Consider an application that is intolerant of any lost or late 670 datagrams. It uses the advertised values Ctot and Dtot and the TSpec 671 of the flow, to compute the resulting delay bound from a service 672 request with rate R. 674 The end-to-end delay bound is 675 [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and 676 (M+Ctot)/R+Dtot for r<=p<=R [9] 677 While sending applications are encouraged to set the peak rate parameter, 678 it is always acceptable to ignore the peak rate for the purposes of 679 computing end-to-end delays. The result is simply an overestimate of the 680 delay. The end-to-end delay without the peak rate is b/R+Ctot/R+Dtot.[9] 682 As an example [9] for the use of the slack term, consider the case where 683 the required end-to-end delay MAX_DELAY is larger than the maximum delay 684 of the fluid flow system. The latter is obtained by setting R=r in 685 the fluid delay formula (for stability, R>=r must be true), and is 686 given by 688 b/r + Ctot/r + Dtot. 690 In this case the slack term is 692 S = MAX_DELAY - (b/r + Ctot/r + Dtot). 694 If S<0 then the path is refused by the receiver. Otherwise the value 695 is included in the S field of the RSpec. 697 Also if the Minimum path latency from the Sender ADSpec is more than 698 AVG_DELAY the receiver shall refuse the path. However DMIF needs to 699 monitor the performance for AVG_DELAY and take the proper measure 700 when the value is larger than required by the Application. 702 A measure that is required in MPEG-4/DMIF for the acceptance of 703 the path in a controlled service is some value representing 704 LOSS_PROB. These are not presently covered in [8]. They therefore 705 need to be monitored along with the Jitter using a mechanism 706 such as RTCP [12]. 708 Guaranteed service is invoked by specifying the traffic (TSpec) and 709 the desired service (RSpec) to the network. A service request for 710 an existing flow that has a new TSpec and/or RSpec is treated as a 711 new invocation, in the sense that admission control is reapplied to 712 the flow. Flows that reduce their TSpec and/or their RSpec (i.e., 713 their new TSpec/RSpec is strictly smaller than the old TSpec/RSpec 714 according to the ordering rules described in [9]) are not denied 715 service. 717 2.7 Reacting to the FlowSpec in the network and at the Sender [7] 719 When a receiver originates a reservation request, it can also 720 request a confirmation message to indicate that its request was 721 (probably) installed in the network. In order to reduce the traffic 722 however the confirmation may be requested in every n RESV messages, 723 where the value of n is network dependent. 725 The RSVP processes in the network pass the FlowSpec reservation 726 request to admission control and policy control. If either test 727 fails, the reservation is rejected and the RSVP process returns 728 an error message to the receiver. If both succeed, the desired 729 QoS is defined by FlowSpec passed to the sender[11]. 731 MPEG-4/DMIF version 1 [1][4] do not use multicast. Therefore it is 732 assumed in this draft proposal that the value of the TSpec remains 733 unchanged from that sent by the receiver and no multicast or 734 heterogeneous source branch points are used in MPEG-4/DMIF version 1. 735 However this is a subject under consideration in DMIF Version 2 or 736 later. 738 In the case of MPEG-4/DMIF Version 1 [1][4], the values in the TSpec 739 received from the Receiver is the same as the Sender_Tspec in all 740 aspects except for the M value. This is set to the smallest acceptable 741 MTU of the data path from that sender to the session receiver. This 742 MTU should be used by the sending application to size its packets. 744 Any packets larger than this MTU may be delivered as best-effort rather 745 than being covered by the session's resource reservation. 747 The network creates an RSVP soft state which must be periodically 748 refreshed by PATH and RESV messages. The state is deleted if no 749 matching refresh messages arrive before the expiration of a "cleanup 750 timeout" interval. State may also be deleted by an explicit 751 "teardown" message. At the expiration of each "refresh timeout" 752 period and after a state change, RSVP scans its state to build and 753 forward PATH and RESV refresh messages to succeeding hops. 755 RSVP "teardown" messages remove path or reservation state 756 immediately. Although it is not necessary to explicitly tear down 757 an old reservation, it is recommended that all end hosts send a 758 teardown request as soon as an application finishes[11]. There are 759 two types of RSVP teardown message, PathTear and ResvTear. A 760 PathTear travels towards the receiver and ResvTear travels toward 761 the sender. A teardown request may be initiated either by an 762 application in an end system (sender or receiver), or a network 763 element as the result of state timeout or service preemption. 765 There are two RSVP error messages, PathErr and ResvErr: 767 PathErr messages are very simple; they report errors in processing 768 Path messages and are simply sent upstream to the sender that 769 created the error. There are only a few possible causes of path 770 errors. 772 ResvErr (reservation error) messages report errors in 773 processing Resv messages, or they may report the spontaneous 774 disruption of a reservation, e.g., by administrative 775 preemption. There are a number of ways for a syntactically valid 776 reservation request to fail at some node along the path. 778 2.8 Open Issues 780 1) In DMIF [4], no primitive exists to indicate the desired MTU size 781 of the AL_PDU. This is important for operation with RSVP in order 782 to be conformant to the M sent back in the FlowSpec of the RESV 783 message. The Sync Layer must use this information to fragment the 784 AU before they are sent across the DA_Data of the DAI. the proposal 785 is to include DA_ChannelInf(). 787 2) During the lifetime of the flow it is conceivable because of changes 788 in conditions within the network the MTU message gets changed. In 789 this case the RESV message will indicate a new value for M. In the 790 specific case if the M is lower than the present value it shall 791 require that the Sync Layer be informed. For this reason an 792 DA_CahnnelInf() message may be required to be added to DMIF [4]. 794 3) The Media QoS needs to include a MIN-AU-SIZE parameter which shall 795 be used to generate the MIN-RTP-SIZE parameter for the RTP stream. 797 This will be used to derive m which is the minimum policed datagram 798 size. However in case it is missing a policy may use a fraction of 799 the AVG_RTP_SIZE to derive m. 801 4) Require to verify and improve on the mapping of the media based QoS 802 into Integrated Service parameters including suggestions on alternate 803 media based QoS parameters. 805 A Authors' Addresses 807 Vahe Balabanian 808 Nortel 809 P.O.Box 3511, St. C 810 Ottawa, Ontario 811 Canada K1Y 4H7 813 Tel: 613-763-4721 814 Email: balabani@nortel.ca 816 B Bibliography 818 [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" May 1998, obtained from 819 the MPEG Home Page http://drogo.cselt.it/mpeg/ 821 [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" May 1998, obtained from 822 the MPEG Home Page http://drogo.cselt.it/mpeg/ 824 [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" May 1998, obtained from 825 the MPEG Home Page http://drogo.cselt.it/mpeg/ 827 [4] ISO/IEC 14496-6 CD "DMIF" May 1998, obtained from 828 the MPEG Home Page http://drogo.cselt.it/mpeg/ 830 [5] Schulzrinne, Casner, Frederick, Jacobson "RTP: A Transport 831 Protocol for Real Time Applications" draft-ietf-avt-new-00, 832 Internet Engineering Task Force, Dec. 1998. 834 [6] Carsten, Balabanian, Basso, Civanlar, hoffman, Speer, 835 Schulzrinne, 'RTP payload format for MPEG-4 Elementary 836 Streams' ietf-avt-rtp-mpeg4-dmdraft-ietf-avt-new-00, 837 Internet Engineering Task Force, March 19987. 839 [7] J. Wroclawski "The Use of RSVP with IETF Integrated 840 Services" RFC 2210, September 1998 842 [8] Wroclawski, J., "Specification of the Controlled Load 843 Quality of Service", RFC 2211, September 1998. 845 [9] Shenker, S., Partridge, C., and R Guerin, "Specification 846 of Guaranteed Quality of Service", RFC 2212, September 847 1998. 849 [10]Shenker, S., and J. Wroclawski, "General Characterization 850 Parameters for Integrated Service Network Elements", RFC 2215, 851 September 1998. 853 [11]Braden, B., Ed., et. al., "Resource Reservation Protocol 854 (RSVP) - Version 1 Functional Specification", RFC 2205, 855 September 1998. 857 [12]Balabanian, " The Role of DMIF in Support of RTP MPEG-4 858 Payloads", draft-balabanian-rtp-mpeg4-dmif-01, August 1998. 860 Internet Engineering Task Force Integrated Services Working Group 861 Internet Draft Balabanian-Nortel 862 draft-balabanian-intserv-mpeg4-dmif-00.txt 863 Sept. 19, 1998 864 Expires: March 23, 1999