draft-ietf-mmusic-sdp-bwparam-05.txt   draft-ietf-mmusic-sdp-bwparam-06.txt 
Network Working Group Magnus Westerlund Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Category: Standards Track October 20, 2003 Expires: October 2004 April 14, 2004
Expires: April 2004
A Transport Independent Bandwidth Modifier for the Session A Transport Independent Bandwidth Modifier for the Session
Description Protocol (SDP). Description Protocol (SDP).
<draft-ietf-mmusic-sdp-bwparam-05.txt> <draft-ietf-mmusic-sdp-bwparam-06.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I (we) certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am (we are) aware have been
disclosed, and any of which I (we) become aware will be disclosed, in
accordance with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I (we) accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress". material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments This document is a submission of the IETF MMUSIC WG. Comments should
should be directed to the authors. be directed to the MMUSIC WG mailing list, mmusic@ietf.org.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The existing Session Description Protocol (SDP) bandwidth modifiers The existing Session Description Protocol (SDP) bandwidth modifiers
and their values include the bandwidth needed also for the transport and their values include the bandwidth needed also for the transport
and IP layers. When using SDP with protocols like the Session and IP layers. When using SDP with protocols like the Session
Announcement Protocol (SAP), the Session Initiation Protocol (SIP) Announcement Protocol (SAP), the Session Initiation Protocol (SIP)
and the Real-Time Streaming Protocol (RTSP) and when the involved and the Real-Time Streaming Protocol (RTSP) and when the involved
hosts reside in networks running different IP versions, the hosts has different transport overhead, for example due to different
interpretation of what lower layer bandwidths are included is not IP versions, the interpretation of what lower layer bandwidths are
clear. This document defines an SDP bandwidth modifier (TIAS) that included is not clear. This document defines an SDP bandwidth
does not include transport overhead; instead an additional packet modifier (TIAS) that does not include transport overhead; instead an
rate attribute is defined. The transport independent bit-rate value additional packet rate attribute is defined. The transport
together with the maximum packet rate can then be used to calculate independent bit-rate value together with the maximum packet rate can
the real bit-rate over the transport actually used. then be used to calculate the real bit-rate over the transport
actually used.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Definitions.........................................................3 1. Definitions.........................................................4
1.1. Glossary.......................................................3 1.1. Glossary.......................................................4
1.2. Terminology....................................................3 1.2. Terminology....................................................4
2. Introduction........................................................3 2. Introduction........................................................4
2.1. The Bandwidth Attribute........................................3 2.1. The Bandwidth Attribute........................................4
2.1.1. Conference Total..........................................4 2.1.1. Conference Total..........................................5
2.1.2. Application Specific Maximum..............................4 2.1.2. Application Specific Maximum..............................5
2.1.3. RTCP Report bandwidth.....................................4 2.1.3. RTCP Report bandwidth.....................................5
2.2. IPv6 and IPv4..................................................4 2.2. IPv6 and IPv4..................................................5
3. The Bandwidth Signaling Problems....................................5 2.3. Further Mechanisms that change the bandwidth utilization.......6
3.1. What IP version is used........................................5 2.3.1. IPSec.....................................................6
3.2. Converting bandwidth values....................................6 2.3.2. Header Compression........................................7
3.3. Header Compression.............................................7 3. The Bandwidth Signaling Problems....................................7
3.4. RTCP problems..................................................7 3.1. What IP version is used........................................7
3.5. Future development.............................................8 3.2. Taking other mechanisms into account...........................8
4. Problem Scope.......................................................8 3.3. Converting bandwidth values....................................9
5. Requirements........................................................8 3.4. RTCP problems..................................................9
6. Solution............................................................9 3.5. Future development............................................10
6.1. Introduction...................................................9 3.6. Problem Conclusion............................................10
6.2. The TIAS bandwidth modifier....................................9 4. Problem Scope......................................................11
6.2.1. Usage.....................................................9 5. Requirements.......................................................11
6.2.2. Definition...............................................10 6. Solution...........................................................11
6.2.3. Usage Rules..............................................11 6.1. Introduction..................................................11
6.3. Packet Rate parameter.........................................11 6.2. The TIAS bandwidth modifier...................................12
6.4. Converting to Transport-Dependent values......................12 6.2.1. Usage....................................................12
6.5. Deriving RTCP bandwidth.......................................13 6.2.2. Definition...............................................13
6.5.1. Motivation for this solution.............................13 6.2.3. Usage Rules..............................................13
6.6. ABNF definitions..............................................13 6.3. Packet Rate parameter.........................................14
6.7. Example.......................................................14 6.4. Converting to Transport-Dependent values......................15
7. Protocol Interaction...............................................15 6.5. Deriving RTCP bandwidth.......................................15
7.1. RTSP..........................................................15 6.5.1. Motivation for this solution.............................16
7.2. SIP...........................................................15 6.6. ABNF definitions..............................................16
7.3. SAP...........................................................15 6.7. Example.......................................................17
8. Security Consideration.............................................15 7. Protocol Interaction...............................................17
9. IANA Considerations................................................16 7.1. RTSP..........................................................17
10. Acknowledgments...................................................16 7.2. SIP...........................................................18
11. Author's Addresses................................................16 7.3. SAP...........................................................18
12. References........................................................17 8. Security Consideration.............................................18
12.1. Normative references.........................................17 9. IANA Considerations................................................19
12.2. Informative References.......................................17 10. Acknowledgments...................................................19
13. IPR Notice........................................................19 11. Author's Addresses................................................19
14. Copyright Notice..................................................19 12. References........................................................19
12.1. Normative references.........................................19
12.2. Informative References.......................................19
1. Definitions 1. Definitions
1.1. Glossary 1.1. Glossary
ALG - Application Level Gateway. ALG - Application Level Gateway.
bps - bits per second. bps - bits per second.
RTSP - Real-Time Streaming Protocol, see [8]. RTSP - Real-Time Streaming Protocol, see [8].
SDP - Session Description Protocol, see [1]. SDP - Session Description Protocol, see [1].
SAP - Session Announcement Protocol, see [5]. SAP - Session Announcement Protocol, see [5].
skipping to change at page 3, line 27 skipping to change at page 4, line 27
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. Introduction 2. Introduction
This specification is structured in the following way: In this This specification is structured in the following way: In this
section (2) some information regarding SDP bandwidth modifiers and IP section (2) some information regarding SDP bandwidth modifiers, and
versions are asserted. In section 3 the problems found are described, different mechanisms that affect transport overhead are asserted. In
including problems that are not solved by this specification. In section 3 the problems found are described, including problems that
section 4 the scope of the problems this specification solves is are not solved by this specification. In section 4 the scope of the
presented. Section 5 contains the requirements applicable to the problems this specification solves is presented. Section 5 contains
problem scope. Section 6 defines the solution, which is a new the requirements applicable to the problem scope. Section 6 defines
bandwidth modifier, and a new maximum packet rate attribute. Section the solution, which is a new bandwidth modifier, and a new maximum
7 looks at the protocol interaction for SIP, RTSP, and SAP. The packet rate attribute. Section 7 looks at the protocol interaction
security considerations are discussed in section 8. The remaining for SIP, RTSP, and SAP. The security considerations are discussed in
sections are the necessary IANA consideration, acknowledgements, section 8. The remaining sections are the necessary IANA
author's address, reference list, and copyright and IPR notices. consideration, acknowledgements, author's address, reference list,
and copyright and IPR notices.
Today the Session Description Protocol (SDP) [1] is used in several Today the Session Description Protocol (SDP) [1] is used in several
types of applications. The original application is session types of applications. The original application is session
information and configuration for multicast sessions announced with information and configuration for multicast sessions announced with
Session Announcement Protocol (SAP) [5]. SDP is also a vital Session Announcement Protocol (SAP) [5]. SDP is also a vital
component in media negotiation for the Session Initiation Protocol component in media negotiation for the Session Initiation Protocol
(SIP) [6] by using the offer answer model [7]. The Real-Time (SIP) [6] by using the offer answer model [7]. The Real-Time
Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the
client what media and codec(s) comprise a multi-media presentation. client what media and codec(s) comprise a multi-media presentation.
skipping to change at page 4, line 34 skipping to change at page 5, line 40
2.1.3. RTCP Report bandwidth 2.1.3. RTCP Report bandwidth
In RFC 3556 [9], two bandwidth modifiers are defined. These In RFC 3556 [9], two bandwidth modifiers are defined. These
modifiers, "RS" and "RR", define the amount of bandwidth that is modifiers, "RS" and "RR", define the amount of bandwidth that is
assigned for RTCP reports by active data senders and RTCP reports by assigned for RTCP reports by active data senders and RTCP reports by
other participants (receivers), respectively. other participants (receivers), respectively.
2.2. IPv6 and IPv4 2.2. IPv6 and IPv4
Today there are two IP versions 4 [15] and 6 [14] used in parallel on Today there are two IP versions 4 [14] and 6 [13] used in parallel on
the Internet. This creates problems and there exist a number of the Internet. This creates problems and there exist a number of
possible transition mechanisms. possible transition mechanisms.
- The nodes which wish to communicate must share the IP version;
typically this is done by deploying dual-stack nodes. For
example, an IPv4 only host cannot communicate with an IPv6 only
host.
- If communication between nodes which do not share a protocol
version is required, using a translation or proxying mechanism
would be required. Work is underway to specify one for this
purpose.
------------------ ---------------------- ------------------ ----------------------
| IPv4 domain | | IPv6 Domain | | IPv4 domain | | IPv6 Domain |
| | ---------| | | | | ------------- | |
| ---------- |-| NAT-PT |-| ---------- | | ---------- |-|Translator |-| ---------- |
| |Server A| | ---------| | |Client B| | | |Server A| | | or proxy | | |Client B| |
| ---------- | | ---------- | | ---------- | ------------- | ---------- |
------------------ ---------------------- ------------------ ----------------------
Figure 1. Translation between IPv6 and IPv4 addresses. Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
- To achieve connectivity between an IPv4 only host and an IPv6
only host, translation is necessary. This translator can be, for
example, Network Address Translation - Protocol Translation (NAT-
PT) [13], see Figure 1. However, to get connectivity for large
number of protocols, Application Level Gateway (ALG) functionality
is also required at the node. To be able to locate hosts through
the translation node DNS ALG must be supported.
- IPv6 nodes belonging to different domains running IPv6, but - IPv6 nodes belonging to different domains running IPv6, but
lacking IPv6 connectivity between them, solve this by tunneling lacking IPv6 connectivity between them, solve this by tunneling
over the IPv4 net, see Figure 2. Basically the IPv6 packets are over the IPv4 net, see Figure 2. Basically the IPv6 packets are
put as payload in IPv4 packets between the tunneling end-points at put as payload in IPv4 packets between the tunneling end-points at
the edge of each IPv6 domain. The bandwidth required over the IPv4 the edge of each IPv6 domain. The bandwidth required over the IPv4
domain will be different from IPv6 domains. However as the domain will be different from IPv6 domains. However as the
tunneling is normally not performed by the application end-point tunneling is normally not performed by the application end-point
this scenario can not usually be taken into consideration. this scenario can not usually be taken into consideration.
skipping to change at page 5, line 32 skipping to change at page 6, line 43
Figure 2. Tunneling through a IPv4 domain Figure 2. Tunneling through a IPv4 domain
IPv4 has a minimum header size of 20 bytes, while the fixed part of IPv4 has a minimum header size of 20 bytes, while the fixed part of
the IPv6 header is 40 bytes. the IPv6 header is 40 bytes.
The difference in header sizes means that the bit-rate required for The difference in header sizes means that the bit-rate required for
the two IP versions is different. The significance of the difference the two IP versions is different. The significance of the difference
depends on the packet rate and payload size of each packet. depends on the packet rate and payload size of each packet.
2.3. Further Mechanisms that change the bandwidth utilization
There exist a number of other mechanisms that also may change the
overhead at layers below media transport. We will here shortly cover
a few of these.
2.3.1. IPSec
IPSec [19] can be used between end points to provide confidentiality
through the application of the IP Encapsulating Security Payload
(ESP) [21] or integrity protection using IP Authentication Header
(AH) [20] of the media stream. The addition of the ESP and AH headers
increases each packet's size.
To provide virtual private networks, complete IP packets may be
encapsulated between an end node and the private networks security
gateway. Thus providing a secure tunnel that ensures confidentiality,
integrity, and authentication of the packet stream. The extra IP and
ESP header will in this case significantly increase the packet size.
2.3.2. Header Compression
Another mechanism that alters the actual overhead over links is
header compression. Header compression uses the fact that most
network protocol headers have either static or predictable values in
their fields within a packet stream. Compression is normally only
done on per hop basis, i.e. on a single link. The normal reason for
doing header compression is that the link has fairly limited
bandwidth and significant gain in throughput is achieved.
There exist several different header compression standards. For
compressing IP headers only, there is RFC 2507 [10]. For compressing
packets with IP/UDP/RTP headers, CRTP [11] was created at the same
time. More recently the Robust Header Compression (ROHC) working
group has been developing a framework and profiles [12] for
compressing certain combinations of protocols, like IP/UDP, and
IP/UDP/RTP.
3. The Bandwidth Signaling Problems 3. The Bandwidth Signaling Problems
When an application wants to use SDP to signal the bandwidth required When an application wants to use SDP to signal the bandwidth required
for this application, some problems become evident due to the for this application, some problems become evident due to the
dependency on the lower protocol layers. inclusion of the lower layers in the bandwidth values.
3.1. What IP version is used 3.1. What IP version is used
If one signals the bandwidth in SDP, with for example "b=AS:" for an If one signals the bandwidth in SDP, with for example "b=AS:" for an
RTP based application, one cannot know if the overhead is calculated RTP based application, one cannot know if the overhead is calculated
for IPv4 or IPv6. An indication of which protocol has been used when for IPv4 or IPv6. An indication of which protocol has been used when
calculating the bandwidth values is given by the "c=" connection calculating the bandwidth values is given by the "c=" connection
address line. This line contains either a multicast group address or address line. This line contains either a multicast group address or
a unicast address of the data source or sink. The "c=" line's address a unicast address of the data source or sink. The "c=" line's address
type may be assumed to be of the same type as the one used in the type may be assumed to be of the same type as the one used in the
bandwidth calculation, although there seems to exist no specification bandwidth calculation, although there seems to exist no specification
pointing this out. pointing this out.
In cases of SDP transported by RTSP this is even less clear. The In cases of SDP transported by RTSP this is even less clear. The
normal usage for a unicast on-demand streaming session is to set the normal usage for a unicast on-demand streaming session is to set the
connection data address to a null address. This null address does connection data address to a null address. This null address does
have an address type, which could be used as an indication. However, have an address type, which could be used as an indication. However,
this is also not clarified anywhere. this is also not clarified anywhere.
Figure 1, illustrates a connection scenario between a streaming Figure 1, illustrates a connection scenario between a streaming
server A and a client B over a translator here designated as a NAT- server A and a client B over a translator. When B receives the SDP
PT. When B receives the SDP from A over RTSP it will be very from A over RTSP it will be very difficult for B to know what the
difficult for B to know what the bandwidth values in the SDP bandwidth values in the SDP represent. The following possibilities
represent. The following possibilities exist: exist:
1. The SDP is unchanged and "c=" null address is of type IPv4. The 1. The SDP is unchanged and "c=" null address is of type IPv4. The
bandwidth value represents the bandwidth needed in an IPv4 bandwidth value represents the bandwidth needed in an IPv4
network. network.
2. The SDP has been changed by an Application Level Gateway (ALG). 2. The SDP has been changed by an Application Level Gateway (ALG).
The "c=" address is changed to IPv6 type. The bandwidth value is The "c=" address is changed to IPv6 type. The bandwidth value is
unchanged. unchanged.
3. The SDP is changed and both "c=" address type and bandwidth value 3. The SDP is changed and both "c=" address type and bandwidth value
is converted. Unfortunately, this can seldom be done, see 3.2. is converted. Unfortunately, this can seldom be done, see 3.2.
skipping to change at page 6, line 40 skipping to change at page 8, line 43
overhead. In cases where a client uses this value to determine if its overhead. In cases where a client uses this value to determine if its
end of the network has sufficient resources the client will end of the network has sufficient resources the client will
underestimate the required bit-rate, potentially resulting in bad underestimate the required bit-rate, potentially resulting in bad
application performance. application performance.
In case 3 everything works correctly. However, this case will be very In case 3 everything works correctly. However, this case will be very
rare. If one tries to convert the bandwidth value without further rare. If one tries to convert the bandwidth value without further
information about the packet rate, significant errors may be information about the packet rate, significant errors may be
introduced into the value. introduced into the value.
3.2. Converting bandwidth values 3.2. Taking other mechanisms into account
Section 2.2 and 2.3 lists a number of reasons, like header
compression and tunnels that would change lower layer header sizes.
For these mechanisms there exist different possibilities to take them
into account.
Using IPSec directly between end-points should definitely been known
to the application, thus enabling it to take the extra headers into
account. However the same problem exist with the current SDP
bandwidth modifiers that a receiver is not able to convert these
values taking the IPSec headers into account.
It is less likely that an application would be aware of the existence
of a virtual private network. Thus the generality of the mechanism to
tunnel all traffic, may prevent the application to even consider this
even if it would be possible to convert the values.
When using header compression the actual overhead will be less
deterministic, but in most cases an average overhead can be
determined for a certain application. If a network node knows that
some type of header compression is employed this can taken into
consideration. For RSVP [15] there exists an extension, RFC 3006
[16], that allows the data sender to inform network nodes about the
compressibility of the data flow. To be able to do this with any
accuracy the compression factor and packet rate or size is needed, as
RFC 3006 provides.
3.3. Converting bandwidth values
If one would like to convert a bandwidth value calculated using IPv4 If one would like to convert a bandwidth value calculated using IPv4
overhead to IPv6 overhead, the packet rate is required. The new overhead to IPv6 overhead, the packet rate is required. The new
bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate"
* 20 bytes, where 20 bytes is the usual difference between IPv6 and * 20 bytes, where 20 bytes is the usual difference between IPv6 and
IPv4 headers. The overhead difference may be some other value in IPv4 headers. The overhead difference may be some other value in
cases when IPv4 options [15] or IPv6 extension headers [14] are used. cases when IPv4 options [14] or IPv6 extension headers [13] are used.
As converting requires the packet rate of the stream, this is not As converting requires the packet rate of the stream, this is not
possible in the general case. Many codecs have either multiple possible in the general case. Many codecs have either multiple
possible packet/frame rates or can perform payload format possible packet/frame rates or can perform payload format
aggregation, resulting in many possible rates. Therefore some extra aggregation, resulting in many possible rates. Therefore some extra
information in the SDP will be required. The "a=ptime:" parameter may information in the SDP will be required. The "a=ptime:" parameter may
be a possible candidate. However this parameter is normally only used be a possible candidate. However this parameter is normally only used
for audio codecs. Also its definition [1] is that it is only a for audio codecs. Also its definition [1] is that it is only a
recommendation which the sender may disregard. A better parameter is recommendation which the sender may disregard. A better parameter is
needed. needed.
3.3. Header Compression
Another mechanism that alters the actual overhead over links is
header compression. Header compression uses the fact that most
network protocol headers have either static or predictable values in
their fields within a packet stream. Compression is normally only
done on per hop basis, i.e. on a single link. The normal reason for
doing header compression is that the link has fairly limited
bandwidth and significant gain in throughput is achieved.
There exist several different header compression standards. For
compressing IP headers only, there is RFC 2507 [10]. For compressing
packets with IP/UDP/RTP headers, CRTP [11] was created at the same
time. More recently the Robust Header Compression (ROHC) working
group has been developing a framework and profiles [12] for
compressing certain combinations of protocols, like IP/UDP, and
IP/UDP/RTP.
When using header compression the actual overhead will be less
deterministic, but in most cases an average overhead can be
determined for a certain application. If a network node knows that
some type of header compression is employed this can taken into
consideration. For RSVP [16] there exists an extension, RFC 3006
[17], that allows the data sender to inform network nodes about the
compressibility of the data flow. To be able to do this with any
accuracy the compression factor and packet rate or size is needed, as
RFC 3006 provides.
3.4. RTCP problems 3.4. RTCP problems
When RTCP is used between hosts in IPv4 and IPv6 networks over an When RTCP is used between hosts in IPv4 and IPv6 networks over an
NAT-PT, similar problems exist. The RTCP traffic going from the IPv4 translator, similar problems exist. The RTCP traffic going from the
domain will result in a higher RTCP bit-rate than intended in the IPv4 domain will result in a higher RTCP bit-rate than intended in
IPv6 domain due to the larger headers. This may result in up to 25% the IPv6 domain due to the larger headers. This may result in up to
increase in required bandwidth for the RTCP traffic. The largest 25% increase in required bandwidth for the RTCP traffic. The largest
increase will be for small RTCP packets when the number of IPv4 hosts increase will be for small RTCP packets when the number of IPv4 hosts
is much larger than the number of IPv6 hosts. Fortunately, as RTCP is much larger than the number of IPv6 hosts. Fortunately, as RTCP
has a limited bandwidth compared to RTP it will only result in a has a limited bandwidth compared to RTP it will only result in a
maximum of 1.75% increase of the total session bandwidth when RTCP maximum of 1.75% increase of the total session bandwidth when RTCP
bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily
result in short term effects of the same magnitude, so this increase result in short term effects of the same magnitude, so this increase
may be considered tolerable. The increase in bandwidth will in most may be considered tolerable. The increase in bandwidth will in most
cases be less. cases be less.
At the same time, this results in unfairness in the reporting between At the same time, this results in unfairness in the reporting between
skipping to change at page 8, line 16 skipping to change at page 10, line 23
worth any complex solutions. Therefore only a simple algorithm for worth any complex solutions. Therefore only a simple algorithm for
deriving RTCP bandwidth is defined in this specification. deriving RTCP bandwidth is defined in this specification.
3.5. Future development 3.5. Future development
Today there is work in IETF to design a new datagram transport Today there is work in IETF to design a new datagram transport
protocol suitable for real-time media. This protocol is called the protocol suitable for real-time media. This protocol is called the
Datagram Congestion Control Protocol (DCCP). It will most probably Datagram Congestion Control Protocol (DCCP). It will most probably
have a different header size than UDP, which is the protocol most have a different header size than UDP, which is the protocol most
often used for real-time media today. This results in even more often used for real-time media today. This results in even more
possible transport combinations to calculate overhead for. possible transport combinations. This may become a problem if one has
the possibility to use different protocols, which will not be
determined prior to actual protocol SETUP. Thus pre-calculating this
value will not be possible. Which is one further motivation why a
transport independent bandwidth modifier is needed.
This may become a problem if one has the possibility to use different DCCP's congestion control algorithms will control how much bandwidth
protocols, which will not be determined prior to actual protocol that really can be utilized. This may require further work with
SETUP. Thus pre-calculating this value will not be possible. specifying SDP bandwidth modifiers to declare the dynamic
possibilities of an application's media stream, for example min and
max media bandwidth the application is capable of producing at all,
or for media codecs only capable of producing certain bit-rates,
enumerating possible rates. However this is for future study and
outside the scope of the present solution.
3.6. Problem Conclusion
A shortcoming of the current SDP bandwidth modifiers is that they
include also the bandwidth needed for lower layers. It is in many
cases difficult to determine which lower layers and their versions
that were included in the calculation, especially in the presence of
translation or proxying between different domains. This prevents a
receiver from determining if given bandwidth needs to be converted
based on the actual lower layers being used.
Secondly there exist no attribute to give the receiver an explicit
determination of the maximum packet rate that will be used. This
value is necessary for accurate conversion of any bandwidth values if
the difference in overhead is known.
4. Problem Scope 4. Problem Scope
The problems described in chapter 3 are common and effect application The problems described in chapter 3 are common and effect application
level signaling using SDP, other signaling protocols, and also level signaling using SDP, other signaling protocols, and also
resource reservation protocols. However this document targets the resource reservation protocols. However this document targets the
specific problem of signaling the bit-rate in SDP. The problems need specific problem of signaling the bit-rate in SDP. The problems need
to be considered in other affected protocols and in new protocols to be considered in other affected protocols and in new protocols
being designed. In the MMUSIC WG there is work on a replacement of being designed. In the MMUSIC WG there is work on a replacement of
SDP called SDP-NG. It is recommended that the problems outlined in SDP called SDP-NG. It is recommended that the problems outlined in
this document be considered when designing solutions for specifying this document be considered when designing solutions for specifying
bandwidth in SDP-NG [18]. bandwidth in SDP-NG [17].
As this specification only targets carrying the bit-rate information As this specification only targets carrying the bit-rate information
within SDP it will have a limited applicability. As SDP information within SDP it will have a limited applicability. As SDP information
normally is transported end-to-end by an application protocol, nodes normally is transported end-to-end by an application protocol, nodes
between the end-points will not have access to the bit-rate between the end-points will not have access to the bit-rate
information. It will normally only be the end points that are able to information. It will normally only be the end points that are able to
take this information into account. An interior node will need to take this information into account. An interior node will need to
receive the information through other means than SDP, and that is receive the information through other means than SDP, and that is
outside the scope of this specification. outside the scope of this specification.
skipping to change at page 16, line 8 skipping to change at page 18, line 49
be integrity protected and source authenticated so no tampering can be integrity protected and source authenticated so no tampering can
be performed and the source trusted. It is also RECOMMENDED that any be performed and the source trusted. It is also RECOMMENDED that any
receiver of the SDP perform an analysis of the received bandwidth receiver of the SDP perform an analysis of the received bandwidth
values to verify that they are reasonable and are what can be values to verify that they are reasonable and are what can be
expected for the application. For example, a single channel AMR- expected for the application. For example, a single channel AMR-
encoded voice stream claiming to use 1000 kbps is not reasonable. encoded voice stream claiming to use 1000 kbps is not reasonable.
Please note that some of the above security requirements are in Please note that some of the above security requirements are in
conflict with what is required to make signaling protocols using SDP conflict with what is required to make signaling protocols using SDP
to work through a middlebox as discussed in the security to work through a middlebox as discussed in the security
considerations of RFC 3303 [19]. considerations of RFC 3303 [18].
9. IANA Considerations 9. IANA Considerations
This document registers one new SDP session and media level attribute This document registers one new SDP session and media level attribute
"maxprate", see section 6.3. "maxprate", see section 6.3.
A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered
in accordance with the rules requiring a standards-track RFC. The in accordance with the rules requiring a standards-track RFC. The
modifier is defined in section 6.2. modifier is defined in section 6.2.
skipping to change at page 17, line 38 skipping to change at page 20, line 17
[8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", [8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
IETF RFC 2326, April 1998. IETF RFC 2326, April 1998.
[9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF [9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF
RFC 3556, Internet Engineering Task Force, July 2003. RFC 3556, Internet Engineering Task Force, July 2003.
[10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", [10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression",
IETF RFC 2507, February 1999. IETF RFC 2507, February 1999.
[11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- [11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-
Speed Serial Links", IETF RFC 2508, February 1999. Speed Serial Links", IETF RFC 2508, February 1999.
[12] C. Bormann, et. al., "RObust Header Compression (ROHC): [12] C. Bormann, et. al., "RObust Header Compression (ROHC):
Framework and four profiles", IETF RFC 3095, July 2001. Framework and four profiles", IETF RFC 3095, July 2001.
[13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation - [13] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering
Task Force, February 2000.
[14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, Internet Engineering Task Force, Specification", RFC 2460, Internet Engineering Task Force,
December 1998. December 1998.
[15] J. Postel, "Internet Protocol", RFC 791, Internet Engineering [14] J. Postel, "Internet Protocol", RFC 791, Internet Engineering
Task Force, September 1981. Task Force, September 1981.
[16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [15] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[17] Davie, B., et. al., "Integrated Services in the Presence of [16] Davie, B., et. al., "Integrated Services in the Presence of
Compressible Flows," RFC 3006, Internet Engineering Task Force, Compressible Flows," RFC 3006, Internet Engineering Task Force,
November 2000. November 2000.
[18] Kutscher, Ott, Bormann, "Session Description and Capability [17] Kutscher, Ott, Bormann, "Session Description and Capability
Negotiation," IETF draft, work in progress, march 2003. Negotiation," IETF draft, work in progress, march 2003.
[18] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "
[19] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "
Middlebox communication architecture and framework," RFC 3303, Middlebox communication architecture and framework," RFC 3303,
Internet Engineering Task Force, August 2002. Internet Engineering Task Force, August 2002.
[19] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol.," RFC 2401, Internet Engineering Task Force, November
1998.
[20] S. Kent, R. Atkinson., "IP Authentication Header.," RFC 2402,
Internet Engineering Task Force, November 1998.
[21] S. Kent, R. Atkinson., "IP Encapsulating Security Payload
(ESP).," RFC 2406, November 1998.
13. IPR Notice Copyright Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14. Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and Copyright (C) The Internet Society (2004). This document is subject
furnished to others, and derivative works that comment on or to the rights, licenses and restrictions contained in BCP 78, and
otherwise explain it or assist in its implementation may be except as set forth therein, the authors retain all their rights.
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will Disclaimer of Validity
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided This document and the information contained herein are provided on an
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Changes Changes
[Note to RFC Editor: Remove this section when publishing] [Note to RFC Editor: Remove this section when publishing]
The following changes have been done to this version compared to The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-01.txt: draft-ietf-mmusic-sdp-bwparam-05.txt
- Improved language in the whole draft
- Updated the problem scope section (4) to clarify what part of the
whole problem space that this specification provides solution to.
- Clarified that the tunneling problem example may not be applicable
for the TIAS parameters (Section 2.2).
- Included text about RFC 3006, which provides hints in RSVP that
header compression is possible.
- Removed an inconsistency in the normative language regarding the
usage of "maxprate" attribute. It shall always be present when TIAS
is used.
The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-02.txt
- Updated language in abstract.
- Replaced a reference to RFC 1889 with RFC XXXX.
- Added a SDP-NG informative reference.
- Corrected two language errors in Section 4.
- Fixed reference [15].
The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-03.txt
- Changed the definition of TIAS and maxprate at SDP session level.
It is now allowed to have a session rate less than the sum of the
individual rates.
- Added an example of the usage of the attributes.
- Reformulated some sentences for clarity.
The following changes have been done to this version compared to
draft-ietf-mmusic-sdp-bwparam-04.txt
- Clarified the scope by explicitly noting that detecting NATs was
out of scope.
- Added a paragraph in the introduction presenting the structure of
the document.
- Clarified that the bandwidth parameter and intended use is not end
to end, but rather near end usage.
- Clarified for readability in the solution section directly what
TIAS stands for.
- Added an example of how to derive reasonable worst case overhead
for the CT bandwidth modifier.
- Clarified what is meant with "RTCP sending rate".
- Added a reference to the security considerations of RFC 3303.
- Replaced the preliminary RFC XXXX and RFC YYYY references with the - Removed any explicit naming of a translation mechanism.
real RFC 3550 and 3556 information. - Updated the ID boilerplate in accordance with RFC 3367, and RFC
3668.
- Clarified that there exist further mechanisms that effect the
lower layers, like IPSec.
- Added a problem conclusion section.
This Internet-Draft expires in April 2004. This Internet-Draft expires in October 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/