idnits 2.17.1 draft-mcquistin-taps-low-latency-services-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 (October 31, 2016) is 2731 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-hamilton-quic-transport-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group S. McQuistin 3 Internet-Draft C. Perkins 4 Intended status: Informational University of Glasgow 5 Expires: May 4, 2017 M. Fayed 6 University of Stirling 7 October 31, 2016 9 Transport Services for Low-Latency Real-Time Applications 10 draft-mcquistin-taps-low-latency-services-00 12 Abstract 14 This document describes the set of transport services required by 15 low-latency, real-time applications. These services are derived from 16 the needs of the applications, rather than from the current 17 capabilities of the transport layer. An example API, based on the 18 Berkeley Sockets API, is also provided, alongside examples of how the 19 target applications would use the API to access the transport 20 services described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Low-Latency Transport Services . . . . . . . . . . . . . . . 3 58 3. Abstract API . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Socket Setup & Teardown . . . . . . . . . . . . . . . . . 5 60 3.2. Socket Options . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Connection Handling . . . . . . . . . . . . . . . . . . . 6 62 3.4. Timing . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5. Messaging . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Utilities . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.7. Design Assumptions . . . . . . . . . . . . . . . . . . . 8 66 4. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3. Real-Time Multimedia . . . . . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Informative References . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The goal of the TAPS working group is to break down the existing 78 transport layer into a set of transport services, decoupling these 79 from the transport protocols that provide them. As a result, the 80 standardisation of transport services becomes feasible and important. 81 The first phase of this process has been to inspect the existing 82 transport protocols, and determine the services they provide. The 83 next phase, enabled both by the use of transport services and their 84 separation from transport protocols, is to define novel transport 85 services based on the needs of applications. In essence, these 86 services are derived from applications by thinking about what the 87 transport layer would provide to applications if the constraints of 88 the existing transport protocols were not in place. 90 This document considers the transport services required by low- 91 latency applications. This is an important class of applications, 92 not only because it represents a significant portion of Internet 93 traffic, but because it is arguably poorly served by the existing 94 transport layer: the available transport protocols bundle services 95 together in such a way that no one protocol provides all the services 96 required. 98 After detailing the transport services required by these 99 applications, a sample API that provides these services is outlined. 100 This API is then used to demonstrate how applications might make use 101 of the transport services described. 103 This document does not consider how the transport services described 104 map to the transport protocols that might provide them. 106 2. Low-Latency Transport Services 108 The decoupling of transport services from transport protocols allows 109 for the development of novel transport services, based on the needs 110 of applications. This section describes the transport services 111 required by low-latency applications. 113 Timing 114 Timing is the most essential characteristic of the data 115 generated by low-latency applications. Data has a lifetime 116 associated with it: a deadline, relative to the time the data 117 was produced, by which it must be delivered. Once this 118 lifetime has been exceeded, the data is no longer useful to the 119 receiving application. Data lifetimes depend on the latency 120 bounds of the application. Interactive applications, such as 121 telephony, video conferencing, or telepresence, require a low 122 end-to-end latency, ranging from tens to a few hundred 123 milliseconds. Non-interactive applications can accomodate 124 higher latency, with bounds in the order of seconds. 126 There are a number of factors used in predicting if data will 127 arrive within its lifetime: the time between being sent by the 128 application and being sent on the wire, the one-way network 129 delay, and the length of time the data will be buffered at the 130 receiver before being used (the play-out delay). Multimedia 131 applications, which comprise a significant portion of the 132 target application area, have a play-out buffer to reduce the 133 impact of jitter. Estimates for both RTT and play-out delay 134 must be available to the sender. 136 Partial Reliability 137 The combination of a lossy, best-effort network (e.g., IP) 138 layer and support for timing and lifetimes results in the need 139 for a partially reliable service. Given the limitations of 140 forward error correct techniques, there is some probability 141 that packet loss can only be recovered from by retransmitting 142 the lost packet. This introduces potentially unbounded delay, 143 given that retransmissions themselves may be lost. Therefore, 144 timing and fully reliable transport services cannot be provided 145 together -- the reliable delivery of data cannot be guaranteed 146 within a given lifetime. 148 This implies a partial reliability service, where data is 149 delivered reliably only while it is likely to be useful to the 150 receiving application. Once a message has exceeded its 151 lifetime, attempts to transmit it will be abandoned. 153 Dependencies 154 Partial reliability means that not all data that is sent will 155 be received successfully. This means that a dependency 156 management transport service is required. Data must not be 157 sent if it relies upon earlier data that has not been 158 successfully delivered. 160 Messaging 161 Given that not all data will arrive successfully, it is 162 important to maximise the utility of the data that does arrive. 163 Application-level framing [CCR20] allows the application to 164 package data into units that are useful (assuming delivery of 165 their dependencies) to the receiver. The combination of a 166 messaging service (to maintain application data unit 167 boundaries) and a dependency services provides greater utility 168 to applications than a stream-oriented service on lossy 169 networks. To minimise latency, messages are delivered to the 170 application in the order they arrive. Reordering messages into 171 transmission order introduces latency when applied across a 172 lossy IP network; messages may be buffered waiting for earlier 173 messages to be retransmitted. Application-layer protocols, 174 such as RTP, introduce sequencing, allowing applications to 175 reorder messages if required. Introducing order at this layer 176 makes the resultant latency explicit to the application. 178 Multistreaming 179 Messaging enables a multistreaming service. Many applications 180 are comprised of multiple streams, each with their own 181 characteristics with regards to the other services listed. For 182 example, a typical multimedia application has at least two 183 flows for audio and video, each with different properties 184 (e.g., loss tolerance, message sizes). A multistreaming 185 service allows these streams to be configured separately. 187 Multipath 188 Multiple paths often exist between hosts; a multipath service 189 is required to allow applications to benefit from this. This 190 is an extension of the multistreaming service: different 191 streams should be mapped to the most suitable path, given the 192 configuration of the stream, and the network conditions of the 193 path. Messaging is required to make optimal use of multiple 194 paths with different loss and delay characteristics. 196 Congestion Control 197 Congestion control is an essential service. A given algorithm 198 is not suitable for all traffic types, and so one is not 199 prescribed. The service should require the use of a suitable 200 congestion control algorithm, and enforce this using a circuit 201 breaker. 203 Connections (optional) 204 Maintaining per-connection metadata at the endpoints is helpful 205 for the implementation of many congestion control algorithms. 206 Further, connection setup and teardown messages can also 207 benefit in-network services, including NAT traversal and 208 firewall pinhole management. As a result, it is often 209 desirable to have support for a connection-oriented service. 211 This set of transport services demonstrates the need for a top-down 212 approach. Timing is a crucial characteristic of low-latency 213 applications, from which the other services follow. 215 3. Abstract API 217 This section describes an abstract API that supports the transport 218 services described in Section 2. This allows the usage of these 219 services to be demonstrated in Section 4. 221 It should be noted that the main contribution of this document is the 222 set of transport services specified in Section 2. An abstract API is 223 described here to illustrate how these services might be provided, 224 based on Berkeley Sockets for familiarity. Other APIs, not 225 constrained by the limitations of Berkeley Sockets, would be more 226 appropriate. 228 3.1. Socket Setup & Teardown 230 Hosts setup and tear-down sockets using the socket() and close() 231 functions, as in the standard Berkeley sockets API. 233 The function signatures are: 235 int socket(int address_family, 236 int socket_type); 238 int close(int sd); 240 socket() returns a socket descriptor (sd) on success, while close() 241 returns 0 on success, and -1 on failure. 243 3.2. Socket Options 245 Socket options can be set and read using the setsockopt() and 246 getsockopt() functions respectively. This mirrors the standard 247 Berkeley sockets API. 249 The function signatures are: 251 int getsockopt(int sd, 252 int level, 253 int option, 254 void *value, 255 socklen_t *len); 257 int setsockopt(int sd, 258 int level, 259 int option, 260 const void *value, 261 socklen_t len); 263 Both return 0 on success, and -1 on failure. 265 3.3. Connection Handling 267 The connection primitives are the same as those of TCP sockets. 268 Servers bind() to a particular address and port, then listen() for 269 and accept() incoming connections. Clients connect() to a server. 271 The function signatures are: 273 int bind(int sd, 274 struct sockaddr *addr, 275 socklen_t addrlen); 277 int listen(int sd); 279 int accept(int sd, 280 struct sockaddr *addr, 281 socklen_t *addrlen); 283 int connect(int sd, 284 const struct sockaddr *addr, 285 socklen_t addrlen); 287 All return 0 on success, and -1 on failure. 289 3.4. Timing 291 Once a connection has been establised, the receiver then indicates 292 its media play-out delay, in milliseconds, via the set_po_delay() 293 function. This specifies how long the application will buffer data 294 for before it is rendered to the user. The play-out delay is fed 295 back to the sender, for use in estimating message liveness. 297 The function signature is: 299 int set_po_delay(int delay); 301 The function returns 0 on success, and -1 on failure. 303 3.5. Messaging 305 Message-oriented data transmission is exposed by the send_message() 306 and recv_message() functions. These expose a partially reliable 307 message delivery service to the application, framing data such that 308 either the complete message is delivered, or lost in its entirety. 310 The function signatures are: 312 int send_message(int sd, 313 const void *buf, 314 size_t len, 315 uint16_t *seq_num, 316 int lifetime, 317 uint16_t depends_on, 318 uint8_t substream); 320 int recv_message(int sd, 321 void *buf, 322 size_t len, 323 uint16_t *seq_num, 324 uint8_t *substream); 326 send_message() returns the number of bytes sent and the sequence 327 number of the message, while recv_message returns the sub-stream 328 identifier and length of the message, along with the received message 329 data. 331 It is instructive to compare the partially reliable send and receive 332 functions to their Berkeley sockets API counterparts. The 333 send_message() call takes three additional parameters, providing 334 support for the transport services described in Section 2: 336 o Lifetime: combined with an estimate of the round-trip time, the 337 time that the message has spent in the sending buffer, and the 338 play-out delay, to estimate message liveness 340 o Dependency message sequence number: used to determine if this 341 message depends on another that was not sent successfully 343 o Sub-stream identifier: to provide the multistreaming service 345 send_message() returns the sequence number of the sent message, 346 allowing it to be used as the dependency of future messages. The 347 sequence number will increase by 1 for each message sent (and wrap 348 around within the 16-bit field). recv_message() returns the sequence 349 number of the received message, allowing the application to identify 350 gaps in the sequence space (indicating reordering or loss). 352 [Discussion question: would it be useful for recv_message() to expose 353 the message arrival time?] 355 3.6. Utilities 357 Two utility functions are needed to support the other services. To 358 allow applications to size messages to increase their utility, 359 get_pmtu() provides the path MTU. get_rtt_est() provides an estimate 360 of the round-trip time, to enable applications to calculate an 361 appropriate play-out delay value. 363 The function signatures are: 365 int get_pmtu(int sd); 367 int get_rtt_est(int sd); 369 get_pmtu() returns the path MTU in bytes. get_rtt_est() returns the 370 current round-trip time estimate in milliseconds. 372 Endpoints need to send data regularly to obtain an accurate RTT 373 estimate. Where an endpoint would not otherwise transmit data, the 374 messages sent by set_po_delay() will allow an RTT estimate to be 375 calculated. 377 3.7. Design Assumptions 379 The API specified here makes a number of assumptions about how the 380 services described in Section 2 should be provided. For example, the 381 way in which sequence numbers are implemented limits messages to 382 expressing their dependence on messages that have been sent 383 previously. A different API may be implement a different set of 384 constraints on the dependency management service. 386 [Discussion questions: does this mean that the services aren't 387 properly defined? How much flexibility should be given when 388 designing an API?] 390 4. Example Usage 392 In this section, examples of how applications might use the API 393 described in Section 3 are given. This is important, not only for 394 demonstrating the usability of the API, but for validating the 395 selection of transport services described. 397 4.1. HTTP/1.1 399 tbd 401 [Not typically described as "low latency", but is used by many 402 applications that would benefit from lower latency. Mapping to a 403 message-oriented transport service is not obvious.] 405 4.2. HTTP/2 407 tbd 409 [Mapping to message-oriented transport is a lot more obvious.] 411 4.3. Real-Time Multimedia 413 Real-time multimedia applications typically make use of RTP [RFC3550] 414 as their application-layer protocol. This adds a header to each 415 message, with timing and sequencing metadata. RTP is compatible with 416 the partially reliable, unordered message delivery model described, 417 making its mapping to the API straightforward. 419 Sender: 421 o The sender opens a socket(), and bind()s to a particular address 422 and port. It then listen()s for and accept()s incoming 423 connections. 425 o Messages are sent using send_message(). The application specifies 426 the lifetime of the message; this is the maximum delay each 427 message can tolerate. For example, a VOIP application would set 428 this to 150ms. The sequence number of message this message 429 depends on is set, and the sub-stream specified. get_pmtu() can be 430 used to help determine the message sizes. 432 o At the end of the connection, the sender close()s the socket. 434 Receiver: 436 o The receiver opens a socket(), and connect()s to a server. 438 o Once the connection has been established, the receiver sets its 439 play-out delay, in milliseconds, using set_po_delay(). The 440 utility function get_rtt_est() can be used in calculating this 441 value. The play-out delay can be changed over time. 443 o Messages are received using recv_message(). The application 444 receives the sequence number and sub-stream identifier alongside 445 the message data. 447 o At the end of the connection, the receiver close()s the socket. 449 5. IANA Considerations 451 This memo includes no request to IANA. 453 6. Security Considerations 455 The transport services described do not themselves introduce any 456 security considerations beyond those of TCP or UDP. No additional 457 metadata needs to be exposed on the wire to provide the transport 458 services described. The transport services result in a partially 459 reliable, message-oriented delivery model. As a result, Datagram TLS 460 [RFC6347] is required for security and encryption. 462 [Discussion question: should DTLS/security be listed as an essential 463 service?] 465 There are a number of options for deploying the transport services 466 described in this document. They could be deployed within a new 467 protocol, but this will likely limit deployability. Alternatively, 468 for greater deployability, existing protocols could be modified. 469 Partially Reliable SCTP [RFC3758] and WebRTC's data channels 470 [I-D.ietf-rtcweb-data-channel] provide a similar set of services over 471 SCTP. For maximum deployability, the services should be provided 472 over TCP. Modifying TCP's in-order byte stream abstraction to 473 provide an out-of-order message-oriented delivery model is 474 challenging. The designs of TCP Hollywood [IFIP2016], Minion 475 [I-D.iyengar-minion-protocol], and QUIC 476 [I-D.hamilton-quic-transport-protocol] show ways of addressing these 477 challenges. 479 7. Informative References 481 [CCR20] Clark, D. and D. Tennenhouse, "Architectural 482 Considerations for a New Generation of Protocols", ACM 483 SIGCOMM Computer Communications Review 20 (4) 200-208, 484 DOI 10.1145/99508.99553, September 1990, 485 . 487 [I-D.hamilton-quic-transport-protocol] 488 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 489 A UDP-Based Multiplexed and Secure Transport", draft- 490 hamilton-quic-transport-protocol-00 (work in progress), 491 July 2016. 493 [I-D.ietf-rtcweb-data-channel] 494 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 495 Channels", draft-ietf-rtcweb-data-channel-13 (work in 496 progress), January 2015. 498 [I-D.iyengar-minion-protocol] 499 Jana, J., Cheshire, S., and J. Graessley, "Minion - Wire 500 Protocol", draft-iyengar-minion-protocol-02 (work in 501 progress), October 2013. 503 [IFIP2016] 504 McQuistin, S., Perkins, C., and M. Fayed, "TCP Hollywood: 505 An Unordered, Time-Lined, TCP for Networked Multimedia 506 Applications", IFIP Networking 2016, 507 DOI 10.1109/IFIPNetworking.2016.7497221, May 2016, 508 . 510 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 511 Jacobson, "RTP: A Transport Protocol for Real-Time 512 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 513 July 2003, . 515 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 516 Conrad, "Stream Control Transmission Protocol (SCTP) 517 Partial Reliability Extension", RFC 3758, 518 DOI 10.17487/RFC3758, May 2004, 519 . 521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 522 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 523 January 2012, . 525 Authors' Addresses 527 Stephen McQuistin 528 University of Glasgow 529 School of Computing Science 530 Glasgow G12 8QQ 531 UK 533 Email: sm@smcquistin.uk 535 Colin Perkins 536 University of Glasgow 537 School of Computing Science 538 Glasgow G12 8QQ 539 UK 541 Email: csp@csperkins.org 543 Marwan Fayed 544 University of Stirling 545 Department of Computing Science & Maths 546 Stirling FK9 4LA 547 UK 549 Email: mmf@cs.stir.ac.uk