Internet Engineering Task Force Integrated Services Working Group Internet Draft Balabanian-Nortel draft-balabanian-intserv-mpeg4-dmif-00.txt Sept. 19, 1998 Expires: March 23, 1999 The Use of MPEG-4/DMIF and RSVP with Integrated Services STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. ABSTRACT This draft proposal explains how the ISO/IEC MPEG DMIF (Delivery Multimedia Integration Framework) can be used to carry MPEG-4 streams according to required media specific QoSs using RSVP with Integrated Services. Comments are solicited and should be addressed to the working group's mailing list at int-serv@isi.edu and/or the authors. 1 Introduction MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data in the form of audiovisual objects that are arranged into an audiovisual scene by means of a scene description [1][2][3][4]. This draft proposal specifies how MPEG-4 QoS requirements for flows are mapped into RSVP with IETF Integrated- Services in the instance of ISO/IEC MPEG multimedia delivery integration framework (DMIF). This would allow the use of IP networks as transports for MPEG-4 streams requiring some level of QoS. This draft proposal provides a solution for discussion in IETF IntServ and ISO/IEC MPEG technical communities in order to identify issues in using of MPEG-4/DMIF with RSVP and incorporate the results. Balabanian [Page 1]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 This would lead to the finalization of the specification on how DMIF can be used to carry MPEG-4 streams according to media specific QoSs using RSVP with Integrated Services. The MPEG-4 standards are versioned each beyond V1 contain backward compatible extensions. MPEG-4 V1 is targeted to become ISO International Standard on December 1998 and each subsequent version will be displaced approximately by a year. MPEG-4 V2 is targeted for February 2000. DMIF is part 6 of the MPEG-4 standard. 1.1 The DMIF Model DMIF as an integration framework uses a uniform procedure at the DAI interface to access the MPEG-4 content irrespective whether the content is broadcast, stored on a local file or obtained through interaction with a remote end-system. The model is shown in Figure 1 below. ! +---+ +-----------+ +-----------+ +-----------+ ! | | |Local DMIF | |Remote DMIF| |Remote App.| +-----+ ! | D | |for Brd'cst| |(locally | |(locally | Brd'cst | | ! | M | | | | emulated) | | emulated) |<-----source |Local| ! | I | +-----------+ +-----------+ +-----------+ | | ! | F | +-----------+ +-----------+ +-----------+ |App | ! | | |Local DMIF | |Remote DMIF| |Remote App.| File | | ! | F | |for Local | |(locally | |(locally |<-----source | | ! | i | | Files | | emulated) | | emulated) | | | ! | l | +-----------+ +-----------+ +-----------+ | | ! | t | +-----------+ ! +---+ / ---- \ | | ! | e | |Local DMIF | ! |Sig| | --- ---- | +-----+ ! | r | |for Remote | ! |map|<->( Network ) |Outside the ! | | | Service | ! | | | ---- ----- |scope of DMIF ! +---+ +-----------+ ! +---+ | ----- | DAI DNI | ^ | \_____ |________/ | | +---+!+------+!+------+ | |Sig|!|Remote|!|Remote| +->|map|!| DMIF |!| App. | | |!|(real)|!|(real)| +---+!+------+!+------+ DNI DAI Figure 1: The DMIF model covers broadcast, local file storage and remote service with a uniform procedure for application transparency Balabanian [Page 2]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 The specific instance of interest in this draft proposal is the interaction with a remote end-system. For this case DMIF uses internal (informative) DMIF-Network Interface(DNI)to map the controls obtained from the application through DAI into the various signaling appropriate to the various networks. The default end-to-end DMIF signaling (DS) protocol which corresponds to DNI is specified in DMIF V1 [4]. 1.5.2 Establishing channels using DAI Of interest in this draft proposal is the process by which a channel is established. Figures 2 and 3 below show the flow of signals across the DAI and the RSVP APIs, between a DMIF Receiver and its Sender. a) Precondition for the procedure in Figure 2: The MPEG-4 service has been initiated and the DMIF signaling channel "DS_" between the originating and the target DMIF [4] has been successfully established, after capability exchange. The receiver application is in possession of the Elementary Stream Descriptors [1] from which it selects the streams and obtains the media based QoS. Balabanian [Page 3]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 b) Channel establishment procedure RSVP RSVP API API DMIF | IP | DMIF DAI (Sndr) DNI| Network |DNI (Rcvr) DAI I-----------I +---------------+ I----------I I I | | I I DA_ChannelAdd I 3 I | DS_ChannelAdd | I 2 1 I DA_ChannelAdd <------------0<-----------------------------0<------((ES-Id,dir, ((ES-Id,dir)) I I |((CAT,dir, | I I qos)) I I | ,qos,ES-Id))| I I I I | | I I I I | | I I ((rsp)) I I | | I I 4 ----->I I | | I I I Maps I | | I I I Channels I | | I I I into I | | I I I specific I | | I I I RTP flows I | | I I I I DN_TransMuxSetup| I I I 5 ----------------------------> I I ((resdcrptr,st-qos)) I I I I ((resdcrptr,rsp)) I I I <--------------------------- 6 I I I | | I I I I | Sender_TSpec | I I I 7 int1----------------->I I I I | ADSpec | I I I I------------------>I I I I | 0-0 | I I I I | / \ | I I I I | / \ | I I I I |-0 \ | I I I I | 0-- | I I I I | FlowSpec | I I I 8 I<----------------- int2 I I reduce I | | I I readjust<--- RTP to I | | I I AL-PDU I new MTU I | | I I to new I I | | I I MTU I I | | I I I I | | I I I I | ((rsp)) | I I ((rsp)) I --------------------------->0--------------> I I | 9 | I 10 I I-----------I +---------------+ I----------I Figure 2: Establishment of downstream channels in MPEG-4 using DAI Signaling(For brevity only the relevant parameters are shown) Balabanian [Page 4]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 Step 1: The receiver application passes a DA_ChannelAdd() requesting channels for Elementary Streams ES-Id1 through Es-Idn. Each ES-Id is associated with direction and QoS. Step 2: DMIF generates Channel Association Tag CAT corresponding to each ES-Id and sends the requests to the sender DMIF. Step 3: At the sender DMIF DA_ChannelAdd is passed to the application. Step 4 The sender application may respond positively to each ES-Id request. Step 5: DMIF groups the channels into RTP flows [6][12] based on priority, QoS parameter values and traffic load requested for each channel. The pooling policy is outside the scope of DMIF. After the proper grouping of channels into flows. The stream-QoS (st-qos) is derived (for either a single or aggregate flows, see section 2.3) in order to be able to meet the QoS requirements for the aggregate channels. UDP/IP ports are assigned to the streams at the sender DMIF and a UDP/IP resourceDescriptors (resdcrptr) are sent along with the stream-QoS to the receiver. Step 6: the receiver DMIF completes the local UDP/IP ports for the requested streams in the UDP/IP resourceDescriptors in response to the DN_TransMuxSetup. Step 7: The UDP/IP resourceDescriptors and the stream-QoS descriptors are used to start RSVP PATH (int1) with Sender_Tspec and ADSpec. This is received at the receiver DMIF and RESV message (int2) is generated with the FlowSpec. The process of int1 and int2 is repeated regularly to maintain the soft states in the IP network. Step 8: After receiving the first RESV message a DA_ChannelInf() (new proposed) message is used to update the MTU size for the AL-PDUs of the stream [6]. This allows the conformance of the stream to the Class of Integrated Service requested. This message is repeated at every change of the MTU value received in int2. Step 9: The response to the DS_ChannelAdd is sent after receiving the first RESV message. Balabanian [Page 5]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 Step 10: At the receiver DMIF the response to the DA_ChannelAdd is sent indicate successful establishment of the channels with the requested QoSs. c) Decoder backchannel establishment procedure To be added. d) channel deleted procedures To be added. 2 Media QoS mapping into RSVP with Integrate Services 2.1 Media Based QoS and Traffic Load The following table provides the media QoS specified by the content provider irrespective of the network used for the transport of the media. No QoS values will be available in DMIF V2 The only parameters being specified in V1 are for characterizing the traffic load of the srtream (the last 3 rows in the table below). +=====================+=====================================+ | Media | Meaning of the | | QoS_QualifierTag | ES Media QoS | +=====================+=====================================+ | MAX_DELAY |Maximum delay per AU (microseconds) | | (DMIF V2) |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY |Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min | +---------------------+-------------------------------------+ | Dejitter Buffer | Bytes reserved for the removal of | | (DMIF V2) | transport jitter from the steam | +---------------------+-------------------------------------+ | LOSS_PROB |Probability of loss of any single AU | | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_AU_SIZE |Maximum size of an AU (Bytes) | | (DMIF V1) | | +---------------------+-------------------------------------+ | MAX_AU_RATE |Maximum arrival rate of an AUs | | (DMIF V1) |(AU-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Average size of AUs (Bytes) | | (DMIF V1) | | +---------------------+-------------------------------------+ Balabanian [Page 6]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 2.2 Other media stream qualifiers In addition to the traffic load in DMIF V1 the stream priority is specified: Priority: Indicates a 32 level value for the importance of the stream related to other streams in the session. 2.3 Derivation of the Media QoS for the RTP-PDU stream The Sync Layer in MPEG-4 fragments the Access Units into SL-PDUs and adds synchronization information [1]. The AL-PDUs in turn can be mapped to RTP-PDUs as follows [6]: RTP-PDU 1:1 SL-PDU RTP-PDU 1:N SL-PDU Balabanian [Page 7]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 2.3.1 The case RTP-PDU 1:1 SL-PDU The table below shows the stream QoS for the case when a single ES is mapped into the RTP PDU. Only the traffic load parameters(the last 3 rows in the table below) are specified in DMIF V1 targeted to be an ISO/IEC International Standard in December 1998. +=====================+=====================================+ | RTP Stream | Derivation from the | | QoS_QualifierTag | ES Media transport-QoS | +=====================+=====================================+ | MAX_DELAY of RTP PDU|Maximum delay per AU (microseconds) | | (DMIF V2) |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY of RTP PDU|Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min | +---------------------+-------------------------------------+ | Dejitter Buffer | Adjusted for the overhead of the | | for the RTP stream | RTP PDU | | (DMIF V2) | | +---------------------+-------------------------------------+ | LOSS_PROB of RTP PDU|Probability of loss of any single AU | | (DMIF V2) |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_RTP_SIZE |Maximum size of an AU (Bytes) | | (DMIF V1) |Plus AL-PDU and RTP overhead | +---------------------+-------------------------------------+ | MAX_RTP_RATE |Maximum arrival rate of AUs | | (DMIF V1) |(RTP-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Average size of AUs (Bytes) | | (DMIF V1) |Plus AL-PDU and RTP overhead | +---------------------+-------------------------------------+ Balabanian [Page 8]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 2.3.2 The case RTP-PDU 1:N SL-PDU The table below shows the stream QoS for the case when multiple ES are aggregated into the RTP PDU. Only the traffic load parameters (the last 3 rows in the table below) are specified in DMIF V1 targeted to be an ISO/IEC International Standard in December 1998. +=====================+=====================================+ | RTP Stream | Derivation from the | | QoS_QualifierTag | ES Media QoS | +=====================+=====================================+ | MAX_DELAY of RTP PDU|Least Maximum delay per AU from | | (DMIF V2) |among the N AL-PDUs(microseconds) | | |measured over 1 sec. | +---------------------+-------------------------------------+ | AVG_DELAY of RTP PDU|Average delay per AU allowed | | (DMIF V2) |(microseconds) measured over 1 min. | +---------------------+-------------------------------------+ | Dejitter Buffer | Total of dejitter buffers adjusted | | for the RTP stream | for the overhead of the RTP PDU | | (DMIF V2) | | +---------------------+-------------------------------------+ | LOSS_PROB of RTP PDU|Least Probability of loss of any | | (DMIF V2) |single AU from the N AL-PDUs | | |(Fraction (0.00 - 1.00) over 1 sec. | +===========================================================+ | MAX_RTP_SIZE |Sum of the MAX_AU_SIZEs of from | | (DMIF V1) |each of the N AL-PDUs Plus AL-PDU | | |and RTP overhead | +---------------------+-------------------------------------+ | MAX_RTP_RATE |Highest MAX_AU_RATE of AUs from each | | (DMIF V1) |of the N AL-PDUs (RTP-PDU/second) | +---------------------+-------------------------------------+ | AVG_RTP_SIZE |Sum of Average size of AUs from | | (DMIF V1) |each of the N AL-PDUs Plus | | |AL-PDU and RTP overhead (Bytes) | +---------------------+-------------------------------------+ Note all the MPEG-4 streams chosen for aggregation over an RTP stream belong to the same stream priority level identified by the Sync Layer. 2.4 Choice of Integrated Service QoS service Each elementary Stream is assigned one of the 32 levels of stream priority [1]. "streamPriority - indicates a relative measure for the priority of this Elementary Stream. An Elementary Stream with a higher streamPriority is more important than one with a lower streamPriority. The absolute values of streamPriority are not normatively defined."[1] Balabanian [Page 9]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 "streamPriority: Provides the priority of the channel. Lower values mean lower priority." [4] These priorities relate to the streams within one MPEG-4 session. On top of these priorities one can superimpose the network priority classes. These relate each individual stream to other streams on the network. It is conceivable and even logical that some mapping algorithms may map higher stream priority values to a higher network priority classs. This policy matter is outside the scope of DMIF. The integrated service classes are described below: Best Effort (the IP network default) DMIF may monitor the channel's performance and request controlled- load service from the network only when best-effort service is not providing acceptable performance. This provides flexibility and offers cost savings in environments where levels of service above best-effort incur a charge. The DMIF layer may choose based on a policy to monitor the performance parameters as defined in [12] in order to take corrective action and notify the user of the necessity for a corrective action. Controlled-Load Service[8] Tightly approximates the behavior visible to applications receiving best-effort service *under unloaded conditions* from the same series of network elements. The controlled-load service is best suited to those applications which can usefully characterize their traffic requirements, this includes the "continuous media" data, such as digitized audio or video. This service is not isochronous and does not provide any explicit information about transmission delay. MPEG-4 with end-to-end timing mechanism can use it similar to the best-effort service. Guaranteed Quality of Service[9] Assures level of bandwidth that, when used by a policed flow, produces a delay-bounded service with no queuing loss for all conforming datagrams. Balabanian [Page 10]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 The choice of any one of the above classes could be made as follows: 1- If MAX_DELAY for the RTP PDU is specified then the attempt is made to use a Guaranteed Quality Service. 2- If LOSS_PROB of RTP PDU is specified then the Controlled-Load Service is attempted. 3- If MAX_DELAY is not specified and LOSS_PROB is not specified then use the Best Effort Only experience will dictate the best formula for mapping and could be a differentiating factor between commercial mapping algorithm softwares. 2.5 Building the Sender_TSpec The Sender_TSpec specifies the load which is used to ensure adequate resources are present at network elements in case of Controlled-Load and Guaranteed Services. The Sender_TSpec parameters and their derivation from the RTP Media QoS follows: -- The token bucket has a bucket depth, b b could be approximated as follows: b >= T*MAX_RTP_RATE(MAX_RTP_SIZE - AVG_RTP_SIZE) Where T is the time period. [Author's note: How is the value of T obtained?] [Author's note: DMIF is considering the use of T*(MAX_RTP_BITRATE- AVG_RTP_BITRATE)/8] -- Bucket rate, r r could be approximated as follows: r = MAX_RTP_RATE*AVG_RTP_SIZE [Author's note: A better measure is required for this such as AVG_RTP-BITRATE. This matter is under consideration in DMIF)] -- The peak rate, p The peak rate is the maximum rate at which the source may inject bursts of traffic into the network. p MUST be greater than or equal to the token bucket rate, r. If the peak rate is unknown or unspecified, then p MUST be set to infinity. p could be approximated as follows: p = MAX_RTP_RATE*MAX_RTP_SIZE [Author's note: A better measure is required for this such as MAX_RTP-BITRATE. This matter is under consideration in DMIF] Balabanian [Page 11]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 -- The minimum policed unit, m Document [4] does not specify MIN_AU_SIZE. If a parameter is designated it can be used to derive the MIN_RTP_SIZE as follows: Case of RTP-PDU 1:1 AL-PDU MIN_RTP_SIZE = MIN_AU_SIZE Plus AL-PDU and RTP overhead Case of RTP-PDU 1:N AL-PDU MIN_RTP_SIZE = Sum of the MIN_AU_SIZEs from each of the N AL-PDUs Plus AL-PDU and RTP overhead m = MIN_RTP_SIZE IP datagram size [Author's note: How critical is the specification of a minimum datagram size? Will it result in discarding the datagram if a larger m is used in calculating the violation of the rT+b bound, see 2.6.1?] -- The maximum datagram size, M M = MAX_RTP_SIZE IP datagram size 2.6 Forming the Receiver FlowSpec Two cases are covered below, one for the controlled load service and the other for the guaranteed service. 2.6.1 FLOWSPEC object when requesting Controlled-Load service In this case the flow object contains the TSpec to which the network shall respond in providing the QoS. In MPEG-4/DMIF the sender makes available to a receiver a set of Elementary Stream descriptors from which the receiver chooses based on its capability to decode the stream when received. Since this is done before the PATH message is received, the Sender TSpec in the PATH therefore already reflects the receiver's choice. As a result the corresponding parameter values may be copied into the FLOWSPEC except for the M parameter which is replaced by the PATH-MTU from the ADSpec in the PATH message. The TSpec contains the following parameters. -- The token bucket has a bucket depth, b This value is kept the same as the one received in the SENDER_TSPEC passed across the RSVP API Balabanian [Page 12]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 -- Bucket rate, r This value is kept the same as the one received in the SENDER_TSPEC passed across the RSVP API -- The peak rate, p This parameter may always be ignored by a Controlled-Load service -- The minimum policed unit, m This value is kept the same as the one received in the Sender TSpec -- The maximum datagram size, M The maximum packet size parameter [M] should be set to the value of the smallest path MTU, which the receiver learns from information in arriving RSVP ADSPEC objects (from different senders in case of incasting not presently covered in [1]& [4]). Alternatively, if the receiving application has built-in knowledge of the maximum packet size in use within the RSVP session, and this value is smaller than the smallest path MTU, [M] may be set to this value. Note that requesting a value of [M] larger than the service modules along the data path can support will cause the reservation to fail.[7] The TSpec's token bucket parameters require that traffic must obey the rule that over all time periods, the amount of data sent does not exceed rT+b, where r and b are the token bucket parameters and T is the length of the time period. For the purposes of this accounting, links must count packets that are smaller than the minimal policing unit m to be of size m. Packets that arrive at an element and cause a violation of the the rT+b bound are considered nonconformant. A measure that is required in MPEG-4/DMIF for the acceptance of the path in a controlled service is a value representing LOSS_PROB. These are not presently covered in [8]. They therefore need to be monitored [12] along with the MAX_DELAY and the AVG_DELAY as well as the Jitter using a mechanism such as RTCP Reports. 2.6.2 FLOWSPEC Object when Requesting Guaranteed Service In this case the FLOWSPEC object contains the Rspec in addition to the TSpec to which the network shall respond in providing the QoS. In MPEG-4/DMIF the sender makes available to a receiver a set of Elementary Stream descriptors from which the receiver chooses based on its capability for decoding the stream when received. Since this is done before the PATH message is received, the Sender TSpec in the PATH therefore already reflects the receiver's choice. As a result the corresponding parameter values may be copied Balabanian [Page 13]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 into the FLOWSPEC except for the M parameter which is replaced by the PATH-MTU from the ADSpec in the PATH message. The TSpec contains the following parameters. -- The token bucket has a bucket depth, b This value is kept the same as the one received in the SENDER_TSPEC passed across the RSVP API -- Bucket rate, r This value is kept the same as the one received in the SENDER_TSPEC passed across the RSVP API -- The peak rate, p This parameter is used to optimize the buffer resources in the network. -- The minimum policed unit, m This value is kept the same as the one received in the Sender TSpec -- The maximum datagram size, M The maximum packet size parameter [M] should be set to the value of the smallest path MTU, which the receiver learns from information in arriving RSVP ADSPEC objects (from different senders in case of incasting not presently covered in the [1]& [4]). Alternatively, if the receiving application has built-in knowledge of the maximum packet size in use within the RSVP session, and this value is smaller than the smallest path MTU, [M] may be set to this value. Note that requesting a value of [M] larger than the service modules along the data path can support will cause the reservation to fail.[7] The network is not permitted to fragment datagrams as part of guaranteed service. Datagrams larger than the MTU of a link are policed as nonconformant which means that they will be policed according to the Policing rules. The network applies the rule that over all time periods, the amount of data sent cannot exceed M+min[pT, rT+b-M], where r and b are the token bucket parameters, M is the maximum datagram size, and T is the length of the time period and p is the peak rate (note that when p is infinite this reduces to the standard token bucket requirement). For the purposes of this accounting, datagrams which are smaller than the minimum policing unit are counted to be as size m. Datagrams which arrive at an element and cause a violation of the the M+min[pT, rT+b-M] bound are considered nonconformant. Balabanian [Page 14]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 Nonconforming datagrams are treated as best-effort datagrams or dropped. All flow controls that are normally applied to best effort datagrams are applied to that datagram too. Datagrams bigger than the MTU of a network element are considered nonconformant and classified as best effort (and will then either be fragmented or dropped according to the element's handling of best effort traffic). The RSpec contains the following values. -- Rate value, R The R value is calculated to meet the value of the AVG_DELAY of the RTP PDU from the stream-QoS (for a single flow or aggregate of flows) using the formula in section 2.6.2.1. -- Slack value, S In order to derive the Slack in the RSpec the MAX_DELAY of the RTP PDU is used from the stream-QoS. (for a single flow or aggregate of flows). Guaranteed service does not control the minimal or average delay of datagrams, merely the maximal queuing delay. Furthermore, to compute the maximum delay a datagram will experience, the latency of the path MUST be determined and added to the guaranteed queuing delay. (However, a conservative bound of the latency can be computed by observing the delay (Minimum path latency in the ADSpec) experienced by any one packet).[9] The MAX_DELAY is reduced by the latency of the path and the resulting value is termed the required Delay Dreq. 2.6.2.1 Calculating the delays and the slack The steps below show the end-to-end queuing derivation and subsequently the derivation of the Slack. The maximum end-to-end queuing delay (as characterized by Ctot and Dtot) and bandwidth (characterized by R) provided along a path will be stable. That is, they will not change as long as the end-to-end path does not change.[9] Consider an application that is intolerant of any lost or late datagrams. It uses the advertised values Ctot and Dtot and the TSpec of the flow, to compute the resulting delay bound from a service request with rate R. The end-to-end delay bound is [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and (M+Ctot)/R+Dtot for r<=p<=R [9] Balabanian [Page 15]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 While sending applications are encouraged to set the peak rate parameter, it is always acceptable to ignore the peak rate for the purposes of computing end-to-end delays. The result is simply an overestimate of the delay. The end-to-end delay without the peak rate is b/R+Ctot/R+Dtot.[9] As an example [9] for the use of the slack term, consider the case where the required end-to-end delay MAX_DELAY is larger than the maximum delay of the fluid flow system. The latter is obtained by setting R=r in the fluid delay formula (for stability, R>=r must be true), and is given by b/r + Ctot/r + Dtot. In this case the slack term is S = MAX_DELAY - (b/r + Ctot/r + Dtot). If S<0 then the path is refused by the receiver. Otherwise the value is included in the S field of the RSpec. Also if the Minimum path latency from the Sender ADSpec is more than AVG_DELAY the receiver shall refuse the path. However DMIF needs to monitor the performance for AVG_DELAY and take the proper measure when the value is larger than required by the Application. A measure that is required in MPEG-4/DMIF for the acceptance of the path in a controlled service is some value representing LOSS_PROB. These are not presently covered in [8]. They therefore need to be monitored along with the Jitter using a mechanism such as RTCP [12]. Guaranteed service is invoked by specifying the traffic (TSpec) and the desired service (RSpec) to the network. A service request for an existing flow that has a new TSpec and/or RSpec is treated as a new invocation, in the sense that admission control is reapplied to the flow. Flows that reduce their TSpec and/or their RSpec (i.e., their new TSpec/RSpec is strictly smaller than the old TSpec/RSpec according to the ordering rules described in [9]) are not denied service. 2.7 Reacting to the FlowSpec in the network and at the Sender [7] When a receiver originates a reservation request, it can also request a confirmation message to indicate that its request was (probably) installed in the network. In order to reduce the traffic however the confirmation may be requested in every n RESV messages, where the value of n is network dependent. The RSVP processes in the network pass the FlowSpec reservation request to admission control and policy control. If either test fails, the reservation is rejected and the RSVP process returns an error message to the receiver. If both succeed, the desired Balabanian [Page 16]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 QoS is defined by FlowSpec passed to the sender[11]. MPEG-4/DMIF version 1 [1][4] do not use multicast. Therefore it is assumed in this draft proposal that the value of the TSpec remains unchanged from that sent by the receiver and no multicast or heterogeneous source branch points are used in MPEG-4/DMIF version 1. However this is a subject under consideration in DMIF Version 2 or later. In the case of MPEG-4/DMIF Version 1 [1][4], the values in the TSpec received from the Receiver is the same as the Sender_Tspec in all aspects except for the M value. This is set to the smallest acceptable MTU of the data path from that sender to the session receiver. This MTU should be used by the sending application to size its packets. Any packets larger than this MTU may be delivered as best-effort rather than being covered by the session's resource reservation. The network creates an RSVP soft state which must be periodically refreshed by PATH and RESV messages. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval. State may also be deleted by an explicit "teardown" message. At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward PATH and RESV refresh messages to succeeding hops. RSVP "teardown" messages remove path or reservation state immediately. Although it is not necessary to explicitly tear down an old reservation, it is recommended that all end hosts send a teardown request as soon as an application finishes[11]. There are two types of RSVP teardown message, PathTear and ResvTear. A PathTear travels towards the receiver and ResvTear travels toward the sender. A teardown request may be initiated either by an application in an end system (sender or receiver), or a network element as the result of state timeout or service preemption. There are two RSVP error messages, PathErr and ResvErr: PathErr messages are very simple; they report errors in processing Path messages and are simply sent upstream to the sender that created the error. There are only a few possible causes of path errors. ResvErr (reservation error) messages report errors in processing Resv messages, or they may report the spontaneous disruption of a reservation, e.g., by administrative preemption. There are a number of ways for a syntactically valid reservation request to fail at some node along the path. Balabanian [Page 17]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 2.8 Open Issues 1) In DMIF [4], no primitive exists to indicate the desired MTU size of the AL_PDU. This is important for operation with RSVP in order to be conformant to the M sent back in the FlowSpec of the RESV message. The Sync Layer must use this information to fragment the AU before they are sent across the DA_Data of the DAI. the proposal is to include DA_ChannelInf(). 2) During the lifetime of the flow it is conceivable because of changes in conditions within the network the MTU message gets changed. In this case the RESV message will indicate a new value for M. In the specific case if the M is lower than the present value it shall require that the Sync Layer be informed. For this reason an DA_CahnnelInf() message may be required to be added to DMIF [4]. 3) The Media QoS needs to include a MIN-AU-SIZE parameter which shall be used to generate the MIN-RTP-SIZE parameter for the RTP stream. This will be used to derive m which is the minimum policed datagram size. However in case it is missing a policy may use a fraction of the AVG_RTP_SIZE to derive m. 4) Require to verify and improve on the mapping of the media based QoS into Integrated Service parameters including suggestions on alternate media based QoS parameters. A Authors' Addresses Vahe Balabanian Nortel P.O.Box 3511, St. C Ottawa, Ontario Canada K1Y 4H7 Tel: 613-763-4721 Email: balabani@nortel.ca B Bibliography [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" May 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" May 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" May 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ Balabanian [Page 18]
Internet Draft MPEG-4 DMIF IntServ RSVP Sept. 19, 1998 [4] ISO/IEC 14496-6 CD "DMIF" May 1998, obtained from the MPEG Home Page http://drogo.cselt.it/mpeg/ [5] Schulzrinne, Casner, Frederick, Jacobson "RTP: A Transport Protocol for Real Time Applications" draft-ietf-avt-new-00, Internet Engineering Task Force, Dec. 1998. [6] Carsten, Balabanian, Basso, Civanlar, hoffman, Speer, Schulzrinne, 'RTP payload format for MPEG-4 Elementary Streams' ietf-avt-rtp-mpeg4-dmdraft-ietf-avt-new-00, Internet Engineering Task Force, March 19987. [7] J. Wroclawski "The Use of RSVP with IETF Integrated Services" RFC 2210, September 1998 [8] Wroclawski, J., "Specification of the Controlled Load Quality of Service", RFC 2211, September 1998. [9] Shenker, S., Partridge, C., and R Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1998. [10]Shenker, S., and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1998. [11]Braden, B., Ed., et. al., "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1998. [12]Balabanian, " The Role of DMIF in Support of RTP MPEG-4 Payloads", draft-balabanian-rtp-mpeg4-dmif-01, August 1998. Internet Engineering Task Force Integrated Services Working Group Internet Draft Balabanian-Nortel draft-balabanian-intserv-mpeg4-dmif-00.txt Sept. 19, 1998 Expires: March 23, 1999 Balabanian [Page 19]