idnits 2.17.1 draft-martinsen-tram-discuss-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the client wants to receive feedback from the network it must add a null NETWORK-STATUS attribute. A null NETWORK_STATUS attribute is created by filling in the all the fields in the attribute with 0x0 values. 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). -- The document date (February 12, 2015) is 3355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 == Outdated reference: A later version (-07) exists of draft-dhesikan-tsvwg-rtcweb-qos-06 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft H. Wildfeuer 4 Intended status: Standards Track Cisco 5 Expires: August 16, 2015 February 12, 2015 7 Differentiated prIorities and Status Code-points Using Stun Signalling 8 (DISCUSS) 9 draft-martinsen-tram-discuss-02 11 Abstract 13 This draft describes a mechanism for information exchange between an 14 application and the network. The information provided from the 15 application to the network MAY be used by a network element in the 16 path to modify its behavior to improve application quality of 17 experience (QoE). Likewise, the information provided by the network 18 to the application MAY be used by the application to modify its 19 behavior to optimize for QoE. 21 The information provided from the application to the network can also 22 be useful for middleboxes that are responsible for security at edges 23 of network (e.g. firewalls) or other middleboxes in determining how 24 to treat the packets delivered from this application. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 16, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Network Processing . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Packet Processing by Network Device . . . . . . . . . . . 6 70 3.2. Interaction with DSCP . . . . . . . . . . . . . . . . . . 7 71 4. Interaction with ICE . . . . . . . . . . . . . . . . . . . . 7 72 5. Multiplexed Streams . . . . . . . . . . . . . . . . . . . . . 8 73 6. New STUN attributes . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. STREAM-TYPE . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2. BANDWIDTH-USAGE . . . . . . . . . . . . . . . . . . . . . 10 76 6.3. STREAM-PRIORITY . . . . . . . . . . . . . . . . . . . . . 10 77 6.4. NETWORK-STATUS . . . . . . . . . . . . . . . . . . . . . 11 78 6.5. SUB-STREAM-TYPE, SUB-STREAM-PRIORITY . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 81 8.1. NATtools . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 11.2. Informational References . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 In the context of Content, Mobile, Fixed Service, Service Providers, 92 Enterprise and Private networks have a need to prioritize packet 93 flows end-to-end. These flows are often dynamic, time-bound, 94 encrypted, peer-to-peer, possibly asymmetric, and might have 95 different priorities depending on network conditions, direction, time 96 of the day, dynamic user preferences and other factors. These 97 factors may be time variant, and thus need to be signalled. 98 Moreover, in many cases of peer-to-peer communication, flow 99 information is known only to the endpoint. These considerations, 100 coupled with the trend to use encryption for browser-to-browser 101 communication [I-D.ietf-rtcweb-security-arch], imply that access 102 lists, deep packet inspection and other static prioritization methods 103 cannot be employed successfully to prioritize packet flows. 105 The lack of congestion control in UDP may lead to problems as 106 described in [I-D.eggert-tsvwg-rfc5405bis]. The mechanism described 107 in this document can be used to introduce fairness and congestion 108 control for UDP streams. 110 There is a need for a solution that is easy for the application 111 developer to use. That means consistent behavior on all supported 112 platforms and preferably without need of administrative privileges to 113 set and read values. The solution also needs to be able to cross 114 administrative domains without the risk of being rewritten. [[Q1: 115 This draft will only offer tamper detection of some of the values. 116 Further discussion regarding the incentive to lie is needed. 117 --palmarti]] 119 This draft describes how these problems can be solved by defining a 120 few strictly defined STUN [RFC5389] attributes which can be added to 121 any STUN message the client wants to send. STUN messages are 122 typically sent during the ICE [RFC5245] connectivity check phase when 123 the media session is established, or when keep-alive STUN messages 124 are sent after the session is established. The application is not 125 limited to those two scenarios, if some communication between 126 application and network is needed it can choose to do so at any time. 128 Devices on the media path can use the information in the STUN 129 attributes to prioritize the flow, perform traffic engineering, 130 provide network analytics or as a gateway to existing methods for 131 prioritizing flows (DSCP [RFC2474]). Applications can use 132 information in network status attribute to influence rate stating 133 points or rate adaption mechanisms. 135 2. General Usage 137 This draft defines several attributes that can be added to a STUN 138 message; STREAM-TYPE, BANDWIDTH-USAGE, STREAM-PRIORITY and NETWORK- 139 STATUS. See Section 6 for the formal description. It is RECOMMENDED 140 to add them to a STUN request response pair, especially if the 141 NETWORK-STATUS attribute is in use. This allows the information 142 gathered to be sent back to the requesting agent in the the STUN 143 response. 145 The STREAM-TYPE, BANDWIDTH-USAGE, STREAM-PRIORITY attributes MUST be 146 added before any INTEGRITY attribute. It is RECOMMENDED to only add 147 these attributes to STUN messages containing a INTEGRITY attribute as 148 this prevents tampering with the content of the attribute. 150 If the client wants to receive feedback from the network it must add 151 a null NETWORK-STATUS attribute. A null NETWORK_STATUS attribute is 152 created by filling in the all the fields in the attribute with 0x0 153 values. This attribute MUST be added after the INTEGRITY attribute, 154 as on-path devices may write information into this attribute. Having 155 a readily available attribute to write into will save the the on-path 156 device from growing buffers to add their own attribute. On path 157 devices SHOULD not add their own NETWORK-STATUS attribute (or any 158 other STUN attribute). 160 If an agent receives a STUN request with a NETWORK-STATUS attribute 161 after the INTEGRITY attribute, it should copy the content into a new 162 NETWORK-STATUS attribute and add it before the INTEGRITY attribute 163 when sending the STUN response. A new null NETWORK-STATUS attribute 164 can be added after the INTEGRITY attribute. New STUN attributes 165 described in this draft can also be added describing the stream in 166 this direction. 168 If an agent receives a STUN response with a NETWORK-STATUS attribute 169 before the INTEGRITY attribute, this describes the stream in the 170 upstream direction. A NETWORK-STATUS attribute after the INTEGRITY 171 attribute describes the stream in the downstream direction. 173 It might make sense to distinguish DISCUSS packets from normal STUN 174 packets. This would prevent unnecessary processing of normal STUN 175 packets on the network nodes. 177 [[Q2: A few alternatives (Needs discussion): ---1: Alter the STUN 178 magic cookie. (But than i would not be a STUN packet anymore, and 179 that raises a new set of problems) ---2: Add a special this is 180 DISCUSS attribute. This must be the first attribute in the message. 181 This allows for network node to look for DISCUSS packets at a fixed 182 offset without needing to parse the entire packet. ---3: Alter the 183 transaction id. This might be problematic if using it in conjunction 184 with ICE connectivity checks. But probably fine in other scenarios. 185 ---4: Define a new STUN Method. Also brakes ICE, makes it harder to 186 tag onto attributes to already in use messages. --palmarti]] 188 [[Q3: Do we want to restrict this to req/resp or do we want to allow 189 for the attributes to be added in this fashion for indications as 190 well? --palmarti]] 191 Alice router1 router2 Bob 192 | | | | 193 |Binding_Request | | | 194 (1)|--------------------->|(2) | | 195 | | | | 196 | |Binding_Request | | 197 | |------------------------------------->| 198 | | | | 199 | | | Binding_Response | 200 | | |<-----------------|(3) 201 | | Binding_Response | | 202 |<-----------------------------------------|(4) | 203 |(5) | | | 205 DISCUSS example flow 207 1. Alice creates a Binding Request, adds STREAM-TYPE, BANDWIDTH- 208 USAGE, STREAM-PRIORITY attributes before the INTEGRITY attribute 209 and a single null NETWORK-STATUS attribute after the INTEGRITY 210 attribute. 212 2. Router1 inspects the STUN Request message and reads any STREAM- 213 TYPE, BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and the 214 information they contain. It then updates the NETWORK-STATUS 215 attribute with any information the router have. It then forwards 216 the request. 218 3. Bob processes the STUN Request. When Bob builds the response, it 219 copies the NETWORK-STATUS attribute into the STUN Response before 220 the INTEGRITY check and adds new null NETWORK-STATUS attribute 221 after the INTEGRITY attribute. Bob then transmits the message. 223 4. Router2 (first DISCUSS network element for the downstream 224 direction) inspects the Response message, reads the STREAM-TYPE, 225 BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and MAY alter the 226 NETWORK-STATUS attribute located after the INTEGRITY attribute. 227 It then transmits the message. 229 5. When Alice receives the STUN Response, she can extract the 230 STREAM-TYPE, BANDWIDTH-USAGE, or STREAM-PRIORITY attributes and 231 the two NETWORK-STATUS attributes to get a complete picture of 232 what the remote agent is sending and how the status of both the 233 upstream and downstream path. 235 3. Network Processing 237 This section describes the processing of DISCUSS packets by network 238 devices. 240 3.1. Packet Processing by Network Device 242 Network devices are said to support DISCUSS if they perform 243 inspection of packets being forward or switched in order to identify 244 an DISCUSS STUN packet. These devices will also be able to read/ 245 write STUN attributes to/from this packet. It is not required that 246 every network device in the path support DISCUSS. It is expected 247 that DISCUSS will have the most value being implemented at certain 248 points in the network (PIN's) such as WAN edge devices, wireless 249 access devices, and Internet gateways. 251 Network devices that support DISCUSS MAY utilize the information 252 provided by the application in the STUN attributes to modify their 253 behavior. These include the attributes defined in this document with 254 the exception of the NETWORK-STATUS attribute. The NETWORK-STATUS 255 attribute SHOULD NOT be used by the DISCUSS capable network device to 256 modify its behavior. The intent of the NETWORK-STATUS attribute is 257 for the application to modify its behavior. 259 If the NETWORK-STATUS attributes exists in a DISCUSS packet after an 260 INTEGRITY attribute, the DISCUSS capable network device MUST process 261 it as described in this section. NETWORK-STATUS attributes that 262 exist before the INTEGRITY attribute MUST NOT be modified by the 263 network device. The modifications to the NETWORK-STATUS attribute 264 are: 266 o Update the Node Cnt field in the attribute. The device SHALL 267 increment this field by one unless it is at its maximum 268 (saturated) value. If the field is at its maximum value, the 269 device SHALL NOT modify this field. 271 o Overwrite the attribute CS bit if the value at this device is 272 "worst" than the current value. In other words, only write to 273 this bit if the device is experiencing congestion on relevant 274 queues/interfaces for this flow AND the current value of this 275 field is 0 (Off). 277 The determination of congestion at a device is out of the scope of 278 this document. Setting of CS bit to On by the device is meant to 279 provide direct feedback to the application of potential or current 280 loss of packets in its flow (s). The application can then react to 281 this indication by altering its encoding of information in the packet 282 to deal with congestion/packet loss, e.g. reduce its encoding rate or 283 switch to embedded encoding. Devices SHOULD ensure that the DISCUSS 284 capable applications that do react to congestion notification by 285 reducing their transmission rate be treated properly to ensure 286 fairness with non reacting applications (i.e. ensure fairness for 287 well behaving applications). 289 The DISCUSS STUN packet SHOULD experience minimal extra processing 290 delay through the DISCUSS capable network device relative to non- 291 DISCUSS packets in the flow. The DISCUSS STUN packet MAY be placed 292 out of order in the packet flow, but SHOULD NOT be delayed more than 293 a few packet interval times. 295 3.2. Interaction with DSCP 297 One of the attributes that may be added to the STUN packet by the 298 application is the STREAM-PRIORITY attribute. This attribute 299 indicates the relative priority of streams inside of an application 300 session. This attribute is compatible with the use of DSCP (or other 301 priority markings) at the networking layer as described in this 302 section. 304 Since transport layer markings may be modified by middle boxes or 305 devices in the path or at the interface of the application itself due 306 to the lack of support in the OS network stack, the STREAM-PRIORITY 307 attribute can be used as a mechanism for ensuring proper QoS 308 treatment through multiple domains. DISCUSS capable device may use 309 the STREAM-PRIORITY attribute to remark the DSCP value to the 310 appropriate value. DSCP re-marking based on STREAM-PRIORITY 311 attribute may make sense at certain PIN's, e.g. gateway between 312 network domains (e.g. managed network to/from Internet), access 313 switches in managed network, etc. The translation from the Priority 314 number in the STREAM-PRIORITY attribute to the correct transport 315 layer marking (e.g. DSCP) is implementation specific and out of the 316 scope of this document. 318 [I-D.dhesikan-tsvwg-rtcweb-qos] provides the recommended DSCP values 319 for webrtc enabled browsers to use for various classes of traffic. 321 4. Interaction with ICE 323 An ICE connectivity check is performed by sending a STUN Binding 324 indication. Prior to sending the agent can add one STREAM-TYPE 325 attribute. If added, only one MUST be added. This is to avoid 326 unnecessary large STUN packets during the connectivity checks. If 327 the connectivity check is sent on a 5-tuple that multiplexes 328 different types of media and more detailed information wants to be 329 signalled it should be done after the connectivity check phase is 330 finished. 332 This limits the information the STUN messages are able to convey 333 during the connectivity checks, but also avoids adding network 334 confusion with BANDWIDTH-USAGE attributes describing different paths 335 that never going to be utilized. 337 [[Q4: Problem with consent freshness if not based on STUN. 338 --palmarti]] 340 5. Multiplexed Streams 342 In some scenarios a 5-tuple can be used to transport several media 343 streams. BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] describes 344 such a mechanism. 346 At times, the different "streams" carried in this bundle require very 347 different treatment from the network, including the ability to 348 prioritize some of these "streams" over others. For example, the 349 application my bundle video and audio in the same 5-tuple flow, but 350 would like the network to prioritize the delivery of audio over that 351 of video in the case of congestion. Another example is the use of 352 embedded (or scalable) coding for video. Per RFC 6190 [RFC6190], 353 using Multi-session Transmission (MST) the layers are transported in 354 seperate sub-flows (RTP sessions) within the bundled flow. Using the 355 STREAM-TYPE attribute with the extension to identify the sub-flow and 356 its priority would allow network elements, if capable, to provide 357 differentiated services even in the case of bundling. 359 For RTP/SRTP based flows, the existence and attributes for sub-flows 360 in the flow MAY be indicated by the application via the SUB-STREAM- 361 xxx attributes. These attributes MUST only be included if the 362 equivalent STREAM-xxxx attributes are included. It is expected that 363 only a sub-set of network elements representing bottleneck Points in 364 Network (PIN) will be able to inspect the higher layer protocols to 365 differentiate sub-flows, so it is important to describe the agregate 366 flow, and then the sub-flows. The SUB-STREAM-xxxx attributes are 367 similar to the corresponding STREAM-xxxx attributes with the addition 368 of the application layer identifier field. For the case of RTP/SRTP, 369 this field is the SSRC assigned to the flow. Note that this will 370 only work for non-header encrypted SRTP. 372 When describing the aggregate stream with a STREAM-TYPE attribute 373 there are two possibilities to describe the streams that are 374 multiplexed. Adding one attribute for each type (Audio, Video,++), 375 or to save a few bits on the wire it is also possible to construct 376 the STREAM-TYPE so a one type value describes several types. For 377 example audio have the value of 1 and application data have the value 378 of 4. If the STREAM_TYPE value is set to 5 the only combination that 379 gives that is audio and application data. As previously discussed, 380 in the case of bundling, the agregate stream attribute MUST be 381 included before the optional sub-stream attributes 383 The other attributes BANDWIDTH-USAGE, STREAM-PRIORITY and NETWORK- 384 STATUS SHOULD only be added once as they describe the behavior of the 385 5-tuple and not individual streams. 387 6. New STUN attributes 389 This STUN extension defines the following new attributes: 391 0xXXX0: STREAM-TYPE 392 0xXXX1: BANDWIDTH-USAGE 393 0xXXX2: STREAM-PRIORITY 394 0xXXX8: SUB-STREAM-TYPE 395 0xXXX9: SUB-BANDWIDTH-USAGE 396 0xXXXA: SUB-STREAM-PRIORITY 397 0xYYYY: NETWORK-STATUS 399 6.1. STREAM-TYPE 401 This attribute have a length that are multiples of 4 (32) so no 402 padding is necessary. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | TYPE | Interactivity | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 1: STREAM TYPE Attribute 412 TYPE: STREAM TYPE is a 16 bit value defined in Figure 2 below 413 describing the flow. 415 0x0001 Audio 416 0x0002 Video 417 0x0004 Application Data 418 0x0008 Other 420 Figure 2: STREAM Types 422 Interactivity: Is a 8 bit value defined in Figure 3 below describing 423 the flow. 425 0x00 Undef 426 0x01 Stream (Broadcast? Oneway?) 427 0x02 Interactive 429 Figure 3: Interactivity Types 431 It is possible to combine the stream types if a stream contains more 432 than one type. 434 If a 5-tuple is used to send both a audio and video stream, the 435 stream type can be set to 0x0006. This can be useful if the 436 application wants to hint that the 5-tuple contains several streams, 437 This is useful if the attribute is added to STUN binding requests 438 during ICE connectivity checks. If more information regarding 439 multiplexed streams is needed it is possible to add more than one 440 attribute to a STUN message (See section ??). This can be done to 441 STUN messages that are being sent after the connectivity check phase 442 is finished (Keep-alive, consent freshness). During this phase the 443 added size of the STUN messages pose no security threat. 445 6.2. BANDWIDTH-USAGE 447 This attribute have a length that are multiples of 4 (32) so no 448 padding is necessary. 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | AVERAGE (kbps) | MAX (kbps) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 Figure 4: BANDWIDTH USAGE Attribute 458 AVERAGE: Expected sustained bandwidth usage for this stream. Note 459 that for elastic types of streams like video, sudden large 460 movements in the picture my lead to this value being inaccurate. 462 MAX: The maximum bandwidth usage for this stream. If the sustained 463 and max value differ greatly it might be safe to assume that an 464 elastic encoder is in use. (Would it be useful to say something 465 about expected BURST lengths?) 467 6.3. STREAM-PRIORITY 469 This attribute have a length that are multiples of 4 (32) so no 470 padding is necessary. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Priority |D| TBD | Stream IDX | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Session ID | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 5: STREAM PRIORITY Attribute 482 Priority: Describes this streams priority among other streams coming 483 from this endpoint/application (With same session ID). Values 484 range from 255 (0xFF) to 0. 486 D: Delay sensitive. The application can set this bit as a hint to 487 the network element that the stream is delay sensitive. (Unsure 488 if this is useful) 490 Stream IDX: Application can choose set this to ease debugging in the 491 network. A reasonable value can foe example be the index have in 492 the SDP. 494 Session ID: Identification to distinguish what session this stream 495 is part of. This MUST have the same value for all the media 496 streams the application wants to give differentiated services. 497 (Note that this ID may overlap with other streams that originates 498 from a different IP address. The network element MUST only 499 prioritize among streams with the same Session Id originating from 500 the same IP) 502 6.4. NETWORK-STATUS 504 This attribute have a length that are multiples of 4 (32) so no 505 padding is necessary. The values are kept in the same attribute to 506 make it easier for the network element to process it. Only one 507 attribute, with static placement of the fields. [[Q5: Does this 508 matter? Could we have several attributes with possible different 509 ordering without any problem for the network element? --palmarti]] 511 This attribute MUST be added after any INTEGRITY attribute in the 512 STUN message. Values in this attribute can be updated along the 513 network path by nodes that are not able to regenerate a correct 514 INTEGRITY attribute. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |C| Flags | Node Cnt | TBD | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Up MAX Bitrate (kbps) | Down MAX Bitrate (kbps) | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 6: NETWORK-STATUS Attribute 526 C: Congestion Status. This bit is set to indicate that there is 527 congestion at the network device's relevant queues/interfaces for 528 this flow. The network element should set this bit to 1 (On) if 529 it is experiencing congestion. This bit is set to 0 (off) when 530 the attribute is created by the application. The application that 531 sees this bit set might act on it by doing some rate adaption or 532 similar action. 534 Flags: 7 more bits available for flags. 536 Node Cnt: Numbers of nodes that supports DISCUSS in the network 537 path. Any router on the path that understands DISCUSS should 538 increase this number. This field is set to 0 when the attribute 539 is created by the application. 541 TBD: 16 more bits available for useful info. 543 Up MAX Bitrate: Available MAX bit-rate the router is able to handle 544 for the 5-tuple in the UP direction. (Same direction as the 545 packet is moving) 547 Down MAX Bitrate: Available MAX bit-rate the router is able to 548 handle for the 5-tuple in the DOWN direction. (Opposite direction 549 as the packet is moving) 551 6.5. SUB-STREAM-TYPE, SUB-STREAM-PRIORITY 553 These attributes are identical format to their aggregate stream 554 version (STREAM-TYPE, STREAM-PRIORITY) with the addition of a 555 transport layer identifier. The transport layer identifier is a 64 556 bit field which contains the unique identifier of the sub-stream for 557 which the attribute applies. 559 Currently, only RTP transport is supported with the identifier being 560 the SSRC currently used by the sub-stream. 562 7. IANA Considerations 564 IANA is requested to add the following attributes to the STUN 565 attribute registry [iana-stun], 567 o 0xXXX0: STREAM-TYPE (0xXXX0, in the comprehension-optional range) 569 o 0xXXX1: BANDWIDTH-USAGE (0xXXX1, in the comprehension-optional 570 range) 572 o 0xXXX2: STREAM-PRIORITY (0xXXX2, in the comprehension-optional 573 range) 575 o 0xYYYY: NETWORK-STATUS (0xYYYY, in the comprehension-optional 576 range) 578 8. Implementation Status 580 [Note to RFC Editor: Please remove this section and reference to 581 [RFC6982] prior to publication.] 583 This section records the status of known implementations of the 584 protocol defined by this specification at the time of posting of this 585 Internet-Draft, and is based on a proposal described in [RFC6982]. 586 The description of implementations in this section is intended to 587 assist the IETF in its decision processes in progressing drafts to 588 RFCs. Please note that the listing of any individual implementation 589 here does not imply endorsement by the IETF. Furthermore, no effort 590 has been spent to verify the information presented here that was 591 supplied by IETF contributors. This is not intended as, and must not 592 be construed to be, a catalog of available implementations or their 593 features. Readers are advised to note that other implementations may 594 exist. 596 According to [RFC6982], "this will allow reviewers and working groups 597 to assign due consideration to documents that have the benefit of 598 running code, which may serve as evidence of valuable experimentation 599 and feedback that have made the implemented protocols more mature. 600 It is up to the individual working groups to use this information as 601 they see fit". 603 8.1. NATtools 605 Organization: Cisco 607 Description: Open-Source ICE, TURN and STUN implementation. 609 Implementation: https://github.com/cisco/NATTools 610 Level of maturity: Code is stable. Tests being run to learn more 611 on how to leverage the information shared between client and 612 network. 614 Coverage: Implements the DISCUSS attributes 616 Licensing: BSD 618 Implementation experience: Draft was implemented with internal 619 video test clients. Wireless access point implemented STUN 620 detection in the media path and acted on the information in the 621 DISCUSS attributes. After running tests in different congestion 622 scenarios it is clear that sharing information between endpoint 623 and network can help with congestion and end-user experience. 624 This approach required little effort to implement on the client 625 side. 627 Contact: Paal-Erik Martinsen . 629 9. Security Considerations 631 Due to the security implications described in 632 [I-D.thomson-mmusic-ice-webrtc] where large STUN packet are used to 633 amplify an attack, keeping the added STUN attributes small is a 634 important design consideration. 636 To avoid unwanted information leakage the new defined STUN attributes 637 defined in this draft are strictly defined. No more information 638 should be leaked that an on-path device could learn by observing the 639 stream over time or do some deep packet analysis. This draft would 640 benefit from more discussions on this topic. 642 It is also worth noticing that the STUN attributes defined should be 643 treated as hints, and more work is needed regarding how to deal with 644 misbehaving clients or network devices. 646 10. Acknowledgements 648 Authors would like to thank Dan Wing, Anca Zamfir, Jon Snyder and 649 Cullen Jennings for their comments and review. 651 11. References 653 11.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, March 1997. 658 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 659 "Definition of the Differentiated Services Field (DS 660 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 661 1998. 663 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 664 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 665 October 2008. 667 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 668 (ICE): A Protocol for Network Address Translator (NAT) 669 Traversal for Offer/Answer Protocols", RFC 5245, April 670 2010. 672 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 673 "RTP Payload Format for Scalable Video Coding", RFC 6190, 674 May 2011. 676 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 677 Code: The Implementation Status Section", RFC 6982, July 678 2013. 680 11.2. Informational References 682 [I-D.ietf-rtcweb-security-arch] 683 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 684 rtcweb-security-arch-09 (work in progress), February 2014. 686 [I-D.thomson-mmusic-ice-webrtc] 687 Thomson, M., "Using Interactive Connectivity Establishment 688 (ICE) in Web Real-Time Communications (WebRTC)", draft- 689 thomson-mmusic-ice-webrtc-01 (work in progress), October 690 2013. 692 [I-D.dhesikan-tsvwg-rtcweb-qos] 693 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 694 other packet markings for RTCWeb QoS", draft-dhesikan- 695 tsvwg-rtcweb-qos-06 (work in progress), March 2014. 697 [I-D.ietf-mmusic-sdp-bundle-negotiation] 698 Holmberg, C., Alvestrand, H., and C. Jennings, 699 "Multiplexing Negotiation Using Session Description 700 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 701 bundle-negotiation-05 (work in progress), October 2013. 703 [I-D.eggert-tsvwg-rfc5405bis] 704 Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 705 Guidelines", draft-eggert-tsvwg-rfc5405bis-01 (work in 706 progress), June 2014. 708 [iana-stun] 709 IANA, , "IANA: STUN Attributes", April 2011, 710 . 713 Authors' Addresses 715 Paal-Erik Martinsen 716 Cisco Systems, Inc. 717 Philip Pedersens vei 20 718 Lysaker, Akershus 1366 719 Norway 721 Email: palmarti@cisco.com 723 Herb Wildfeuer 724 Cisco Systems, Inc. 725 821 Alder Drive 726 Milpitas, California 95035 727 United States 729 Email: hwildfeu@cisco.com