TRAM P. Martinsen Internet-Draft Cisco Intended status: Standards Track February 10, 2014 Expires: August 14, 2014 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: This draft will only offer tamper detection of some of the values. Further discussion regarding the incentive to lie is needed. --palmarti]] 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: 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. --palmarti]] [[Q3: 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? --palmarti]] 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: Problem with consent freshness if not based on STUN. --palmarti]] 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: STREAM TYPE Attribute TYPE: STREAM TYPE is a 16 bit value defined in Figure 2 below describing the flow. 0x0001 Audio 0x0002 Video 0x0004 Application Data 0x0008 Other Figure 2: STREAM Types Interactivity: Is a 8 bit value defined in Figure 3 below describing the flow. 0x00 Undef 0x01 Stream (Broadcast? Oneway?) 0x02 Interactive Figure 3: Interactivity Types 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. 6.2. BANDWIDTH-USAGE 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 AVERAGE: 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. MAX: 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?) 6.3. STREAM-PRIORITY 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 Priority: Describes this streams priority among other streams coming from this endpoint/application (With same session ID). Values range from 255 (0xFF) to 0. D: 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. Stream 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) 6.4. NETWORK-STATUS 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. [[Q5: Does this matter? Could we have several attributes with possible different ordering without any problem for the network element? --palmarti]] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Congestion Lvl| Node Cnt | 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: NETWORK-STATUS Attribute Congestion Lvl: Value in the range 0x00 and Ox0F describing the level of congestion the network element is experiencing at this point. 0x00 means no congestion, 0x0F Fully congested. The router can choose any value between those value as it sees fit. The application that sees those values might act on by doing some rate adaption or similar. The values 0x10-0xFF are reserved for future use. Node Cnt: Numbers of nodes that supports DISCUSS in the network path. Any router on the path that understands DISCUSS should increase this number. 7. References 7.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. 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. 7.2. Informational References [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-07 (work in progress), July 2013. [I-D.thomson-mmusic-ice-webrtc] Thomson, M., "Using Interactive Connectivity Establishment (ICE) in Web Real-Time Communications (WebRTC)", draft- thomson-mmusic-ice-webrtc-01 (work in progress), October 2013. Author's Address Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 20 Lysaker, Akershus 1366 Norway Email: palmarti@cisco.com