idnits 2.17.1 draft-reddy-tram-stun-path-data-01.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 -- The document date (January 20, 2015) is 3383 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 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-mprtp-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM T. Reddy 3 Internet-Draft D. Wing 4 Intended status: Standards Track P. Martinsen 5 Expires: July 24, 2015 Cisco 6 V. Singh 7 callstats.io 8 January 20, 2015 10 Discovery of path characteristics using STUN 11 draft-reddy-tram-stun-path-data-01 13 Abstract 15 A host with multiple interfaces needs to choose the best interface 16 for communication. Oftentimes, this decision is based on a static 17 configuration and does not consider the path characteristics, which 18 may affect the user experience. 20 This document describes a mechanism for an endpoint to discover the 21 path characteristics using Session Traversal Utilities for NAT (STUN) 22 messages. The measurement information can then be used to influence 23 the endpoint's Interactive Connectivity Establishment (ICE) candidate 24 pair selection algorithm. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 24, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 62 3. Path characteristics determination mechanism . . . . . . . . 3 63 3.1. The PATH-CHARACTERISTIC attribute in request . . . . . . 4 64 3.2. The PATH-CHARACTERISTIC attribute in response . . . . . . 5 65 3.3. Example Operation . . . . . . . . . . . . . . . . . . . . 6 66 4. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The ICE [RFC5245] mechanism uses a prioritization formula to order 78 the candidate pairs and perform connectivity checks, in which the 79 most preferred address pairs are tested first and when a sufficiently 80 good pair is discovered, that pair is used for communications and 81 further connectivity tests are stopped. This approach works well for 82 an endpoint with a single interface, but is too simplistic for 83 endpoints with multiple interfaces, wherein a candidate pair with a 84 lower priority might infact have better path characteristics (e.g., 85 round-trip time, loss, etc.). The ICE connectivity checks can assist 86 in measuring the path characteristics, but as currently defined, the 87 STUN responses to re-transmitted requests are indistinguishable from 88 each other. 90 This draft extends STUN [RFC5389] to distinguish STUN responses to 91 re-transmitted requests and this assists the client in determining 92 the path characteristics like round-trip time (RTT) and packet loss 93 in each direction between endpoints. These metrics can then be used 94 by the controlling agent to influence the ICE candidate pair 95 priorities. 97 The PATH-CHARACTERISTICS attribute introduced in this specification 98 can be used in ICE connectivity checks (STUN Binding request and 99 response). When multiple TURN servers are discovered then this new 100 attribute can also be used with Allocate request to determine the 101 priority amongst the relayed candidates. 103 This specification can be used with the regular nomination procedure 104 defined in ICE, wherein ICE connectivity checks need to be performed 105 on all or subset of the chosen candidate pairs. Finalizing an 106 approporiate candidate pair based on the path characteristics depends 107 on the number of candidate pairs, time interval for pacing ICE 108 connectivity checks and the corresponding RTO values. By picking 109 appropriate values the endpoints will not observe any noticeable 110 impact to the media setup time. 112 TODO: Add details of ICE continous nomination procedure discussed in 113 mmusic WG which allows picking better candidate pairs as and when 114 they appear. http://juberti.github.io/draughts/nombis/draft-uberti- 115 mmusic-nombis.html explains simplifying and improving the procedures 116 for candidate nomination in ICE to make dynamic decisions. 118 2. Notational Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 This note uses terminology defined in ICE [RFC5245] and STUN 125 [RFC5389]. 127 3. Path characteristics determination mechanism 129 When multiple paths are available for communication, the endpoint 130 sends ICE connectivity checks across each path (candidate pair) and 131 perhaps chooses the path with the lowest round trip time. Choosing 132 the path with the lowest round trip time is a reasonable approach, 133 but re-transmits can cause an otherwise-good path to appear flawed. 134 However, STUN's retransmission algorithm [RFC5389] cannot determine 135 the round-trip time (RTT) if a STUN request packet is re-transmitted, 136 because each request and retransmission packet is identical. 137 Further, several STUN requests may be sent before the connectivity 138 between candidate pairs is ascertained (see Section 16 of [RFC5245]). 139 To resolve the issue of identical request and response packets in a 140 STUN transaction, this document changes that retransmission behavior 141 for idempotent packets. In addition to determining RTT, it is also 142 desirable to detect which path direction caused packet loss, 143 described as "bi-directional path characteristics," below. This is 144 achieved by defining a new STUN attribute and requires compliant STUN 145 (TURN, ICE) endpoints to count request packets. 147 This specification defines a new comprehension-optional STUN 148 attribute PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN 149 Type TBD-CA. This type is in the comprehension-optional range, which 150 means that STUN agents can safely ignore the attribute if they do not 151 understand it. 153 If a client wishes to determine the path characteristics, it inserts 154 the PATH-CHARACTERISTIC attribute in a STUN request. In the PATH- 155 CHARACTERISTIC attribute client sends the number of times the STUN 156 request is retransmitted with the same Transaction ID. The server 157 would echo back the retransmission count in the response so that 158 client can distinguish STUN responses from the re-transmitted 159 requests. Hence, the endpoint can use the STUN requests and 160 responses to determine the round-trip time (RTT). The server may 161 also convey the number of times it received the request with the same 162 Transaction ID and the number of responses it has sent for the STUN 163 request to the client. Further, this information enables the client 164 to determine packet loss in each direction. 166 3.1. The PATH-CHARACTERISTIC attribute in request 168 The PATH-CHARACTERISTIC attribute in a STUN request takes a 1-byte 169 Value, which means that the Length is 1 and 3 bytes of padding are 170 required after the value (Section 15 of [RFC5389]). When sending a 171 STUN request, the PATH-CHARACTERISTIC attribute allows a client to 172 indicate to the server that it wants to determine path 173 characteristics. If the client receives a STUN response with error 174 code 420 (Unknown Attribute) and PATH-CHARACTERISTIC is listed in the 175 UNKNOWN-ATTRIBUTE attribute of the message, the client SHOULD 176 retransmit the original request without the PATH-CHARACTERISTIC 177 attribute. However this case is not expected to occur, due to the 178 use of the comprehension-optional attribute type. 180 This specification updates one the STUN message structuring rules 181 explained in Section 6 of [RFC5389] that resends of the same request 182 reuse the same transaction ID and are bit-wise identical to the 183 previous request. For idempotent packets the ReTransCnt in the PATH- 184 CHARACTERISTIC attribute will be incremented by 1 for every re- 185 transmission and the re-transmitted STUN request MUST be bit-wise 186 identical to the previous request except for the ReTransCnt value. 188 The format of the value in PATH-CHARACTERISTIC attribute in the 189 request is: 191 0 192 0 1 2 3 4 5 6 7 193 +-+-+-+-+-+-+-+-+ 194 | ReTransCnt | 195 +-+-+-+-+-+-+-+-+ 197 Figure 1: PATH-CHARACTERISTIC attribute in request 199 The field is described below: 201 ReTransCnt: Number of times request is re-transmitted with the same 202 transaction ID to the server. 204 3.2. The PATH-CHARACTERISTIC attribute in response 206 When a server receives a STUN request that includes a PATH- 207 CHARACTERISTIC attribute, it processes the request as per the STUN 208 specification [RFC5389] plus the specific rules mentioned here. The 209 server checks the following: 211 o If the PATH-CHARACTERISTIC attribute is not recognized, ignore the 212 attribute because its type indicates that it is comprehension- 213 optional. This should be the existing behavior as explained in 214 section 3.1 of [RFC5389]. 216 o The server that supports PATH-CHARACTERISTIC attribute MUST echo 217 back ReTransCnt in the response. 219 o If the server is stateless or does not want to remember the 220 transaction ID then it would populate value 0 for the ReqTransCnt 221 and RespTransCnt fields in PATH-CHARACTERISTIC attribute sent in 222 the response .If the server is stateful then it populates 223 ReqTransCnt with the number of times it received the STUN request 224 with the same transaction ID and RespTransCnt with the number of 225 responses it has sent for the STUN request. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| ReTransCnt | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | ReqTransCnt | RespTransCnt | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: PATH-CHARACTERISTIC attribute in response 237 The fields are described below: 239 ReTransCnt: Copied from request. 241 ReqTransCnt: Number of times request is received from the client 242 with the same transaction ID. 244 RespTransCnt: Number of responses sent to the client for the same 245 transaction ID. 247 3.3. Example Operation 249 The operation is described in Figure 3. In the first case, all the 250 requests and responses are received correctly. In the upstream loss 251 case, the first request is lost, but the second one is received 252 correctly, the client on receiving the response notes that while 2 253 requests were sent, only one was received by the server, also the 254 server realizes that the RespTransCnt does not match the ReTransCnt, 255 therefore 1 request was lost. This may also occur at startup in the 256 presence firewalls or NATs that block unsolicited incoming traffic. 257 In the downstream loss case, the responses get lost, client expecting 258 multiple response notes that while the server responded to 3 requests 259 but only 1 response was received. In the both loss case, requests 260 and responses get lost in tandem, the server notes one request packet 261 was not received, while the client expecting 3 responses received 262 only one, it notes that one request and response packets were lost. 264 Normal | Upstream loss | Downstream loss| Both loss | 265 Client Server | Client Server | Client Server | Client Server | 266 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 267 1 1,1 | 1 x | 1 1,1 | 1 x | 268 1,1 | | x | | 269 2 2,2 | 2 2,1 | 2 2,2 | 2 2,1 | 270 2,2 | 2,1 | x | x | 271 3 3,3 | 3 3,2 | 3 3,3 | 3 3,2 | 272 3,3 | 3,2 | 3,3 | 3,2 | 274 Figure 3: Retransmit Operation between client and Server 276 4. Usecases 278 The STUN attribute defined in this specification can be used by 279 applications in the following scenarios: 281 o When an endpoint has multiple interfaces (for example 3G, 4G, 282 WiFi, VPN, etc.), an ICE agent can choose the interfaces for media 283 streams according to the path characteristics. After STUN 284 responses to STUN checks are received, the ICE agent using regular 285 nomination can sort the ICE candidate pairs according to the path 286 characteristics (loss and RTT) discovered using STUN. The 287 controlling agent can then assign the highest priority to 288 candidate pair which best fulfills the desired path 289 characteristics. However, it should be noted that the path 290 capacity or throughput is not determined by these STUN checks. If 291 an endpoint needs to pick paths based on capacity, it would have 292 to send media on those paths. 294 o When a host has multiple interfaces available an MPRTP 295 [I-D.ietf-avtcore-mprtp] application can choose the interfaces for 296 the corresponding subflows according to the path characteristics 297 discovered using STUN. For example, the scheduling algorithm 298 described in [ACM-MPRTP] uses path capacity, latency, and loss 299 rate for choosing the most suitable subset of paths. 301 o The STUN extension proposed in this specification can also be used 302 to choose a TURN server that provides the best user experience 303 (section 3.1 of [I-D.patil-tram-turn-serv-selection]). 305 5. IANA Considerations 307 [Paragraphs in braces should be removed by the RFC Editor upon 308 publication] 310 [The PATH-CHARACTERISTIC attribute requires that IANA allocate a 311 value in the "STUN attributes Registry" from the comprehension- 312 optional range (0x8000-0xFFFF), to be replaced for TBD-CA throughout 313 this document] 315 This document defines the PATH-CHARACTERISTIC STUN attribute, 316 described in Section 3. IANA has allocated the comprehension- 317 optional codepoint TBD-CA for this attribute. 319 6. Security Considerations 321 Security considerations discussed in [RFC5389] are to be taken into 322 account. STUN requires the 96 bits transaction ID to be uniformly 323 and randomly chosen from the interval 0 .. 2**96-1, and be 324 cryptographically strong. This is good enough security against an 325 off-path attacker. An on-path attacker can either inject a fake 326 response or modify the values in PATH-CHARACTERISTIC attribute to 327 mislead the client and server, this attack can be mitigated using 328 STUN authentication. As PATH-CHARACTERISTIC is expected to be used 329 between peers using ICE, and ICE uses STUN short-term credential 330 mechanism the risk of on-path attack influencing the messages is 331 minimal. However, an attacker could corrupt, remove, or delay an ICE 332 request or response, in order to discourage that path from being 333 used. Unauthenticated STUN message MUST NOT include the PATH- 334 CHARACTERISTIC attribute in order to prevent on-path attacker from 335 influencing decision-making. 337 7. Acknowledgements 339 Thanks to Brandon Williams, Simon Perreault, Aijun Wang for valuable 340 inputs and comments. 342 8. References 344 8.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 350 (ICE): A Protocol for Network Address Translator (NAT) 351 Traversal for Offer/Answer Protocols", RFC 5245, April 352 2010. 354 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 355 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 356 October 2008. 358 8.2. Informative References 360 [ACM-MPRTP] 361 Singh, V., Ahsan, S., and J. Ott, "MPRTP: multipath 362 considerations for real-time media", in Proc. of ACM 363 Multimedia Systems, MMSys, 2013. 365 [I-D.ietf-avtcore-mprtp] 366 Singh, V., Karkkainen, T., Ott, J., Ahsan, S., and L. 367 Eggert, "Multipath RTP (MPRTP)", draft-ietf-avtcore- 368 mprtp-00 (work in progress), December 2014. 370 [I-D.patil-tram-turn-serv-selection] 371 Patil, P., Reddy, T., and G. Salgueiro, "Traversal Using 372 Relays around NAT (TURN) Server Selection", draft-patil- 373 tram-turn-serv-selection-00 (work in progress), October 374 2014. 376 Authors' Addresses 377 Tirumaleswar Reddy 378 Cisco Systems, Inc. 379 Cessna Business Park, Varthur Hobli 380 Sarjapur Marathalli Outer Ring Road 381 Bangalore, Karnataka 560103 382 India 384 Email: tireddy@cisco.com 386 Dan Wing 387 Cisco Systems, Inc. 388 170 West Tasman Drive 389 San Jose, California 95134 390 USA 392 Email: dwing@cisco.com 394 Paal-Erik Martinsen 395 Cisco Systems, Inc. 396 Philip Pedersens vei 22 397 Lysaker, Akershus 1325 398 Norway 400 Email: palmarti@cisco.com 402 Varun Singh 403 Nemu Dialogue System Oy 404 Espoo 02235 405 Finland 407 Email: varun@callstats.io