Skip to main content

A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)
RFC 3890

Revision differences

Document history

Date Rev. By Action
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier …
Received changes through RFC Editor sync (changed abstract to 'This document defines a Session Description Protocol (SDP) Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.

The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. [STANDARDS-TRACK]')
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Bert Wijnen
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2004-09-28
06 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2004-09-28
06 Amy Vezza [Note]: 'RFC 3890' added by Amy Vezza
2004-09-17
06 (System) RFC published
2004-05-06
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-05-06
06 Amy Vezza IESG state changed to Approved-announcement sent
2004-05-06
06 Amy Vezza IESG has approved the document
2004-05-06
06 Amy Vezza Closed "Approve" ballot
2004-05-06
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::Revised ID Needed by Amy Vezza
2004-05-05
06 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen
2004-04-14
06 (System) New version available: draft-ietf-mmusic-sdp-bwparam-06.txt
2004-02-16
06 Jon Peterson State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jon Peterson
2003-12-23
06 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2003-12-23
06 Steven Bellovin
[Ballot comment]
There are many other things that can cause erroneous bandwidth estimates, including various forms of tunneling (GRE, IPsec, 6to4) and link-layer encapsulation -- …
[Ballot comment]
There are many other things that can cause erroneous bandwidth estimates, including various forms of tunneling (GRE, IPsec, 6to4) and link-layer encapsulation -- should those be discussed here?
2003-12-18
06 Amy Vezza Removed from agenda for telechat - 2003-12-18 by Amy Vezza
2003-12-18
06 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2003-12-18
06 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for  by Amy Vezza
2003-12-18
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for  by Russ Housley
2003-12-18
06 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for  by Allison Mankin
2003-12-18
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for  by Bill Fenner
2003-12-18
06 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for  by Thomas Narten
2003-12-18
06 Bert Wijnen
[Ballot discuss]
From OPS Directorate review (Pekka)

one potential issue I see is in the introductory section:

2.2. IPv6 and IPv4
        …
[Ballot discuss]
From OPS Directorate review (Pekka)

one potential issue I see is in the introductory section:

2.2. IPv6 and IPv4
                                                                                                                                     
  Today there are two IP versions 4 [15] and 6 [14] used in parallel on
  the Internet. This creates problems and there exist a number of
  possible transition mechanisms.
                                                                                                                                     
                                                                                                                                     
    ------------------            ----------------------
    | IPv4 domain    |            | IPv6 Domain        |
    |                | ---------| |                    |
    | ----------    |-| NAT-PT |-|      ----------    |
    | |Server A|    | ---------| |      |Client B|    |
    | ----------    |            |      ----------    |
    ------------------            ----------------------
                                                                                                                                     
                                                                                                                                     
    Figure 1. Translation 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.
[...]

==> I do not feel particularly strongly about this, but I'm not sure
if we want to be referring to translation and NAT-PT in a standards
track document like this, at least at this phase .. when it doesn't
seem to be necessary.  Maybe the same result could be obtained by
removing the figure and rewording the bullet point e.g. to:

  -  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 mechanism would be
    required.  Work is underway to specify one for this purpose.
2003-12-18
06 Bert Wijnen [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Undefined by Bert Wijnen
2003-12-18
06 Bert Wijnen [Ballot Position Update] New position, Undefined, has been recorded for  by Bert Wijnen
2003-12-18
06 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for  by Alex Zinin
2003-12-17
06 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for  by Margaret Wasserman
2003-12-16
06 Ted Hardie
[Ballot comment]
I found section 3.5 on the potential interaction with DCCP somewhat lacking.  It's clear that using
DCCP for real time media will be …
[Ballot comment]
I found section 3.5 on the potential interaction with DCCP somewhat lacking.  It's clear that using
DCCP for real time media will be different in a number of ways from the current flows over UDP,
and while it is good that the draft notes the likely difference in header size, it hardly seems
like the most important thing to note.  The use of different congestion control algorithms
seems far more salient; see draft-phelan-dccp-media-00.txt for a description of how
TFRC's "contentment penalty" might apply when wrong guesses about available bandwidth
come into play.

That section of the draft may well date back some time, of course, so it may be unfair to
ask for changes, and I certainly wouldn't block the draft for this.  But a review by the DCCP
folk might imrpove this a good bit; it also might show the need for a separate draft to discuss
the DCCP-specific interactions here.
2003-12-16
06 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for  by Ted Hardie
2003-12-16
06 Jon Peterson State Changes to IESG Evaluation from Waiting for Writeup by Jon Peterson
2003-12-16
06 Steven Bellovin
[Ballot discuss]
I'm not sure what to do about the conflict between this document's security suggestion versus NAT.  Of course, it's hardly news that NAT …
[Ballot discuss]
I'm not sure what to do about the conflict between this document's security suggestion versus NAT.  Of course, it's hardly news that NAT is bad for security, so we should probably live with it.  This document should refer to whatever document defines SDP security.

There are many other things that can cause erroneous bandwidth estimates, including various forms of tunneling (GRE, IPsec, 6to4) and link-layer encapsulation -- should those be discussed here?
2003-12-16
06 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for  by Steve Bellovin
2003-12-12
06 Ned Freed [Ballot Position Update] New position, No Objection, has been recorded for  by Ned Freed
2003-12-11
06 Jon Peterson Placed on agenda for telechat - 2003-12-18 by Jon Peterson
2003-12-11
06 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2003-12-11
06 Jon Peterson Ballot has been issued by Jon Peterson
2003-12-11
06 Jon Peterson Created "Approve" ballot
2003-12-10
06 (System) State has been changed to Waiting for Writeup from In Last Call by system
2003-11-26
06 Amy Vezza Last call sent
2003-11-26
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2003-11-25
06 Jon Peterson State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Jon Peterson
2003-11-25
06 Jon Peterson Last Call was requested by Jon Peterson
2003-11-25
06 (System) Ballot writeup text was added
2003-11-25
06 (System) Last call text was added
2003-11-25
06 (System) Ballot approval text was added
2003-11-04
06 Jon Peterson New version -05 fixes previous comments - will start a Last Call after the IETF meeting in MPLS.
2003-10-30
05 (System) New version available: draft-ietf-mmusic-sdp-bwparam-05.txt
2003-10-09
06 Jon Peterson State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson
2003-10-06
06 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2003-08-19
06 Natalia Syracuse Draft Added by Natalia Syracuse
2003-06-26
04 (System) New version available: draft-ietf-mmusic-sdp-bwparam-04.txt
2003-05-28
03 (System) New version available: draft-ietf-mmusic-sdp-bwparam-03.txt
2003-05-14
02 (System) New version available: draft-ietf-mmusic-sdp-bwparam-02.txt
2003-02-27
01 (System) New version available: draft-ietf-mmusic-sdp-bwparam-01.txt
2003-01-30
00 (System) New version available: draft-ietf-mmusic-sdp-bwparam-00.txt