idnits 2.17.1 draft-arkko-path-signals-information-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (22 February 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-irtf-panrg-what-not-to-do-17 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational 22 February 2021 5 Expires: 26 August 2021 7 Considerations on Information Passed between Networks and Applications 8 draft-arkko-path-signals-information-00 10 Abstract 12 Path signals are messages seen by on-path elements examining 13 transport protocols. Current preference for good protocol design 14 indicates desire for constructing explict rather than implicit 15 signals to carry information. For instance, the ability of various 16 middleboxes to read TCP messaging was an implicit signal that lead to 17 difficulties in evolving the TCP protocol without breaking 18 connectivity through some of those middleboxes. 20 This document discusses the types of information that could be passed 21 in these path signals, and provides some advice on what types of 22 information might be provided in a beneficial manner, and which 23 information might be less likely to be revealed or used by 24 applications or networks. 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 https://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 26 August 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Past Experiences and Guidance . . . . . . . . . . . . . . . . 2 61 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Information Specificity . . . . . . . . . . . . . . . . . 3 63 3.2. Granularity . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Informative References . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 [RFC8558] discusses the topic of path signals: Path signals are 71 messages seen by on-path elements examining transport protocols. 72 There's a difference between implicit and explicit signals. For 73 instance, TCP's well-known messages [RFC0793] are in the clear, and 74 often interpreted in various ways by on-path elements. In contrast, 75 QUIC protects almost all of this information, and hence end-to-end 76 signaling becomes opaque for network elements in between. QUIC does 77 provide some information, but has chosen to make these signals (such 78 as the Spin bit) explicit [I-D.ietf-quic-transport]. 80 Many attempts have been made at network - application collaboration 81 using path signals. Section 2 discusses some of the experiences and 82 guidelines determine from those attempts. This draft then focuses on 83 the specific question of what kind of data can be passed. 85 2. Past Experiences and Guidance 87 Incentives are a well understood problem in general but perhaps not 88 fully internalised for various collaborative like designs. The 89 principle is that both receiver and sender of information must 90 acquire tangible and immediate benefits from the communication, such 91 as improved performance, 93 A related issue is understanding whether there is or is not a 94 business model or ecosystem change. Some designs may work well 95 without any monetary or payment or cross-administrative domains 96 agreements. For instance, I could ask my packets to be prioritised 97 relative to each other and that shouldn't affect anything else. Some 98 other designs may require a matching business ecosystem change to 99 support what is being proposed, and may be much harder to achieve. 100 For instance, requesting prioritisation over other people's traffic 101 may imply that you have to pay for that which may not be easy even 102 for a single provider let alone across many. 104 But on to more technical aspects. 106 The main guidance in [RFC8558] is to be aware that implicit signals 107 will be used whether intended or not. Protocol designers should 108 consider either hiding these signals when the information should not 109 be visible, or using explicit signals when it should be. 111 [I-D.irtf-panrg-what-not-to-do] discusses many past failure cases, a 112 catalogue of past issues to avoid. It also provides relevant 113 guidelines for new work, from discussion of incentives to more 114 specific observations, such as the need for outperforming end-to-end 115 mechanisms (Section 4.4), considering the need for per-connection 116 state (Section 4.6), and so on. 118 There are also more general guidance documents, e.g., [RFC5218] 119 discusses protocol successes and failures, and provides general 120 advice on incremental deployability etc. Internet Technology 121 Adoption and Transition (ITAT) workshop report [RFC7305] is also 122 recommended reading on this same general topic. And [RFC6709] 123 discusses protocol extensibility, and provides general advice on the 124 importance of global interoperability and so on. 126 3. Principles 128 This section attempts to provide some further guidelines, relating to 129 information that can be passed in path signals. Hopefully, these 130 guidelines can help future designers, explain past issues and 131 recommend useful models to apply. 133 3.1. Information Specificity 135 One common problem in finding a workable solution for network - 136 application collaboration is information leakage. All parties are 137 afraid of either their own propietary information or the users' data 138 leaking to others. Oddly enough, no one is usually worried about 139 users' data leaking to themselves, but I digress. :-) 141 [I-D.per-app-networking-considerations] discusses how applications 142 may be identified through collaboration mechanisms. This can be 143 harmful, as in extreme cases it may lead to undesirable 144 prioritization decisions or even blocking certain applications. 145 [I-D.per-app-networking-considerations] explains how to reduce the 146 latter problem by categories or requested service rather than 147 specific application identity, such as providing the category "video 148 call service" rather than the name of a particular application 149 performing conference call or video call services. This points to a 150 more general principle of information specificity, providing only the 151 information that is needed for the other party to perform the 152 collaboration task that is desired by this party, and not more. This 153 applies to information sent by an application about itself, 154 information sent about users, or information sent by the network. 156 An architecture can follow the guideline from RFC 8558 in using 157 explicit signals, but still fail to differentiate properly between 158 information that should be kept private and information that should 159 be shared. 161 In looking at what information can or cannot easily be passed, we can 162 look at both information from the network to the application, and 163 from the application to the network. 165 For the application to the network direction, user-identifying 166 information can be problematic for privacy and tracking reasons. 167 Similarly, application identity can be problematic, if it might form 168 the basis for prioritization or discrimination that the that 169 application provider may not wish to happen. It may also have 170 undesirable economic consequences, such as extra charges for the 171 consumer from a priority service where a regular service would have 172 worked. 174 On the other hand, as noted above, information about general classes 175 of applications may be desirable to be given by application 176 providers, if it enables prioritization that would improve service, 177 e.g., differentiation between interactive and non-interactive 178 services. 180 For the network to application direction there's less directly 181 sensitive information. Various network conditions, predictive 182 bandwidth and latency capabilities, and so on might be attractive 183 information that applications can use to determine, for instance, 184 optimal strategies for changing codecs. 186 However, care needs to be take to ensure that neither private 187 information about the individual user (such as user's physical 188 location) is not indirectly exposed through this information. 189 Similarly, this information should not form a mechanism to provide a 190 side-channel into what other users are doing. 192 3.2. Granularity 194 In the IAB Covid-19 Network Impacts workshop Jana Iyengar brought up 195 the granularity of operations [I-D.iab-covid19-workshop]. There are 196 many reasons why per-flow designs are problematic: scalability, need 197 to release information about individual user's individual activities, 198 etc. Perhaps designs that work on aggregates would work better. 200 4. Acknowledgments 202 The author would like to thank Mirja Kuhlewind, Tommy Pauly, Ted 203 Hardie, David Allan, Brian Trammell, Szilvezter Nadas, Zaheduzzaman 204 Sarker, Joel Halpern, Magnus Westerlund, Jana Iyengar and Balaz Varga 205 for interesting thoughts and proposals in this space. 207 5. Informative References 209 [I-D.iab-covid19-workshop] 210 Arkko, J., Farrell, S., Kuhlewind, M., and C. Perkins, 211 "Report from the IAB COVID-19 Network Impacts Workshop 212 2020", Internet Draft (Work in Progress), draft-iab- 213 covid19-workshop, IETF , February 2021. 215 [I-D.ietf-quic-transport] 216 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 217 and Secure Transport", Work in Progress, Internet-Draft, 218 draft-ietf-quic-transport-34, 14 January 2021, 219 . 222 [I-D.irtf-panrg-what-not-to-do] 223 Dawkins, S., "Path Aware Networking: Obstacles to 224 Deployment (A Bestiary of Roads Not Taken)", Work in 225 Progress, Internet-Draft, draft-irtf-panrg-what-not-to-do- 226 17, 10 February 2021, . 229 [I-D.per-app-networking-considerations] 230 Colitti, L. and T. Pauly, "Per-Application Networking 231 Considerations", Work in Progress, Internet-Draft, draft- 232 per-app-networking-considerations-00, 15 November 2020, 233 . 236 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 237 RFC 793, DOI 10.17487/RFC0793, September 1981, 238 . 240 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 241 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 242 . 244 [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 245 Considerations for Protocol Extensions", RFC 6709, 246 DOI 10.17487/RFC6709, September 2012, 247 . 249 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet 250 Technology Adoption and Transition (ITAT)", RFC 7305, 251 DOI 10.17487/RFC7305, July 2014, 252 . 254 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 255 RFC 8558, DOI 10.17487/RFC8558, April 2019, 256 . 258 Author's Address 260 Jari Arkko 261 Ericsson 263 Email: jari.arkko@ericsson.com