Internet DRAFT - draft-balabanian-intserv-mpeg4-dmif
draft-balabanian-intserv-mpeg4-dmif
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]
