draft-ietf-mmusic-traffic-class-for-sdp-03.txt   draft-ietf-mmusic-traffic-class-for-sdp-04.txt 
Network WG James Polk Network WG James Polk
Internet-Draft Subha Dhesikan Internet-Draft Subha Dhesikan
Expires: August 18, 2013 Paul Jones Expires: January 14, 2014 Paul Jones
Intended Status: Standards Track (PS) Cisco Systems Intended Status: Standards Track (PS) Cisco Systems
Feb 18, 2013 July 14, 2013
The Session Description Protocol (SDP) 'trafficclass' Attribute The Session Description Protocol (SDP) 'trafficclass' Attribute
draft-ietf-mmusic-traffic-class-for-sdp-03 draft-ietf-mmusic-traffic-class-for-sdp-04
Abstract Abstract
This document proposes a new Session Description Protocol (SDP) This document proposes a new Session Description Protocol (SDP)
attribute to identify the traffic class a session is requesting attribute to identify the traffic class a session is requesting
in its offer/answer exchange. in its offer/answer exchange.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2013. This Internet-Draft will expire on January 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
3.1 Categories within the SDP Traffic Class Label . . . . . . 8 3.1 Categories within the SDP Traffic Class Label . . . . . . 8
3.2 Applications within the SDP Traffic Class Label . . . . . 9 3.2 Applications within the SDP Traffic Class Label . . . . . 9
3.3 Adjectives within the SDP Traffic Class Label . . . . . . 9 3.3 Adjectives within the SDP Traffic Class Label . . . . . . 9
3.3.1 Qualified Adjectives . . . . . . . . . . . . . . . . . 9 3.3.1 Qualified Adjectives . . . . . . . . . . . . . . . . . 9
4. Matching Categories with Applications and Adjectives . . . . 11 4. Matching Categories with Applications and Adjectives . . . . 11
4.1 Conversational Category Traffic Class . . . . . . . . . . 11 4.1 Conversational Category Traffic Class . . . . . . . . . . 11
4.2 Multimedia-Conferencing Category Traffic Class . . . . . 12 4.2 Multimedia-Conferencing Category Traffic Class . . . . . 12
4.3 Realtime-Interactive Category Traffic Class . . . . . . . 14 4.3 Realtime-Interactive Category Traffic Class . . . . . . . 14
4.4 Multimedia-Streaming Category Traffic Class . . . . . . . 15 4.4 Multimedia-Streaming Category Traffic Class . . . . . . . 15
4.5 Broadcast Category Traffic Class . . . . . . . . . . . . 17 4.5 Broadcast Category Traffic Class . . . . . . . . . . . . 17
5. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 18 4.6 Intermittent Category Traffic Class . . . . . . . . . . . 18
5.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 18 5. Offer/Answer Behavior . . . . . . . . . . . . . . . . . . . . 19
5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 19 5.1 Offer Behavior . . . . . . . . . . . . . . . . . . . . . 20
6. Security considerations . . . . . . . . . . . . . . . . . . . 20 5.2 Answer Behavior . . . . . . . . . . . . . . . . . . . . . 20
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . 26
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 26
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 27
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [RFC4566] provides a means The Session Description Protocol (SDP) [RFC4566] provides a means
for an offerer to describe the specifics of a session to an for an offerer to describe the specifics of a session to an
answerer, and for the answerer to respond back with its session answerer, and for the answerer to respond back with its session
skipping to change at page 5, line 15 skipping to change at page 5, line 17
RFC 4594 as such service identification information is currently RFC 4594 as such service identification information is currently
not available in SDP and therefore to the network elements. Since not available in SDP and therefore to the network elements. Since
SDP understands how each stream is created (i.e., the particulars of SDP understands how each stream is created (i.e., the particulars of
the RTP stream), this is the right place to have this service the RTP stream), this is the right place to have this service
differentiated. Such service differentiation can then be differentiated. Such service differentiation can then be
communicated to and leveraged by the network. communicated to and leveraged by the network.
[Editor's Note: the words "traffic" and "service" are similar enough [Editor's Note: the words "traffic" and "service" are similar enough
that the above paragraph talks about RFC 5897's that the above paragraph talks about RFC 5897's
"service identification", but this document only "service identification", but this document only
discuss and propose traffic indications in SDP.] discusses and proposes traffic indications in SDP.]
This document proposes a simple attribute line to identify the This document proposes a simple attribute line to identify the
application a session is requesting in its offer/answer exchange. application a session is requesting in its offer/answer exchange.
This document uses previously defined service class strings for This document uses previously defined service class strings for
consistency between IETF documents. consistency between IETF documents.
This document modifies the traffic classes originally created in RFC This document modifies the traffic classes originally created in RFC
4594 in Section 2, incrementing each class with application 4594 in Section 2, incrementing each class with application
identifiers and optional adjective strings. Section 3 defines the identifiers and optional adjective strings. Section 3 defines the
new SDP attribute "trafficclass". Section 4 discusses the offerer new SDP attribute "trafficclass". Section 4 discusses the offerer
skipping to change at page 6, line 53 skipping to change at page 6, line 54
attribute =/ traffic-class-label attribute =/ traffic-class-label
traffic-class-label = "trafficclass" ":" [SP] category traffic-class-label = "trafficclass" ":" [SP] category
"." application *( "." adjective ) "." application *( "." adjective )
category = "broadcast" / category = "broadcast" /
"realtime-interactive" / "realtime-interactive" /
"multimedia-conferencing" / "multimedia-conferencing" /
"multimedia-streaming" / "multimedia-streaming" /
"conversational" / tcl-token "conversational" /
"intermittent / tcl-token
application = tcl-token application = tcl-token
adjective = classified-adjective / adjective = classified-adjective /
unclassified-adjective unclassified-adjective
classified-adjective = tcl-token ":" tcl-token classified-adjective = tcl-token ":" tcl-token
unclassified-adjective = tcl-token unclassified-adjective = tcl-token
tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT ) tcl-token = ALPHA *( [ "-" ] ALPHA / DIGIT )
The attribute is named "trafficclass", for traffic classification, The attribute is named "trafficclass", for traffic classification,
identifying which one of the five categories applies to the identifying which one of the six categories applies to the
media stream associated with this m-line. There MUST NOT be more media stream associated with this m-line. There MUST NOT be more
than one category component per media line. than one category component per media line.
The categories in this document are an augmented version of the The categories in this document are an augmented version of the
application labels introduced by table 3 of RFC 4595 (which will be application labels introduced by table 3 of RFC 4594 (which will be
rewritten based on the updated labels and treatments expected for rewritten based on the updated labels and treatments expected for
each traffic class defined in this document). each traffic class defined in this document).
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| Application Labels | Category Classes Defined | | Application Labels | Category Classes Defined |
| Defined in RFC 4594 | in this document | | Defined in RFC 4594 | in this document |
+=========================+==============================+ +=========================+==============================+
| broadcast-video | broadcast | | broadcast-video | broadcast |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
| realtime-interactive | realtime-interactive | | realtime-interactive | realtime-interactive |
skipping to change at page 7, line 55 skipping to change at page 8, line 4
document relative to how RFC 4594 defined them. These differences document relative to how RFC 4594 defined them. These differences
are articulated in Section 4 of this document. are articulated in Section 4 of this document.
Applications and adjectives are defined using the syntax of Applications and adjectives are defined using the syntax of
"tcl-token" defined above. "tcl-token" defined above.
RFC 4566 defined SDP as case sensitive. Everything is here as well. RFC 4566 defined SDP as case sensitive. Everything is here as well.
An algorithm such as alphabetizing the list of components and An algorithm such as alphabetizing the list of components and
matching the understood strings SHOULD be used for determining the matching the understood strings SHOULD be used for determining the
traffic within a session. traffic within a session. Strings not understood by an entity MUST
be ignored during processing, but MUST NOT be deleted.
Any category, application, or adjective string component within this Any category, application, or adjective string component within this
attribute that is not understood MUST be ignored, leaving all that attribute that is not understood MUST be ignored, leaving all that
is understood to be processed. Ignored components SHOULD NOT be is understood to be processed. Ignored components SHOULD NOT be
deleted, as a downstream entity could understand the component(s) deleted, as a downstream entity could understand the component(s)
and use it/them during processing. and use it/them during processing.
The following is an example of media level description with a The following is an example of media level description with a
'trafficclass' attribute: 'trafficclass' attribute:
skipping to change at page 8, line 34 skipping to change at page 8, line 36
answers these questions, is the traffic answers these questions, is the traffic
- one-way or two-or-more-way interactive? - one-way or two-or-more-way interactive?
- elastic or inelastic (as far as retransmissions)? - elastic or inelastic (as far as retransmissions)?
- buffered or (virtually) non-buffered? - buffered or (virtually) non-buffered?
- media or non-media (data)? - media or non-media (data)?
The five category components of the traffic class attribute defined The six category components of the traffic class attribute defined
within this specification are as follows: within this specification are as follows:
o conversational o conversational
o multimedia-conferencing o multimedia-conferencing
o realtime-interactive o realtime-interactive
o multimedia-streaming o multimedia-streaming
o broadcast o broadcast
o intermittent
Sections 3.1 through 3.5 define each of the above. Sections 4.1 through 4.6 define each of the above.
The category component MUST NOT be the only component present in a The category component MUST NOT be the only component present in a
traffic class attribute. The category component MUST BE paired with traffic class attribute. The category component MUST BE paired with
an application component to give enough meaning to the traffic class an 'application' component to give enough meaning to the traffic
labeling goal. class labeling goal.
Not understanding the category component SHOULD mean that this Not understanding the category component SHOULD mean that this
attribute is ignored, because of the information about the attribute is ignored, because of the information about the
communication flow within that component. expected behavior of this communication flow is identified by or
within that component.
3.2 Applications within the SDP Traffic Class Label 3.2 Applications within the SDP Traffic Class Label
The application component identifies the application of a particular The application component identifies the application of a particular
traffic flow, for example, audio or video. The application types are traffic flow, for example, audio or video. The application types are
listed and defined in Section 2 of this document. Not every category listed and defined in Section 2 of this document. Not every category
is paired with every application listed, at least as defined in this is paired with every application listed, at least as defined in this
document. One or more applications are inappropriate in one or more document. One or more applications are inappropriate in one or more
categories. For example, iptv is a single directional traffic categories. For example, iptv is a single directional traffic
application that is suited for the broadcast (one-way) category application that is suited for the broadcast (one-way) category
rather than categories like realtime-interactive or conversational. rather than categories like realtime-interactive or conversational.
Section 4.1 through 4.5 list many of the expected combinations. Section 4.1 through 4.6 list many of the expected combinations.
3.3 Adjectives within the SDP Traffic Class Label 3.3 Adjectives within the SDP Traffic Class Label
For additional application type granularity, adjective components For additional application type granularity, adjective components
can be added. One or more adjectives can be within the same traffic can be added. One or more adjectives can be within the same traffic
class attribute to provide more differentiation. class attribute to provide more differentiation.
It is important to note that while the order of component types It is important to note that while the order of component types
matter, the order of the adjective components do not. There might be matter, the order of the adjective components do not. There might be
local significance to the ordering of adjectives though, such as local significance to the ordering of adjectives though, such as
skipping to change at page 11, line 21 skipping to change at page 11, line 22
4.1 Conversational Category Traffic Class 4.1 Conversational Category Traffic Class
The "conversational" traffic class is best suited for applications The "conversational" traffic class is best suited for applications
that require very low delay variation and generally intended to that require very low delay variation and generally intended to
enable realtime, bi-directional person-to-person or enable realtime, bi-directional person-to-person or
multi-directional via an MCU communication. Conversational flows are multi-directional via an MCU communication. Conversational flows are
inelastic, and with few exceptions, use a UDP transport. inelastic, and with few exceptions, use a UDP transport.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| | High priority, typically | Very | Very | Very | | | High priority, typically | Very | Very | Very |
|conversational | small packets (large video | Low | Low | Low | |conversational | small packets (large video | Low | Low | Low |
| | frames produce large packets),| | | | | | frames produce large packets),| | | |
| | generally sustained high | | | | | | generally sustained high | | | |
| | packet rate, low inter-packet | | | | | | packet rate, low inter-packet | | | |
| | transmission interval, | | | | | | transmission interval, | | | |
| | usually UDP framed in (S)RTP | | | | | | usually UDP framed in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
skipping to change at page 13, line 10 skipping to change at page 13, line 16
The "multimedia-conferencing" traffic class is best suited for The "multimedia-conferencing" traffic class is best suited for
applications that are generally intended for communication between applications that are generally intended for communication between
human users, but are less demanding in terms of delay, packet loss, human users, but are less demanding in terms of delay, packet loss,
and jitter than what conversational applications require. These and jitter than what conversational applications require. These
applications require low to medium delay and may have the ability to applications require low to medium delay and may have the ability to
change encoding rate (rate adaptive) or transmit data at varying change encoding rate (rate adaptive) or transmit data at varying
rates. rates.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| multimedia- | Variable size packets, | Low | Low | Low | | multimedia- | Variable size packets, | Low | Low | Low |
| conferencing | Variable transmit interval, | - | - | - | | conferencing | Variable transmit interval, | - | - | - |
| | rate adaptive, reacts to |Medium|Medium|Medium| | | rate adaptive, reacts to |Medium|Medium|Medium|
| | loss, usually TCP-based | | | | | | loss, usually TCP-based | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 4. Multimedia Conferencing Traffic Characteristics Figure 4. Multimedia Conferencing Traffic Characteristics
skipping to change at page 14, line 40 skipping to change at page 14, line 46
4.3 Realtime-Interactive Category Traffic Class 4.3 Realtime-Interactive Category Traffic Class
The "Realtime-Interactive" traffic class is intended for interactive The "Realtime-Interactive" traffic class is intended for interactive
variable rate inelastic applications that require low jitter and variable rate inelastic applications that require low jitter and
loss and very low delay. Many of the applications that use the loss and very low delay. Many of the applications that use the
Realtime-Interactive category use TCP or SCTP, even gaming, because Realtime-Interactive category use TCP or SCTP, even gaming, because
lost packets is information that is still required - therefore it is lost packets is information that is still required - therefore it is
retransmitted. retransmitted.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| realtime- | Inelastic, mostly variable | Low | Very | Low | | realtime- | Inelastic, mostly variable | Low | Very | Low |
| interactive | rate, rate increases with | | Low | | | interactive | rate, rate increases with | | Low | |
| | user activity | | | | | | user activity | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 6. Realtime Interactive Traffic Characteristics Figure 6. Realtime Interactive Traffic Characteristics
The following application components are The following application components are
skipping to change at page 15, line 51 skipping to change at page 16, line 6
Combinations Combinations
4.4 Multimedia-Streaming Category Traffic Class 4.4 Multimedia-Streaming Category Traffic Class
The "multimedia-streaming" traffic class is best suited for variable The "multimedia-streaming" traffic class is best suited for variable
rate elastic streaming media applications where a human is waiting rate elastic streaming media applications where a human is waiting
for output and where the application has the capability to react to for output and where the application has the capability to react to
packet loss by reducing its transmission rate. packet loss by reducing its transmission rate.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| multimedia- | Variable size packets, |Low - |Medium| High | | multimedia- | Variable size packets, |Low - |Medium| High |
| streaming | elastic with variable rate |Medium|- High| | | streaming | elastic with variable rate |Medium|- High| |
| | | | | | | | | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 8. Multimedia Streaming Traffic Characteristics Figure 8. Multimedia Streaming Traffic Characteristics
The following application components are appropriate for use with The following application components are appropriate for use with
the Multimedia-Streaming category: the Multimedia-Streaming category:
o audio (see Section 4.1) o audio (see Section 4.1)
o video (see Section 4.1) o video (see Section 4.1)
o webcast o webcast - is a media file distributed over the Internet or
enterprise network using streaming media technology.
o multiplex (see Section 4.1) o multiplex (see Section 4.1)
The primary difference from the multimedia-streaming category and The primary difference from the multimedia-streaming category and
the broadcast category is about the length of time for buffering. the broadcast category is about the length of time for buffering.
Buffered streaming audio and/or video which are initiated by SDP, Buffered streaming audio and/or video which are initiated by SDP,
and not HTTP. Buffering here can be from many seconds to hours, and and not HTTP. Buffering here can be from many seconds to hours, and
is typically at the destination end (as opposed to Broadcast is typically at the destination end (as opposed to Broadcast
buffering which is minimal at the destination). The buffering aspect buffering which is minimal at the destination). The buffering aspect
is what differentiates this category class from the broadcast is what differentiates this category class from the broadcast
skipping to change at page 17, line 18 skipping to change at page 17, line 25
The "broadcast" traffic class is best suited for inelastic streaming The "broadcast" traffic class is best suited for inelastic streaming
media Applications, which might have a 'wardrobe malfunction' delay media Applications, which might have a 'wardrobe malfunction' delay
at or near the source but not typically at the destination, that may at or near the source but not typically at the destination, that may
be of constant or variable rate, requiring low jitter and very low be of constant or variable rate, requiring low jitter and very low
packet loss. packet loss.
See Section 4.4 for the difference between Multimedia-Streaming and See Section 4.4 for the difference between Multimedia-Streaming and
Broadcast; it all has to do with buffering. Broadcast; it all has to do with buffering.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Traffic Class | | Tolerance to | | Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======| |===============+===============================+======+======+======|
| broadcast | Constant and variable rate, | Very |Low - |Low - | | broadcast | Constant and variable rate, | Very |Low - |Low - |
| | inelastic, generally | Low |Medium|Medium| | | inelastic, generally | Low |Medium|Medium|
| | non-bursty flows, generally | | | | | | non-bursty flows, generally | | | |
| | sustained high packet rate, | | | | | | sustained high packet rate, | | | |
| | low inter-packet transmission | | | | | | low inter-packet transmission | | | |
| | interval, usually UDP framed | | | | | | interval, usually UDP framed | | | |
| | in (S)RTP | | | | | | in (S)RTP | | | |
+---------------+-------------------------------+------+------+------+ +---------------+-------------------------------+------+------+------+
Figure 10. Broadcast Traffic Characteristics Figure 10. Broadcast Traffic Characteristics
The following application components are appropriate for use with The following application components are appropriate for use with
the Broadcast category: the Broadcast category:
o audio (see Section 4.1) o audio (see Section 4.1)
o video (see Section 4.1) o video (see Section 4.1)
o iptv o iptv - is one-way television content that, instead of being
delivered through traditional broadcast and cable formats,
is received by the viewer through the technologies used for
computer networks. IPTV is can be service provider or
enterprise network based.
o multiplex (see Section 4.1) o multiplex (see Section 4.1)
With adjective substrings to the above: With adjective substrings to the above:
o live (non-buffered) o live (non-buffered) - refers to various types of media broadcast
without a significant delay, typically measured in
milliseconds to a few seconds only.
o surveillance - one way audio from a microphone or video from a o surveillance - one way audio from a microphone or video from a
camera (e.g., observing a parking lot or building exit), camera (e.g., observing a parking lot or building exit),
typically enabled for long periods of time, usually stored typically enabled for long periods of time, usually stored
at the destination. at the destination.
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| Category | Application | Adjective | | Category | Application | Adjective |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
| broadcast | audio | surveillance | | broadcast | audio | surveillance |
skipping to change at page 18, line 36 skipping to change at page 18, line 46
| | | aq:none | | | | aq:none |
| | | | | | | |
| | multiplex | aq:admitted | | | multiplex | aq:admitted |
| | | aq:non-admitted | | | | aq:non-admitted |
| | | aq:partial | | | | aq:partial |
| | | aq:none | | | | aq:none |
+----------------------+---------------------+---------------------+ +----------------------+---------------------+---------------------+
Figure 11. Broadcast Applications and Adjective Combinations Figure 11. Broadcast Applications and Adjective Combinations
4.6 Intermittent Category Traffic Class
The "intermittent" traffic class is best suited for inconstant rate
applications such as those from a sensor device, where tolerance to
loss, delay and jitter is often medium to high in nature. This
category is not to be used for bulk file transfers, rather it can be
sometimes bursty for brief periods of time, but then not produce
traffic for short or long (i.e., hours or days) durations. Nor is
this category to be used for any kind of regular paced rate of
transmission, no matter how long the interval.
+--------------------------------------------------------------------+
| Traffic Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+===============================+======+======+======|
| intermittent | Inconstant rate, infrequent |Medium|Medium| High |
| | but sometimes bursty flows, |- High|- High| |
| | generally non-regular, | | | |
| | variable inter-packet | | | |
| | transmission interval, can be | | | |
| | UDP framed in (S)RTP or in | | | |
| | TCP/SCTP | | | |
+---------------+-------------------------------+------+------+------+
Figure 12. Intermittent Traffic Characteristics
The following application components are appropriate for use with
the Broadcast category:
o sensor - a flow containing information obtained from a sensor,
such as a temperature or motion sensor.
With adjective substrings to the above:
o there are no defined adjectives for the 'sensor' application at
this time. There are many examples one could think would be viable
adjectives, such as light, motion, temperature, magnetic fields,
gravity, humidity, moisture, vibration, pressure, electrical
fields, and other physical aspects of the external environment
measured by the sensor.
+----------------------+---------------------+---------------------+
| Category | Application | Adjective |
+----------------------+---------------------+---------------------+
| intermittent | sensor | (undefined at this |
| | | time) |
+----------------------+---------------------+---------------------+
Figure 13. Intermittent Applications and Adjective Combinations
5. Offer/Answer Behavior 5. Offer/Answer Behavior
Through the inclusion of the 'trafficclass' attribute, an Through the inclusion of the 'trafficclass' attribute, an
offer/answer exchange identifies the application type for use by offer/answer exchange identifies the application type for use by
endpoints within a session. Policy elements can use this attribute endpoints within a session. Policy elements can use this attribute
to determine the acceptability and/or treatment of that session to determine the acceptability and/or treatment of that session
through lower layers. One specific use-case is for setting of the through lower layers. One specific use-case is for setting of the
DSCP specific for that application type (say a broadcast instead DSCP specific for that application type (say a broadcast instead
of a conversational video), decided on a per domain basis - of a conversational video), decided on a per domain basis -
instead of exclusively by the offering domain. instead of exclusively by the offering domain.
skipping to change at page 22, line 36 skipping to change at page 23, line 49
aq:admitted [this document] aq:admitted [this document]
aq:non-admitted [this document] aq:non-admitted [this document]
aq:partial [this document] aq:partial [this document]
aq:none [this document] aq:none [this document]
7.5 The Traffic Classification Component Mapping 7.5 The Traffic Classification Component Mapping
7.5.1 Broadcast Applications and Adjective Combinations 7.5.1 Broadcast Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Broadcast category mapping similar to Table 11 in Section 4.5 of Broadcast category mapping similar to Figure 11 in Section 4.5 of
this document within the Session Description Protocol (SDP) this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Broadcast Applications and Adjective Combinations Registry Name: Broadcast Applications and Adjective Combinations
Table Table
Reference: [this document] Reference: [this document]
Registration Procedures: TBD Registration Procedures: Specification Required
7.5.2 Realtime Interactive Applications and Adjective Combinations 7.5.2 Realtime Interactive Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Realtime Interactive category mapping similar to Table 7 in Section Realtime Interactive category mapping similar to Figure 7 in Section
4.3 of this document within the Session Description Protocol (SDP) 4.3 of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Realtime Interactive Applications and Adjective Registry Name: Realtime Interactive Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: TBD Registration Procedures: Specification Required
7.5.3 Multimedia Conferencing Applications and Adjective Combinations 7.5.3 Multimedia Conferencing Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Multimedia Conferencing category mapping similar to Table 5 in Multimedia Conferencing category mapping similar to Figure 5 in
Section 4.2 of this document within the Session Description Protocol Section 4.2 of this document within the Session Description Protocol
(SDP) Parameters registry: (SDP) Parameters registry:
Registry Name: Multimedia Conferencing Applications and Adjective Registry Name: Multimedia Conferencing Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: TBD Registration Procedures: Specification Required
7.5.4 Multimedia-Streaming 7.5.4 Multimedia-Streaming
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
Multimedia-Streaming category mapping similar to Table 9 in Section Multimedia-Streaming category mapping similar to Figure 9 in Section
4.4 of this document within the Session Description Protocol (SDP) 4.4 of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Multimedia-Streaming Applications and Adjective Registry Name: Multimedia-Streaming Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: TBD Registration Procedures: Specification Required
7.5.5 Conversational Applications and Adjective Combinations 7.5.5 Conversational Applications and Adjective Combinations
This document requests IANA to create a new registry for the This document requests IANA to create a new registry for the
conversational category mapping similar to Table 3 in Section 4.1 of conversational category mapping similar to Figure 3 in Section 4.1
this document within the Session Description Protocol (SDP) of this document within the Session Description Protocol (SDP)
Parameters registry: Parameters registry:
Registry Name: Conversational Applications and Adjective Registry Name: Conversational Applications and Adjective
Combinations Table Combinations Table
Reference: [this document] Reference: [this document]
Registration Procedures: TBD Registration Procedures: Specification Required
7.5.6 Intermittent Applications and Adjective Combinations
This document requests IANA to create a new registry for the
intermittent category mapping similar to Table 13 in Section 4.6 of
this document within the Session Description Protocol (SDP)
Parameters registry:
Registry Name: Intermittent Applications and Adjective
Combinations Table
Reference: [this document]
Registration Procedures: Specification Required
8. Acknowledgments 8. Acknowledgments
To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David To Dave Oran, Toerless Eckert, Henry Chen, David Benham, David
Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn, Benham, Mo Zanty, Michael Ramalho, Glen Lavers, Charles Ganzhorn,
Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings Paul Kyzivat, Greg Edwards, Charles Eckel, Dan Wing, Cullen Jennings
and Peter Saint-Andre for their comments and suggestions. and Peter Saint-Andre for their comments and suggestions.
9. References 9. References
skipping to change at page 25, line 29 skipping to change at page 27, line 4
170 W Tasman St 170 W Tasman St
San Jose, CA, USA San Jose, CA, USA
+1.408-902-3351 +1.408-902-3351
mailto: sdhesika@cisco.com mailto: sdhesika@cisco.com
Paul E. Jones Paul E. Jones
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC, USA Research Triangle Park, NC, USA
+1 919 476 2048 +1 919 476 2048
mailto: paulej@packetizer.com mailto: paulej@packetizer.com
Appendix - Changes from Previous Versions Appendix - Changes from Previous Versions
A.1 From -02 to -03 A.1 From -03 to -04
These are the following changes made between the WG -03 version and
the -04 version:
- minimal text changes.
- introduced the "intermittent" category based on IETF86 feedback in
the WG.
A.2 From -02 to -03
These are the following changes made between the WG -02 version and These are the following changes made between the WG -02 version and
the -03 version: the -03 version:
- Rearranged a fair amount of text - Rearranged a fair amount of text
- Separated and defined the components into separate subsections. - Separated and defined the components into separate subsections.
- built 5 different tables, one per category, that lists within each - built 5 different tables, one per category, that lists within each
category - what applications are appropriate as well as what category - what applications are appropriate as well as what
adjectives are appropriate for each application within that adjectives are appropriate for each application within that
category. category.
- added the 'partial' admission qualifier for those flows that have - added the 'partial' admission qualifier for those flows that have
only part of their respective flow admitted (i.e., CAC'd). only part of their respective flow admitted (i.e., CAC'd).
A.2 From -01 to -02 A.3 From -01 to -02
These are the following changes made between the WG -01 version and These are the following changes made between the WG -01 version and
the -02 version: the -02 version:
- converged the use of terms 'parent' and 'category' to just - converged the use of terms 'parent' and 'category' to just
'category' for consistency. 'category' for consistency.
- changed ABNF to reflect extensibility by not having applications - changed ABNF to reflect extensibility by not having applications
and adjectives named in the ABNF, rather have them merely IANA and adjectives named in the ABNF, rather have them merely IANA
registered. registered.
- merged the qualified and unqualified adjective sections into a - merged the qualified and unqualified adjective sections into a
single section on adjectives, but allowing some to have a single section on adjectives, but allowing some to have a
preceding qualifier. preceding qualifier.
- text clean-up - text clean-up
A.3 From -00 to -01 A.4 From -00 to -01
These are the following changes made between the WG -00 version and These are the following changes made between the WG -00 version and
the -01 version: the -01 version:
- removed the non-SDP applications Netflix and VOD - removed the non-SDP applications Netflix and VOD
- switched the adjective 'desktop' to 'avconf' - switched the adjective 'desktop' to 'avconf'
- Labeled each of the figures. - Labeled each of the figures.
skipping to change at page 26, line 45 skipping to change at page 28, line 28
- defined Video surveillance - defined Video surveillance
- added the concept of a 'qualified' adjective, and modified the - added the concept of a 'qualified' adjective, and modified the
ABNF. ABNF.
- deleted the idea of a 'cac-class' as a separate component, and - deleted the idea of a 'cac-class' as a separate component, and
made the equivalent a qualified adjective. made the equivalent a qualified adjective.
- modified the answerer behavior because of the removal of the - modified the answerer behavior because of the removal of the
'cac-class' component. 'cac-class' component.
- created an IANA registry for qualified adjectives - created an IANA registry for qualified adjectives
- general clean-up of the doc. - general clean-up of the doc.
Did *not* do the following in this version:
- add the ability to have more than one trafficclass attribute based
on the codec chosen, as feedback indicated this was a bad idea.
- no swap of the Multimedia-Conferencing category with the
offered Collaboration category, as doing this did not solve
any perceived problems.
- add more to the 'how does this get processed' portion of Section
3. That will come in the next revision.
 End of changes. 42 change blocks. 
52 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/