Differentiated prIorities and Status Code-points Using Stun Signalling (DISCUSS)
draft-martinsen-tram-discuss-00

Abstract

This draft describes a mechanism for setting differentiated service code points in-band in a stream to make it is easy for the application developer. Those code points can cross administrative domains without being lost and may contain internal application stream priorities. This makes it possible for the network to prioritize the streams that have the most value for the application. It also describes a mechanism to signal early congestion notification messages back to the application.

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 http://datatracker.ietf.org/drafts/current/.

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 14, 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 (http://trustee.ietf.org/license-info) 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
• 2. General Usage
• 3. Interaction with ICE
• 4. Multiplexed streams
• 5. Network Processing
• 6. New STUN attributes
• 6.1. STREAM-TYPE
• 6.2. BANDWIDTH-USAGE
• 6.3. STREAM-PRIORITY
• 6.4. NETWORK-STATUS
• 7. References
• 7.1. Normative References
• 7.2. Informational References
• Author's Address

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. [Q1]palmarti: This draft will only offer tamper detection of some of the values. Further discussion regarding the incentive to lie is needed.

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, DELAY-TOLERANCE, LOSS-TOLERANCE and NETWORK-STATUS. Se 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, DELAY-TOLERANCE, LOSS-TOLERANCE attributes MUST be added before any INTEGRITY attribute. It is RECOMMENDED to only add this attribute 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 empty NETWORK-STATUS attribute. This attribute MUST be added after the INTEGRITY attribute, as on-path devices will 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.

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 empty 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 IMPRESS packets from normal STUN packets. This would prevent unnecessary processing of normal STUN packets on the network nodes.

[Q2]palmarti: A few alternatives (Needs discussion): ---1: Alter the STUN magic cookie. (But than i would not be a STUN packet anymore, and that raises a new set of problems) ---2: Add a special this is IMPRESS attribute. This must be the first attribute in the message. This allows for network node to look for IMPRESS packets at a fixed offset without needing to parse the entire packet. ---3: Alter the transaction id. This might be problematic if using it in conjunction with ICE connectivity checks. But probably fine in other scenarios. ---4: Define a new STUN Method. Also brakes ICE, makes it harder to tag onto attributes to already in use messages.

[Q3]palmarti: Do we want to restrict this to req/resp or do we want to allow for the attributes to be added in this fashion for indications as well?

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

IMPRESS example flow

1. Alice creates a Binding Request, adds STREAM-TYPE, BANDWIDTH-USAGE, DELAY-TOLERANCE, LOSS-TOLERANCE attributes before the INTEGRITY attribute and a single NETWORK-STATUS attribute after the INTEGRITY attribute.
2. Router1 inspects the STUN Request message and reads any STREAM-TYPE, BANDWIDTH-USAGE, DELAY-TOLERANCE or LOSS-TOLERANCE 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 empty NETWORK-STATUS attribute after the INTEGRITY attribute. Bob then transmits the message.
4. Router2 (first IMPRESS network element for the downstream direction) inspects the Response message, reads the STREAM-TYPE, BANDWIDTH-USAGE, DELAY-TOLERANCE or LOSS-TOLERANCE 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, DELAY-TOLERANCE or LOSS-TOLERANCE 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. 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.

[Q4]palmarti: Problem with consent freshness if not based on STUN.

4. Multiplexed streams

TODO: Write. Explain in detail what options you have with multiplexed streams. If not used in conn checks you can add more than one attribute.

5. Network Processing

TODO: Write properly. Update the node cont field. Only update other fields if they are worse than what is already there (Aggregated result). Values are only hints, no promises. Will not describe algorithm to calculate congestion value. But values close to MAX may lead to applications rate adoption mechanisms to kick in. (Fairness problem)

TODO: Describe interaction with DSCP. The rtcweb-qos documents explicitly says how to map for instance video to a DSCP value. If the DSCP values was somehow reset on the path (That happens) the router can remark the IP packets correctly by looking at the STUN message. (IE the signalling in the STUN message survives the whole path, and is integrity protects, but the network node have no way of detecting that...)

6. New STUN attributes

This STUN extension defines the following new attributes:

      0xXXX0: STREAM-TYPE
      0xXXX1: BANDWIDTH-USAGE
      0xXXX2: STREAM-PRIORITY
      0xYYYY: NETWORK-STATUS
           

6.1. STREAM-TYPE

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 |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      

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

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

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)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      

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                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Lvl| Node Cnt      |    0xFFFF                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+