idnits 2.17.1 draft-martinsen-tram-turnbandwidthprobe-00.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 (May 29, 2015) is 3254 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) == Outdated reference: A later version (-01) exists of draft-martinsen-tram-stuntrace-00 == Outdated reference: A later version (-01) exists of draft-petithuguenin-tram-stun-pmtud-00 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Martinsen 3 Internet-Draft T. Andersen 4 Intended status: Informational G. Salgueiro 5 Expires: November 30, 2015 Cisco 6 M. Petit-Huguenin 7 Impedance Mismatch 8 May 29, 2015 10 Traversal Using Relays around NAT (TURN) Bandwidth Probe 11 draft-martinsen-tram-turnbandwidthprobe-00 13 Abstract 15 Performing pre-call probing to discover a reasonable value for the 16 available bandwidth, is useful information that can be utilized by 17 bandwidth sensitive or bandwidth intensive network devices (e.g., 18 video encoders). The method described herein is intended to produce 19 an initial bandwidth value. Applications using this mechanism should 20 also employ appropriate rate adaptation techniques. In addition to 21 bandwidth, latency and bufferbloat can also be measured. No 22 modification is needed on the server side. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 30, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 60 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 61 4. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 4 62 4.1. UDP Procedures . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. TCP Procedures . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. Sending Data to Measure Available Bandwidth and 65 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. New STUN Attribute . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Cisco Collaboration Endpoint (CE) . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 10.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 When Interactive Connectivity Establishment (ICE) [RFC5245] and 81 Traversal Using Relays around NAT (TURN) [RFC5766] are used by an 82 endpoint as a firewall/NAT traversal mechanism, the TURN relay can 83 also be used to measure bandwidth and latency prior to call setup. 85 In normal ICE behavior the client first sends a message (allocate 86 request) to the TURN server to allocate a RELAY address. This 87 address can be used by the endpoint to receive media from other 88 endpoints. The media stream is then received by the TURN server and 89 then relayed back to the endpoint behind the firewall/NAT. For 90 security reasons the endpoint must first set the correct permissions 91 on the TURN server to only allow media from remote participants it 92 wants to communicate with (i.e., addresses taken from the Session 93 Initiation Protocol (SIP) [RFC3261] Session Description Protocol 94 (SDP) [RFC4566] offer/answer exchange [RFC3264]) . The endpoint will 95 also learn its reflexive address on the firewall/NAT when talking to 96 the TURN server. 98 Combining this with a TCP transfer on the same TURN server can be 99 used to also measure bufferbloat, an important metric for multimedia 100 applications. 102 Note that only the maximum bandwidth, maximum latency and maximum 103 bufferbloat of the aggregation of both uplink and downlink can be 104 measured. It is not possible with this technique to get the metrics 105 of only one. For most multimedia applications using TURN that is not 106 an issue as they are generally symmetrical, but some other use cases 107 (like conferencing) may need other techniques to measure these 108 metrics separately. 110 No modification to the TURN server is necessary. 112 2. Notational Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Overview of Operation 120 Prior to the call (upon registering with the call control server, 121 receiving a configuration, loading application, or a similar event) 122 the endpoint can measure bandwidth and latency between the endpoint 123 and the TURN server. 125 *Relay 126 +------+ 127 *Rflx -<-| TURN |<-\ 128 /-------\ +-----+ / +------+ | 129 | |--<--| NAT |-<--- | 130 | Alice |--->-|-->--|->-->----->----->--/ 131 \-------/ +-----+ 133 Figure 1 135 The agent allocates a TURN Relay port on its designated TURN server 136 as described in TURN RFC [RFC5766]. In the process the agent will 137 also learn the outermost NAT address. This is called a reflexive 138 address (Rflx). For more information see Section 2.1 of the TURN RFC 139 regarding candidate gathering in ICE. 141 The agent must set the permissions on the allocated RELAY port as 142 described in Section 8 of the TURN RFC to allow traffic from the 143 discovered reflexive address. 145 When sending packets to the allocated RELAY port on the TURN server, 146 the packets will be forwarded back to the agent in a data indication 147 packet. See Section 10 of the TURN RFC for details on how the TURN 148 server can relay packets back to the allocating agent. Available 149 bandwidth can be measured by sending varying number of packets and 150 detecting the amount of packet loss. Each packet sent affects both 151 upstream and downstream links. 153 To make it easier to calculate the available bandwidth a TIMESTAMP 154 attribute is defined in this document (see Section Section 6.1) and 155 can be added to the Session Traversal Utilities for NAT (STUN) 156 [RFC5389] probe packets. The PADDING attribute from the NAT Behavior 157 Discovery Using STUN RFC [RFC5780] can be used to vary the packet 158 size. 160 Discovering the MTU and network path (using the STUN-PMTUD 161 [I-D.petithuguenin-tram-stun-pmtud] and STUN Traceroute 162 [I-D.martinsen-tram-stuntrace] mechanisms) can also be performed when 163 probing for the bandwidth available between the client and the TURN 164 server. 166 4. Base Protocol Procedures 168 In order to perform the STUN bandwidth probing mechanism described in 169 this document, the client MUST take the following general steps 170 (explained in greater detail in the following subsections). 172 o Allocate TURN RELAY address 174 o Set correct permissions on the allocated TURN RELAY address 176 o Originating client sends data to itself through the TURN server 177 and measures bandwidth throughput and latency 179 When initiating a bandwidth probe it is important to not do so when a 180 device powers up or some similar initiating events. If a power 181 failure has happened and all devices within an area are rebooted 182 concurrently the bandwidth probing of all the devices can have a 183 DDOS-like effect. Measures should be taken to avoid such scenarios 184 (e.g., random delays to initiate bandwidth probing, etc). 186 Discovery of the TURN server as well as the determination of what 187 TURN server to uses is entirely at the discretion of the client and 188 outside the scope of this document. A client MUST be prepared to be 189 redirected to another TURN server if it receives an ALTERNATE-SERVER 190 response. 192 While allocating the TURN RELAY port the client will learn its 193 outermost NAT address or reflexive address. This is the address the 194 TURN server will receive the bandwidth probing packets from. 196 The bandwidth mechanism can use either a UDP transport or a TCP. 197 Secure transports (i.e. TLS or DTLS) may be used to discover if an 198 intermediary network element tries to process flows differently when 199 they are secured. 201 4.1. UDP Procedures 203 The client allocates a TURN RELAY port as described in the TURN RFC. 204 The client then use a CreatePermission request with the obtained 205 reflexive address encoded in a XOR-PEER-ADDRESS attribute as 206 described in Section 9.1 of the TURN RFC. 208 It is recommended to create a TURN channel as soon as possible to 209 lower the overhead of the packets exchanged. 211 If the transport address used to send the UDP packets to the TURN 212 relay is identical to the transport address used to create the TURN 213 allocation, then a TURN Channel can be created immediately by using 214 the reflexive transport address learned during the Allocate. 216 If not, the TURN Channel can be created as soon the first Data 217 indication is received. 219 The client can then send UDP packets to the relay transport address 220 and receive then over the TURN Channel. 222 Immediately after this the client can send UDP packets over the TURN 223 channel and receive them directly, as an additional way of averaging 224 the impact of the difference of encapsulation for the packets. Note 225 that the client still need to periodically send packets over the TURN 226 Channel to persist eventual NAT bindings. 228 Note that the client cannot use a TCP transport to the server with a 229 UDP allocation because there would be no way to retrieve the UDP 230 reflexive address for the CreatePermission request. 232 4.2. TCP Procedures 234 The client allocates a TURN RELAY port as described in TURN 235 Extensions for TCP Allocations [RFC6062]. The client then use a 236 CreatePermission request with the obtained reflexive address encoded 237 in a XOR-PEER-ADDRESS attribute as described in Section 9.1 of the 238 TURN RFC. 240 The client then establishes a TCP connection to the relay transport 241 address. The client will receive a ConnectAttempt indication that 242 will trigger a new TCP connection to the TURN server, and the sending 243 of a ConnectBind. 245 After completion of this procedure, data sent over the direct TCP 246 connection will be received over the bound TURN connection, and vice- 247 versa, although there is no difference of overhead in that case. 249 4.3. Sending Data to Measure Available Bandwidth and Latency 251 The specific calculation and measurement of the bandwidth is client 252 dependent and implementation-specific and is thus outside the scope 253 of this document. 255 If the client want to use STUN packets as the basis for the probing 256 packets, then a TIMESTAMP attribute is defined in this specification 257 (see Section Section 6.1) to simplify measurement of round-trip time 258 (RTT) and available bandwidth. A PADDING attribute is already 259 defined in RFC 5780 [RFC5780] that makes it easy to vary the size of 260 the STUN probing packet. 262 The probing packet will be sent upstream to the TURN server and later 263 received downstream from the TURN server. Available bandwidth would 264 typically be determined to be the lowest of the bandwidth values 265 calculated for the upstream and downstream directions. 267 If the RTP [RFC3550] loop-back mechanism described in RFC 6849 268 [RFC6849] is in use the method described here can extend the use- 269 cases mentioned in RFC6849 Section 1.1 to enable the "loopback 270 source" and "loopback mirror" to be running on the same device. 271 Using RTP would permit to reuse the standards RTP tools for 272 calculating latency, jitter and other metrics. It may also permit to 273 get better results if some intermediary network element has 274 preferential treatment for media packets. 276 The client should take care to reuse the same congestion control 277 mechanisms it uses when sending media to avoid unnecessary strain on 278 the network. 280 5. IANA Considerations 282 This specification defines a new STUN attribute. IANA added this new 283 attribute to the STUN Attributes sub-registry of the Session 284 Traversal Utilities for NAT (STUN) Parameters registry. (This is 285 still an ID draft so not assignment yet) 287 6. New STUN Attribute 289 This STUN extension defines the following new attribute: 291 0xXXX0: TIMESTAMP 293 6.1. TIMESTAMP 295 The TIMESTAMP attribute has a length of 80 bits. Padding is needed 296 to hit the required 32 bit STUN attribute boundary. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | seconds (32bit) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | microseconds (32bit) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | seq (16bit) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 2: TIMESTAMP Attribute 310 The seconds and microseconds fields reflect what would be returned in 311 the struct timeval when calling getTimeofDay() function. Note that 312 the size of that struct may vary based on platform, but 32 bits is 313 more than sufficient to obtain the required accuracy for the feature 314 described in this document. It is RECOMMENDED to initialize these 315 fields with a random value that later can be subtracted to get the 316 right timing. 318 The seq field is a 16 bit sequence number. It is increased by one 319 for each bandwidth probe STUN packet sent. It is RECOMMENDED to 320 choose a random starting value. 322 7. Implementation Status 324 [[Note to RFC Editor: Please remove this section and the reference to 325 [RFC6982] before publication.]] 327 This section records the status of known implementations of the 328 protocol defined by this specification at the time of posting of this 329 Internet-Draft, and is based on a proposal described in RFC 6982 331 [RFC6982]. The description of implementations in this section is 332 intended to assist the IETF in its decision processes in progressing 333 drafts to RFCs. Please note that the listing of any individual 334 implementation here does not imply endorsement by the IETF. 335 Furthermore, no effort has been spent to verify the information 336 presented here that was supplied by IETF contributors. This is not 337 intended as, and must not be construed to be, a catalog of available 338 implementations or their features. Readers are advised to note that 339 other implementations may exist. 341 According to RFC 6982 [RFC6982], "this will allow reviewers and 342 working groups to assign due consideration to documents that have the 343 benefit of running code, which may serve as evidence of valuable 344 experimentation and feedback that have made the implemented protocols 345 more mature. It is up to the individual working groups to use this 346 information as they see fit" 348 7.1. Cisco Collaboration Endpoint (CE) 350 Organization: Cisco 352 Name: Cisco Collaboration Endpoints (CE) software 354 Description: Hard video endpoint part of the Cisco collaboration 355 portfolio 357 Level of maturity: In released products 359 Coverage Implementation of base procedures of the functionality 360 described in this specification 362 Licensing: Proprietary 364 Implementation experience: Straight forward, but implementation was 365 don prior to writing up the spec 367 Contact: Paal-Erik Martinsen (palmarti@cisco.com) 369 8. Security Considerations 371 When setting permissions this is done on a per IP address basis. 372 Port number is not part of the permission. This is necessary 373 limitation of the TURN protocol [RFC5766] and not something 374 introduced by this specification. 376 To prevent replay attacks or other attacks that rely on static 377 sequence number initialization it is important to randomly initialize 378 the seq number in the TIMESTAMP Attribute. Likewise it is important 379 to hide the time information by assigning a random value to the 380 seconds and microseconds fields. That random value can be added and 381 subtracted by the client when sending and receiving packets to get 382 the correct value. This prevents any information leakage regarding 383 time from the client. 385 9. Acknowledgements 387 Thanks to Dan Wing for input. 389 10. References 391 10.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 397 Jacobson, "RTP: A Transport Protocol for Real-Time 398 Applications", STD 64, RFC 3550, July 2003. 400 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 401 (ICE): A Protocol for Network Address Translator (NAT) 402 Traversal for Offer/Answer Protocols", RFC 5245, April 403 2010. 405 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 406 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 407 October 2008. 409 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 410 Relays around NAT (TURN): Relay Extensions to Session 411 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 413 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 414 Using Session Traversal Utilities for NAT (STUN)", RFC 415 5780, May 2010. 417 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 418 around NAT (TURN) Extensions for TCP Allocations", RFC 419 6062, November 2010. 421 [RFC6849] Kaplan, H., Hedayat, K., Venna, N., Jones, P., and N. 422 Stratton, "An Extension to the Session Description 423 Protocol (SDP) and Real-time Transport Protocol (RTP) for 424 Media Loopback", RFC 6849, February 2013. 426 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 427 Code: The Implementation Status Section", RFC 6982, July 428 2013. 430 10.2. Informative References 432 [I-D.martinsen-tram-stuntrace] 433 Martinsen, P. and D. Wing, "STUN Traceroute", draft- 434 martinsen-tram-stuntrace-00 (work in progress), February 435 2015. 437 [I-D.petithuguenin-tram-stun-pmtud] 438 Petit-Huguenin, M., "Path MTU Discovery Using Session 439 Traversal Utilities for NAT (STUN)", draft-petithuguenin- 440 tram-stun-pmtud-00 (work in progress), January 2015. 442 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 443 A., Peterson, J., Sparks, R., Handley, M., and E. 444 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 445 June 2002. 447 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 448 with Session Description Protocol (SDP)", RFC 3264, June 449 2002. 451 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 452 Description Protocol", RFC 4566, July 2006. 454 Authors' Addresses 456 Paal-Erik Martinsen 457 Cisco Systems, Inc. 458 Philip Pedersens Vei 22 459 Lysaker, Akershus 1325 460 Norway 462 Email: palmarti@cisco.com 464 Trond Andersen 465 Cisco Systems, Inc. 466 Philip Pedersens Vei 22 467 Lysaker, Akershus 1325 468 Norway 470 Email: trondand@cisco.com 471 Gonzalo Salgueiro 472 Cisco Systems, Inc. 473 7200-12 Kit Creek Road 474 Research Triangle Park, NC 27709 475 US 477 Email: gsalguei@cisco.com 479 Marc Petit-Huguenin 480 Impedance Mismatch 482 Email: marc@petit-huguenin.org