TRAM P.E. Martinsen
Internet-Draft H. Wildfeuer
Intended status: Standards Track Cisco
Expires: August 16, 2014 February 12, 2014

Differentiated prIorities and Status Code-points Using Stun Signalling (DISCUSS)


This draft describes a mechanism for information exchange between an application and the network. The information provided from the application to the network MAY be used by a network element in the path to modify its behavior to improve application quality of experience (QoE). Likewise, the information provided by the network to the application MAY be used by the application to modify its behavior to optimize for QoE.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 16, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

In the context of Content, Mobile, Fixed Service, Service Providers, Enterprise and Private networks have a need to prioritize packet flows end-to-end. These flows are often dynamic, time-bound, encrypted, peer-to-peer, possibly asymmetric, and might have different priorities depending on network conditions, direction, time of the day, dynamic user preferences and other factors. These factors may be time variant, and thus need to be signalled. Moreover, in many cases of peer-to-peer communication, flow information is known only to the endpoint. These considerations, coupled with the trend to use encryption for browser-to-browser communication [I-D.ietf-rtcweb-security-arch], imply that access lists, deep packet inspection and other static prioritization methods cannot be employed successfully to prioritize packet flows.

There is a need for a solution that is easy for the application developer to use. That means consistent behaviour on all supported platforms and preferably without need of administrative privileges to set and read values. The solution also needs to be able to cross administrative domains without the risk of being rewritten.

This draft describes how these problems can be solved by defining a few strictly defined STUN [RFC5389] attributes which can be added to any STUN message the client wants to send. STUN messages are typically sent during the ICE [RFC5245] connectivity check phase when the media session is established, or when keep-alive STUN messages are sent after the session is established. The application is not limited to those two scenarios, if some communication between application and network is needed it can choose to do so at any time.

Devices on the media path can use the information in the STUN attributes to prioritize the flow, perform traffic engineering, provide network analytics or as a gateway to existing methods for prioritizing flows (DSCP [RFC2474]). Applications can use information in network status attribute to influence rate stating points or rate adaption mechanisms.

The functionality described here is referred to as DISCUSS. Due to the security implications described in [I-D.thomson-mmusic-ice-webrtc] where large STUN packet are used amplify an attack, keeping the added STUN attributes is an important design consideration. To avoid unwanted information leakage the new defined STUN attributes are strictly defined in this draft.

2. General Usage

This draft defines several attributes that can be added to a STUN message; STREAM-TYPE, BANDWIDTH-USAGE, STREAM-PRIORITY and NETWORK-STATUS. See Section 6 for the formal description. It is RECOMMENDED to add them to a STUN request response pair, especially if the NETWORK-STATUS attribute is in use. This allows the information gathered to be sent back to the requesting agent in the the STUN response.

The STREAM-TYPE, BANDWIDTH-USAGE, STREAM-PRIORITY attributes MUST be added before any INTEGRITY attribute. It is RECOMMENDED to only add these attributes to STUN messages containing a INTEGRITY attribute as this prevents tampering with the content of the attribute.

If the client wants to receive feedback from the network it must add a null NETWORK-STATUS attribute. A null NETWORK_STATUS attribute consists of the attribute with the Node Cnt field set to zero (0) and the CS bit set to 0 (Off). This attribute MUST be added after the INTEGRITY attribute, as on-path devices may write information into this attribute. Having a readily available attribute to write into will save the the on-path device from growing buffers to add their own attribute. On path devices SHOULD not add their own NETWORK-STATUS attribute (or any other STUN attribute).

If an agent receives a STUN request with a NETWORK-STATUS attribute after the INTEGRITY attribute, it should copy the content into a new NETWORK-STATUS attribute and add it before the INTEGRITY attribute when sending the STUN response. A new null NETWORK-STATUS attribute can be added after the INTEGRITY attribute. New STUN attributes described in this draft can also be added describing the stream in this direction.

If an agent receives a STUN response with a NETWORK-STATUS attribute before the INTEGRITY attribute, this describes the stream in the upstream direction. A NETWORK-STATUS attribute after the INTEGRITY attribute describes the stream in the downstream direction.

It might make sense to distinguish DISCUSS packets from normal STUN packets. This would prevent unnecessary processing of normal STUN packets on the network nodes.

  Alice                router1            router2              Bob
   |                      |                   |                  |
   |Binding_Request       |                   |                  |
(1)|--------------------->|(2)                |                  |
   |                      |                   |                  |
   |                      |Binding_Request    |                  |
   |                      |------------------------------------->|
   |                      |                   |                  |
   |                      |                   | Binding_Response |
   |                      |                   |<-----------------|(3)
   |                      |  Binding_Response |                  |
   |<-----------------------------------------|(4)               |
   |(5)                   |                   |                  |

DISCUSS example flow

  1. Alice creates a Binding Request, adds STREAM-TYPE, BANDWIDTH-USAGE, STREAM-PRIORITY attributes before the INTEGRITY attribute and a single null NETWORK-STATUS attribute after the INTEGRITY attribute.
  2. Router1 inspects the STUN Request message and reads any STREAM-TYPE, BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and the information they contain. It then updates the NETWORK-STATUS attribute with any information the router have. It then forwards the request.
  3. Bob processes the STUN Request. When Bob builds the response, it copies the NETWORK-STATUS attribute into the STUN Response before the INTEGRITY check and adds new null NETWORK-STATUS attribute after the INTEGRITY attribute. Bob then transmits the message.
  4. Router2 (first DISCUSS network element for the downstream direction) inspects the Response message, reads the STREAM-TYPE, BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and MAY alter the NETWORK-STATUS attribute located after the INTEGRITY attribute. It then transmits the message.
  5. When Alice receives the STUN Response, she can extract the STREAM-TYPE, BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and the two NETWORK-STATUS attributes to get a complete picture of what the remote agent is sending and how the status of both the upstream and downstream path.

3. Network Processing

This section describes the processing of DISCUSS packets by network devices.

3.1. Packet Processing by Network Device

Network devices are said to support DISCUSS if they perform inspection of packets being forward or switched in order to identify an DISCUSS STUN packet. These devices will also be able to read/write STUN attributes to/from this packet. It is not required that every network device in the path support DISCUSS. It is expected that DISCUSS will have the most value being implemented at certain points in the network (PIN's) such as WAN edge devices, wireless access devices, and Internet gateways.

Network devices that support DISCUSS MAY utilize the information provided by the application in the STUN attributes to modify their behavior. These include the attributes defined in this document with the exception of the NETWORK-STATUS attribute. The NETWORK-STATUS attribute SHOULD NOT be used by the DISCUSS capable network device to modify its behavior. The intent of the NEWTORK-STATUS attribute is for the application to modify its behavior.

If the NETWORK-STATUS attributes exists in a DISCUSS packet after an INTEGRITY attribute, the DISCUSS capable network device MUST process it as described in this section. NETWORK-STATUS attributes that exist before the INTEGRITY attribute MUST NOT be modified by the network device. The modifications to the NETWORK-STATUS attribute are:

The determination of congestion at a device is out of the scope of this document. Setting of CS bit to On by the device is meant to provide direct feedback to the application of potential or current loss of packets in its flow (s). The application can then react to this indication by altering its encoding of information in the packet to deal with congestion/packet loss, e.g. reduce its encoding rate or switch to embedded encoding. Devices SHOULD ensure that the DISCUSS capable applications that do react to congestion notification by reducing their transmission rate be treated properly to ensure fairness with non reacting applications (i.e. ensure fairness for well behaving applications).

The DISCUSS STUN packet SHOULD experience minimal extra processing delay through the DISCUSS capable network device relative to non-DISCUSS packets in the flow. The DISCUSS STUN packet MAY be placed out of order in the packet flow, but SHOULD NOT be delayed more than a few packet interval times.

3.2. Interaction with DSCP

One of the attributes that may be added to the STUN packet by the application is the STREAM-PRIORITY attribute. This attribute indicates the relative priority of streams inside of an application session. This attribute is compatible with the use of DSCP (or other priority markings) at the networking layer as described in this section.

Since transport layer markings may be modified by middle boxes or devices in the path or at the interface of the application itself due to the lack of support in the OS network stack, the STREAM-PRIORITY attribute can be used as a mechanism for ensuring proper QoS treatment through multiple domains. DISCUSS capable device may use the STREAM-PRIORITY attribute to remark the DSCP value to the appropriate value. DSCP re-marking based on STREAM-PRIORITY attribute may make sense at certain PIN's, e.g. gateway between network domains (e.g. managed network to/from Internet), access switches in managed network, etc. The translation from the Priority number in the STREAM-PRIORITY attribute to the correct transport layer marking (e.g. DSCP) is implementation specific and out of the scope of this document.

[I-D.dhesikan-tsvwg-rtcweb-qos] provides the recommended DSCP values for webrtc enabled browsers to use for various classes of traffic.

4. Interaction with ICE

An ICE connectivity check is performed by sending a STUN Binding indication. Prior to sending the agent can add one STREAM-TYPE attribute. If added, only one MUST be added. This is to avoid unnecessary large STUN packets during the connectivity checks. If the connectivity check is sent on a 5-tuple that multiplexes different types of media and more detailed information wants to be signalled it should be done after the connectivity check phase is finished.

This limits the information the STUN messages are able to convey during the connectivity checks, but also avoids adding network confusion with BANDWIDTH-USAGE attributes describing different paths that never going to be utilized.

5. Multiplexed Streams

In some scenarios a 5-tuple can be used to transport several media streams. BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] describes such a mechanism.

When describing the stream with a STREAM-TYPE attribute there are two possibilities to describe the streams that are multiplexed. Adding one attribute for each type (Audio, Video,++), or to save a few bits on the wire it is also possible to construct the STREAM-TYPE so a one type value describes several types. For example audio have the value of 1 and application data have the value of 4. If the STREAM_TYPE value is set to 5 the only combination that gives that is audio and application data.

The other attributes BANDWIDTH-USAGE, STREAM-PRIORITY and NETWORK-STATUS SHOULD only be added once as they describe the behaviour of the 5-tuple and not individual streams.

6. New STUN attributes

This STUN extension defines the following new attributes:



This attribute have a length that are multiples of 4 (32) so no padding is necessary.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|              TYPE             | Interactivity |               |


Figure 1: STREAM TYPE Attribute

     0x0001 Audio
     0x0002 Video
     0x0004 Application Data
     0x0008 Other

Figure 2: STREAM Types

     0x00 Undef
     0x01 Stream (Broadcast? Oneway?)
     0x02 Interactive

Figure 3: Interactivity Types

STREAM TYPE is a 16 bit value defined in Figure 2 below describing the flow.
Is a 8 bit value defined in Figure 3 below describing the flow.

It is possible to combine the stream types if a stream contains more than one type.

If a 5-tuple is used to send both a audio and video stream, the stream type can be set to 0x0006. This can be useful if the application wants to hint that the 5-tuple contains several streams, This is useful if the attribute is added to STUN binding requests during ICE connectivity checks. If more information regarding multiplexed streams is needed it is possible to add more than one attribute to a STUN message (See section ??). This can be done to STUN messages that are being sent after the connectivity check phase is finished (Keepalive, consent freshness). During this phase the added size of the STUN messages pose no security threat.


This attribute have a length that are multiples of 4 (32) so no padding is necessary.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|             AVERAGE (kbps)    |           MAX (kbps)          |


Figure 4: BANDWIDTH USAGE Attribute

Expected sustained bandwidth usage for this stream. Note that for elastic types of streams like video, sudden large movements in the picture my lead to this value being inaccurate.
The maximum bandwidth usage for this stream. If the sustained and max value differ greatly it might be safe to assume that an elastic encoder is in use. (Would it be useful to say something about expected BURST lengths?)


This attribute have a length that are multiples of 4 (32) so no padding is necessary.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Priority      |D|    TBD      |           Stream IDX          |
|                           Session ID                          |


Figure 5: STREAM PRIORITY Attribute

Describes this streams priority among other streams coming from this endpoint/application (With same session ID). Values range from 255 (0xFF) to 0.
Delay sensitive. The application can set this bit as a hint to the network element that the stream is delay sensitive. (Unsure if this is useful)
Stream IDX:
Application can choose set this to ease debugging in the network. A reasonable value can foe example be the index have in the SDP.
Session ID:
Identification to distinguish what session this stream is part of. This MUST have the same value for all the media streams the application wants to give differentiated services. (Note that this ID may overlap with other streams that originates from a different IP address. The network element MUST only prioritize among streams with the same Session Id originating from the same IP)


This attribute have a length that are multiples of 4 (32) so no padding is necessary. The values are kept in the same attribute to make it easier for the network element to process it. Only one attribute, with static placement of the fields.

This attribute MUST be added after any INTEGRITY attribute in the STUN message. Values in this attribute can be updated along the network path by nodes that are not able to regenerate a correct INTEGRITY attribute.

 0                    1                   2                   3
 0  1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|CS|   Node Cnt    |           0x7FFFFF                          |


Figure 6: NETWORK-STATUS Attribute

Congestion Status. This bit is set to indicate that there is congestion at the network device's relevant queues/interfaces for this flow. The network element should set this bit to 1 (On) if it is experiencing congestion. This bit is set to 0 (off) when the attribute is created by the application. The application that sees this bit set might act on it by doing some rate adaption or similar action.
Node Cnt:
Numbers of nodes that supports DISCUSS in the network path. Any router on the path that understands DISCUSS should increase this number. This field is set to 0 when the attribute is created by the application.

7. Acknowledgements

Authors would like to thank Dan Wing, Anca Zamfir and Cullen Jennings for their comments and review.

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F. and D.L. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P. and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.

8.2. Informational References

[I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", Internet-Draft draft-ietf-rtcweb-security-arch-08, January 2014.
[I-D.thomson-mmusic-ice-webrtc] Thomson, M., "Using Interactive Connectivity Establishment (ICE) in Web Real-Time Communications (WebRTC)", Internet-Draft draft-thomson-mmusic-ice-webrtc-01, October 2013.
[I-D.dhesikan-tsvwg-rtcweb-qos] Dhesikan, S., Druta, D., Jones, P. and J. Polk, "DSCP and other packet markings for RTCWeb QoS", Internet-Draft draft-dhesikan-tsvwg-rtcweb-qos-04, January 2014.
[I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H. and C. Jennings, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Internet-Draft draft-ietf-mmusic-sdp-bundle-negotiation-05, October 2013.

Authors' Addresses

Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 20 Lysaker, Akershus 1366 Norway EMail:
Herb Wildfeuer Cisco Systems, Inc. 821 Alder Drive Milpitas, California 95035 United States EMail: