idnits 2.17.1 draft-tiesel-taps-socketintents-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 27, 2017) is 2372 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0-9' is mentioned on line 222, but not defined == Unused Reference: 'I-D.pauly-taps-guidelines' is defined on line 531, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-tiesel-taps-communitgrany-01 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group P. Tiesel 3 Internet-Draft T. Enghardt 4 Intended status: Experimental A. Feldmann 5 Expires: April 30, 2018 TU Berlin 6 October 27, 2017 8 Socket Intents 9 draft-tiesel-taps-socketintents-01 11 Abstract 13 This document outlines Socket Intents, a concept that allows 14 applications to share their knowledge about upcoming communication 15 and express their performance preferences in a generic, intuitive 16 and, portable way. Using Socket Intents, an application can express 17 what it knows, assumes, expects, or wants regarding its network 18 communication. The information provided by Socket Intents can be 19 used by the network stack to optimize communication in a best-effort 20 way. 22 Socket Intent can be used to stem against the complexity of 23 exploiting transport diversity, e.g., to automate the choice among 24 multiple paths, provisioning domains or protocols. By shifting this 25 complexity from the application developer to the operating system, it 26 enables the use of these transport features to a wider range of 27 applications. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 30, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Socket Intents Concept . . . . . . . . . . . . . . . . . . . 4 67 4.1. Interactions between Socket Intents and QoS . . . . . . . 5 68 5. Socket Intent Types . . . . . . . . . . . . . . . . . . . . . 5 69 6. Initial Socket Intent Types . . . . . . . . . . . . . . . . . 6 70 6.1. Traffic Category . . . . . . . . . . . . . . . . . . . . 6 71 6.2. Size to be Sent / Received . . . . . . . . . . . . . . . 7 72 6.3. Duration . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6.4. Stream Bitrate Sent / Received . . . . . . . . . . . . . 7 74 6.5. Burstiness . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.6. Timeliness . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.7. Disruption Resilience . . . . . . . . . . . . . . . . . . 9 77 6.8. Cost Preferences . . . . . . . . . . . . . . . . . . . . 9 78 7. Implementation Guidelines . . . . . . . . . . . . . . . . . . 10 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8.1. Performance Degradation Attacks . . . . . . . . . . . . . 10 81 8.2. Information Leakage . . . . . . . . . . . . . . . . . . . 11 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 10. Publications History . . . . . . . . . . . . . . . . . . . . 11 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 12.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Appendix A. Usage examples . . . . . . . . . . . . . . . . . . . 13 89 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13 90 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 91 A.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 14 92 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 14 93 B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Conventions and Definitions 99 The words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and 100 "MAY" are used in this document. It's not shouting; when these words 101 are capitalized, they have a special meaning as defined in [RFC2119]. 103 Association Set, Association, Stream, or Message are used as defined 104 in [I-D.tiesel-taps-communitgrany]. 106 2. Introduction 108 Despite recent advances in the transport area, the adaption of new 109 transport protocols and transport protocol features is slow. In 110 practice, this only happens in limited fields as Web browsers or 111 within datacenters. The same problem occurs for taking advantage of 112 paths or provisioning domains (PvDs). In both cases, the benefits of 113 the new transport diversity come at the cost of an increased 114 complexity that has to be mastered by the application programmer. 116 To enable transport features like TCP fast open [RFC7413] or to 117 control how MPTCP [RFC6824] creates subflows requires specialized 118 APIs. These APIs are not part of the standard socket API, usually 119 not portable, and not available in many programming languages. Using 120 them often requires profound knowledge of the transport protocol 121 internals. 123 To use multiple paths, applications usually have to use their own 124 heuristics to select which paths, provisioning domains, or access 125 network to use. Choosing the right path is difficult as their 126 characteristics differ, e.g., regarding performance. Obtaining the 127 necessary information is difficult since it may require special 128 privileges and non-portable APIs. 130 In all cases mentioned above, an application that wants to take 131 advantage of the available transport diversity is faced with 132 substantially higher complexity regarding network APIs and networking 133 code. 135 3. Problem Statement 137 Application programmers opening a communication channel typically 138 know how this channel will be used. There is more information 139 available than the protocol and destination address needed to 140 establish a communication channel: An application developer has an 141 intuition about many aspects of an upcoming communication. These 142 intuition may include: 144 preferences: whether to optimize for bandwidth, latency, or cost 146 characteristics: expected packet rates, byte rates or how many bytes 147 will be sent or received. 149 expectations: towards path availability or packet loss 151 resiliences: whether the application can gracefully handle certain 152 error cases 154 These preferences, expectations and other information known about the 155 upcoming communication should be expressible in an intuitive, generic 156 way, that is independent of the network and transport protocol. Its 157 representation should be independent of the actual API used for 158 network communication and should be expressible in whatever API 159 available, e.g., as socket options for BSD sockets or as part of the 160 address resolution configuration for Post Sockets 161 [I-D.trammell-taps-post-sockets]. 163 Socket Intents should enable the OS to adjust the communication 164 channel according to the application's intents in a best-effort 165 fashion: They should provide the information needed to automatically 166 enabling transport features the application can benefit from or help 167 choosing the most suitable (combination) of paths based on the 168 properties of the access networks or PvD (see [RFC7556], Section 6.2) 169 available. The actual implementation is not part of the Socket 170 Intents concept, it is left to an OS policy that may choose the best 171 transport protocol, default parameters and PvDs available and may 172 also try to further optimize wherever possible. 174 4. Socket Intents Concept 176 Socket Intents are pieces of information that allow an application to 177 express what they know about the application's communication. They 178 indicate what the application wants to achieve, knows, or assumes in 179 general, intuitive terms. An application can use them to annotate 180 the characteristics, preferences, and intentions it associates with 181 each communication unit. Depending on the API used, Socket Intents 182 can be used on a per Association Set, Association, Stream or, Message 183 level. 185 Socket Intents are optional information that can be considered in a 186 _best-effort_ manner. Socket Intents _do not include requirements_, 187 such as reliable in-order delivery. Typical examples include desired 188 transport characteristics, e.g., low delay, high throughput, or 189 minimal cost, as well as expected application behavior, e.g., will 190 send 500 bytes. As this information captures the intents of an 191 applications and passes them along with the communication socket, we 192 call these pieces of information Socket Intents. 194 Applications have an incentive to specify their intents as accurately 195 as possible to take advantage of the most suitable existing 196 resources. Applications are expected to selfishly specify their 197 preferences. It is up to the OS's policy to prevent commitment of 198 excessive resources. 200 4.1. Interactions between Socket Intents and QoS 202 Socket Intents are not QoS labels, but have an orthogonal meaning. 203 While the purpose of QoS is to specify what an application requires, 204 Socket Intents are used to specify what an application knows or 205 prefers. Therefore, 207 o Socket Intents SHALL be purely advisory. 209 o Socket Intents MUST NOT be used to derive IntServ / RSVP style 210 guarantees. 212 o Socket Intents SHOULD be taken into account on a best-effort basis 213 and MAY be used to derive DiffServ Service Classes as described in 214 [RFC4594]. 216 5. Socket Intent Types 218 Socket Intents are structured as key-value-pairs. 220 The key, called short name, specifies the Socket Intent type. It is 221 identified by a string of the lower-case characters [a-z], numbers 222 [0-9] and the separator "-". 224 The namespace for the short names is partitioned as follows: 226 o All Socket Intent type not starting with "x-" or "y-" are managed 227 by an IANA registry. The assignment of new types requires an RFC 228 or expert review (TO BE DECIDED). 230 o Socket Intent type starting with "x-" are for experimental use. 232 o Private or vendor specific Socket Intent type MUST start with 233 "y-[vendor]-". 235 Values can be represented as Enum, Int, Float, ASCII-String [RFC0020] 236 or a sequence of the aforementioned data types. Implementations 237 determine how these types are represented on the respective platform. 239 The data type for the individual Socket Intents are determined by the 240 document defining the Socket Intent and MUST NOT be changed by an 241 implementation. For Enum data types, a list of valid values MUST be 242 provided by the document specifying that intent as well as a default 243 value that is equivalent to not specifying this intent. 245 6. Initial Socket Intent Types 247 The following sections contain a list or Socket Intent types and 248 their possible values. Recommended default values for Enum values 249 are marked with an asterisk (*) behind the level name. 251 6.1. Traffic Category 253 The Traffic Category describes the dominating traffic pattern of the 254 respective communication unit expected by the application. 256 Short name: category 258 Applicability: Association Set, Association, Stream 260 Data type: Enum 262 +---------+---------------------------------------------------------+ 263 | Level | Description | 264 +---------+---------------------------------------------------------+ 265 | query | Single request / response style workload, latency bound | 266 | | | 267 | control | Long lasting low bandwidth control channel, not | 268 | | bandwidth bound | 269 | | | 270 | stream | Stream of bytes/messages with steady data rate | 271 | | | 272 | bulk | Bulk transfer of large messages, presumably bandwidth | 273 | | bound | 274 | | | 275 | mixed* | Don't know or none of the above | 276 +---------+---------------------------------------------------------+ 278 Note: Most categories suggest the use of other intents to further 279 describe the traffic pattern anticipated, e.g., the bulk category 280 suggesting the use of the Size to be Sent intent or the stream 281 category suggesting the Stream Bitrate and Duration intents. 283 6.2. Size to be Sent / Received 285 This Intent is used to communicate the expected size of a transfer. 287 Short name: send_size / recv_size 289 Applicability: Association Set, Association, Stream, Message 291 Data type: Int (bytes) 293 6.3. Duration 295 This Intent is used to communicate the expected lifetime of the 296 respective communication unit. 298 Short name: duration 300 Applicability: Association Set, Association, Stream 302 Data type: Int (msec) 304 6.4. Stream Bitrate Sent / Received 306 This Intent is used to communicate the bitrate of the respective 307 communication unit. 309 Short name: send_bitrate / recv_bitrate 311 Applicability: Association Set, Association, Stream 313 Data type: Int (bits/sec) 315 6.5. Burstiness 317 This Intent describes the anticipated burst characteristics of the 318 traffic for this communication unit. It expresses how the traffic 319 sent by the application is expected to vary over time, and, 320 consequently, how long sequences of consecutively sent packets will 321 be. Note that the actual burst characteristics of the traffic at the 322 receiver side will depend on the network. 324 This Intent can provide hints to the application on what the resource 325 usage pattern for this communication unit will look like, which can 326 be useful for balancing the requirements of different application. 328 Short name: bursts 330 Applicability: Association Set, Association, Stream 331 Data type: Enum 333 +----------------+--------------------------------------------------+ 334 | Level | Description | 335 +----------------+--------------------------------------------------+ 336 | no_bursts | Application sends traffic at a constant rate | 337 | | | 338 | regular_bursts | Application sends bursts of traffic periodically | 339 | | | 340 | random_bursts | Application sends bursts of traffic irregularly | 341 | | | 342 | bulk | Application sends a bulk of traffic | 343 | | | 344 | mixed* | Don't know or none of the above | 345 +----------------+--------------------------------------------------+ 347 6.6. Timeliness 349 This Intent describes the desired delay characteristics for this 350 communication unit. It provides hints for the OS whether to optimize 351 for low delay or for other criteria. There are no hard requirements 352 or implied guarantees on whether these requirements can actually be 353 satisfied. 355 Short name: timeliness 357 Applicability: Association Set, Association, Stream, Message 359 Data type: Enum 361 +-------------+-----------------------------------------------------+ 362 | Level | Description | 363 +-------------+-----------------------------------------------------+ 364 | stream | Delay and packet delay variation should be kept as | 365 | | low as possible | 366 | | | 367 | interactive | Delay should be kept as low as possible, but some | 368 | | variation is tolerable | 369 | | | 370 | transfer* | Delay and packet delay variation should be | 371 | | reasonable, but are not critical | 372 | | | 373 | background | Delay and packet delay variation is no concern | 374 +-------------+-----------------------------------------------------+ 376 6.7. Disruption Resilience 378 This Intent describes how an application deals with disruption of its 379 communication, e.g. connection loss. It communicates how well the 380 application can recover from such disturbance and can have 381 implications on how many resources the OS should allocate to failover 382 techniques for this particular communication unit. 384 Short name: resilience 386 Applicability: Association Set, Association, Stream, Message 388 Data type: Enum 390 +--------------+----------------------------------------------------+ 391 | Level | Description | 392 +--------------+----------------------------------------------------+ 393 | sensitive | Disruptions result in application failure, | 394 | | disrupting user experience | 395 | | | 396 | recoverable* | Disruptions are inconvenient for the application, | 397 | | but can be recovered from | 398 | | | 399 | resilient | Disruptions have minimal impact for the | 400 | | application | 401 +--------------+----------------------------------------------------+ 403 6.8. Cost Preferences 405 This describes the Intents of an Application towards costs cased by 406 the respective communication unit. It should guide the OS how to 407 handle cost vs. performance and reliability tradeoffs. 409 Short name: cost 411 Applicability: Association Set, Association, Stream, Message 413 Data type: Enum 414 +---------------+---------------------------------------------------+ 415 | Level | Description | 416 +---------------+---------------------------------------------------+ 417 | no_expense | Avoid expensive transports and consider failing | 418 | | otherwise | 419 | | | 420 | optimize_cost | Prefer inexpensive transports and accept service | 421 | | degradation | 422 | | | 423 | balance_cost* | Do not bias balancing cost and other criteria | 424 | | | 425 | ignore_cost | Ignore cost, choose transport solely based on | 426 | | other criteria | 427 +---------------+---------------------------------------------------+ 429 Note: the "no_expense" level implicitly asks the OS to fail 430 communication attempts if no inexpensive transports are available. 432 Application developers MUST be aware that this also no hard 433 requirement and can be ignored or overridden by the OS policy. 435 7. Implementation Guidelines 437 Implementations faced with unknown Socket Intent types SHOULD ignore 438 these intents for forward compatibility. The API MAY include a 439 parameter to change this behavior and make specifying unknown Socket 440 Intent types return an error. 442 Invalid values SHOULD return an error to the application. 444 For debugging purposes, implementations SHOULD allow to enumerate the 445 Socket Intents that are understood by the implementation. They MAY 446 expose which of the Socket Intents were considered by the 447 implementation. 449 8. Security Considerations 451 8.1. Performance Degradation Attacks 453 We assume that applications specify their preferences in a selfish, 454 but not malicious way and that it is up to the OS to find a 455 compromise between demands. 457 A malicious application could confuse the OS in a way that leads to 458 scheduling traffic with certain Intents on a more expensive 459 interface, penalizing this traffic, or even rejecting it. The attack 460 vector added by this is negligible: As the malicious application 461 could also generate the traffic it claims to intend, it already has a 462 much more powerful attack vector. 464 As a mitigation, the OS could monitor and compare the intents 465 specified with the traffic actually generated and notify the user if 466 the usage of Socket Intents is unusual or defective. 468 8.2. Information Leakage 470 Varying the transport or IP layer parameters of packets belonging to 471 different Streams or Messages multiplexed in the same encrypted 472 association might enable an attacker to gain some ground truth about 473 the shares of different kinds of traffic. As this might also be 474 implied by packet timings, application developers might weight the 475 small additional information disclosure against the possible 476 performance gains. Using Socket Intents on Association level can be 477 considered safe. 479 9. IANA Considerations 481 The Socket Intents type namespace SHOULD be managed by the IANA 482 registry. Details conforming to [RFC5226] are laid out in Section 5, 483 the initial types for the registry are described in Section 6. 485 10. Publications History 487 o The original idea of Socket Intents was published in [CoNEXT2013]. 489 o A performance study "Socket Intents: OS Support for Using Multiple 490 Access Networks and its Benefits for Web Browsing" is under 491 submission. 493 11. Acknowledgements 495 This work has been supported by Leibniz Prize project funds of DFG - 496 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 497 FE 570/4-1). 499 12. References 501 12.1. Normative References 503 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 504 RFC 20, DOI 10.17487/RFC0020, October 1969, 505 . 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 513 IANA Considerations Section in RFCs", RFC 5226, 514 DOI 10.17487/RFC5226, May 2008, 515 . 517 12.2. Informative References 519 [CoNEXT2013] 520 Schmidt, P., Enghardt, T., Khalili, R., and A. Feldmann, 521 "Socket intents", Proceedings of the ninth ACM conference 522 on Emerging networking experiments and technologies - 523 CoNEXT '13, DOI 10.1145/2535372.2535405, 2013. 525 [DASH] International Organization for Standardization, "Dynamic 526 adaptive streaming over HTTP (DASH) - Part 1: Media 527 presentation description and segment formats", Standard 528 ISO/IEC 23009-1:2014 , June 2011, 529 . 531 [I-D.pauly-taps-guidelines] 532 Pauly, T., "Guidelines for Racing During Connection 533 Establishment", draft-pauly-taps-guidelines-01 (work in 534 progress), October 2017. 536 [I-D.tiesel-taps-communitgrany] 537 Tiesel, P. and T. Enghardt, "Communication Units 538 Granularity Considerations for Multi-Path Aware Transport 539 Selection", draft-tiesel-taps-communitgrany-01 (work in 540 progress), October 2017. 542 [I-D.trammell-taps-post-sockets] 543 Trammell, B., Perkins, C., Pauly, T., Kuehlewind, M., and 544 C. Wood, "Post Sockets, An Abstract Programming Interface 545 for the Transport Layer", draft-trammell-taps-post- 546 sockets-03 (work in progress), October 2017. 548 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 549 Guidelines for DiffServ Service Classes", RFC 4594, 550 DOI 10.17487/RFC4594, August 2006, 551 . 553 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 554 RFC 4960, DOI 10.17487/RFC4960, September 2007, 555 . 557 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 558 "TCP Extensions for Multipath Operation with Multiple 559 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 560 . 562 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 563 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 564 . 566 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 567 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 568 . 570 Appendix A. Usage examples 572 A.1. Example 1 574 Consider a cellphone performing an OS upgrade. This process usually 575 implies downloading a large file. This is a bulk transfer for which 576 the application may already know the file size. Timing is typically 577 noncritical and the data can be downloaded as background traffic with 578 minimal cost and power overhead. It would not hurt if the TCP 579 connection was closed during the transfer as the download can be 580 continued. 582 For this case, the application should set the "Traffic Category" to 583 "bulk", "Timeliness" to "background", and "Application Resilience" to 584 "resilient". In addition, "Message Size to be Received" can be 585 provided. Finally, the application may set the the "Cost 586 Preferences" to "no_expense". 588 The OS can use this information and therefore may schedule this 589 transfer on a flaky but not traffic-billed WiFi link and may reject 590 the connection attempt if no cheap access link is available. 592 A.2. Example 2 594 Consider a user watching non-live video content using MPEG-DASH 595 [DASH]. This usually means fetching a stream of video chunks. The 596 application should know the size of each chunk and may know the 597 bitrate and the duration of each chunk and the whole video. 598 Disconnection of the TCP connection should be avoided because that 599 might have an effect that is visible to the user. 601 For this case, the application should set the "Traffic Category" to 602 "stream", the "Timeliness" to "stream", and "Application Resilience" 603 to "sensitive". It may also provide the "Stream Bitrate Received" 604 and "Duration" expected. Finally, the application may set the the 605 "Cost Preferences" to "balance_cost". 607 The OS can use this information and, e.g, use MPTCP [RFC6824] if 608 available to schedule the traffic on the cheaper link (e.g, WiFi) 609 while establishing an additional subflow over an expensive link 610 (e.g., LTE). If the desired bandwidth cannot be matched by the 611 cheaper link, the more expensive link can be added to satisfy the 612 desired bandwidth. 614 If the application would set the "Cost Preferences" to 615 "optimize_cost", the OS would not schedule traffic on the second 616 subflow and the application would reduce the video quality to adapt 617 to the available data rate. 619 A.3. Example 3 621 Consider a user managing a remote machine via SSH. This usually 622 involves at least one long-lived console session and possibly file 623 transfers using SCP or rsync multiplexed on the same association 624 (e.g. TCP connection). 626 For the packets sent for the console session, the application can set 627 the "Traffic Category" to "control", the "Burstiness" to "random 628 bursts", the timeliness to "interactive" and the resilience to 629 "sensitive". For the packets of the file transfers, SSH may set 630 both, the "Traffic Category" and "Burstiness" to "bulk". It may also 631 know the size of the transfer and therefore sets "Message Size to be 632 Sent" or "Message Size to be Received". 634 Assuming there are transport opportunities supporting multiple 635 streams in a single association (e.g. SCPT [RFC4960]), the OS can 636 use this information to schedule the streams over different links to 637 meet their requirements (latency vs. bandwidth). In case the OS has 638 to use TCP, it can still optimize by disabling TCP Nagle Algorithm 639 for console session related transmissions. 641 Appendix B. Changes 643 B.1. Since -00 645 o Updates on Terminology (Object -> Message, Flow -> Assocication) 647 o More detailed Socket Intent Types specification 648 o Added implementation guidelines 650 o Many clairfications 652 o Fixed Authors and affiliations 654 Authors' Addresses 656 Philipp S. Tiesel 657 TU Berlin 658 Marchstr. 23 659 Berlin 660 Germany 662 Email: philipp@inet.tu-berlin.de 664 Theresa Enghardt 665 TU Berlin 666 Marchstr. 23 667 Berlin 668 Germany 670 Email: theresa@inet.tu-berlin.de 672 Anja Feldmann 673 TU Berlin 674 Marchstr. 23 675 Berlin 676 Germany 678 Email: anja@inet.tu-berlin.de