idnits 2.17.1 draft-kunze-coinrg-transport-issues-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 (November 04, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-kunze-coin-industrial-use-cases-00 == Outdated reference: A later version (-02) exists of draft-kutscher-coinrg-dir-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COINRG I. Kunze 3 Internet-Draft K. Wehrle 4 Intended status: Informational RWTH Aachen University 5 Expires: May 7, 2020 November 04, 2019 7 Transport Protocol Issues of In-Network Computing Systems 8 draft-kunze-coinrg-transport-issues-00 10 Abstract 12 Today's transport protocols offer a variety of functionality based on 13 the notion that the network is to be treated as an unreliable 14 communication medium. Some, like TCP, establish a reliable 15 connection on top of the unreliable network while others, like UDP, 16 simply transmit datagrams without a connection and without guarantees 17 into the network. These fundamental differences in functionality 18 have a significant impact on how COIN approaches can be designed and 19 implemented. Furthermore, traditional transport protocols are not 20 designed for the multi-party communication principles that underlie 21 many COIN approaches. This document discusses selected 22 characteristics of transport protocols which have to be adapted to 23 support COIN functionality. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 7, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Flow granularity . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Authentication . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Advanced Transport Features . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. Informative References . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 A fundamental design choice of the Internet is that the network 74 should be kept as simple as possible while complexity in the form of 75 processing should ideally be located at the edges of the network, 76 i.e., on end-hosts. This choice is reflected in the widely known 77 end-to-end principle which states that end-hosts directly address 78 each other and perform all relevant computations while the only 79 purpose of the network is to deliver the packets without modifying 80 them. Transport protocols are consequently designed to facilitate 81 the direct communication between end-hosts. 83 In practice, the end-to-end principle is often violated by 84 intransparent middleboxes which alter transmitted packets, e.g., by 85 dropping or changing header fields. Contrary to that, COIN 86 encourages explicit computations in the network which introduces an 87 intertwined complexity as the concrete computations on the end-hosts 88 critically depend on the functionality that is deployed in the 89 network. On another note, it challenges traditional end-to-end 90 transport protocols as they lack means for addressing in-network 91 computation entities and as they are generally not designed to 92 include more than two devices into a communication. Some of these 93 problems are already presented in [I-D.draft-kutscher-coinrg-dir-00]. 94 This draft intends to discuss potential problems for traditional 95 transport protocols in more detail to raise questions that the COIN 96 community needs to solve before a widespread application of COIN 97 functionality is sensible. Collaboration with other IRTF and IETF 98 groups, such as PANRG, the IETF transport area in general, or the 99 LOOPS BOF, can help in finding suitable solutions. 101 2. Addressing 103 The traditional addressing concept of the Internet are end-hosts 104 directly addressing each other, with all computational intelligence 105 residing at the network edges. As other COIN drafts, such as 106 [I-D.draft-montpetit-coin-xr-03], 107 [I-D.draft-he-coin-managed-networks-01] and 108 [I-D.draft-kunze-coin-industrial-use-cases-00], and extensive 109 publications, such as [DANG], [RUETH] and [SAPIO], in the last years 110 have shown, performing some computations within the network offers 111 the prospect of improved application performance. In systems like 112 data centers, which do not rely on the Internet and where the whole 113 network is under the control of the network operator, integrating 114 such functionality can be done by explicitly adjusting the 115 communication schemes within these fully controlled systems based on 116 the functionality that is executed in the network. 118 With a widespread application of COIN and a consequent increase in 119 computational capacities in the network, however, it might also 120 become viable to deploy functionality in the 'wild' Internet so that 121 everyday applications might also benefit from these computations. At 122 this point, it is no longer feasible to manually adjust the traffic 123 patterns or the applications to correctly incorporate changes made by 124 the network. 126 It might thus make sense to make it possible to specify which kind of 127 functionality should be applied to the transmitted data on the path 128 inside the network, maybe even where or by whom exactly the execution 129 should take place. Such functionality could for example be 130 implemented using an indirection mechanisms which routes a packet 131 along a pre-defined or dynamically chosen path which then realizes 132 the desired functionality. Related concepts which might be of use 133 are Segment and Source Routing as well as (Service/Network) Function 134 Chaining/Composition. 136 The main challenges/questions at this point are: 138 1. How should end-hosts address the functionality within the 139 network? 141 2. How exactly can the end-hosts influence where or by whom the 142 functionality is executed? 144 3. How can devices which do not implement COIN functionality be 145 integrated into the systems without breaking the COIN or legacy 146 functionality? 148 Assuming that there is a suitable addressing scheme which allows to 149 define which kinds of functionality should be applied to the 150 transmitted data, a next question that arises is how the transmitted 151 data is to be treated by the devices implementing the functionality. 153 3. Flow granularity 155 Core networking hardware pipelines such as backbone switches serving 156 several tens of GBit/s are built to process incoming packets on a 157 per-packet basis, keeping little to no state between them. While 158 this is appropriate for the general task of forwarding packets, it 159 might not be sufficient for performing computations as related 160 information that is needed for the computations can be spread across 161 several packets. In a TCP stream, for example, data is dynamically 162 distributed across different segments which means that the data 163 needed for application-level computations might also be split up. In 164 contrast to that the content of UDP datagrams is defined by the 165 application itself which is why the datagrams could either be self- 166 contained or information can be cleverly distributed onto different 167 datagrams. The common scheme is that different transport protocols 168 induce different meanings to the packets that they send out which 169 needs to be accounted for in COIN elements as they have to know how 170 the received data is to be interpreted. There are at least three 171 options for this. 173 1. Every packet should be treated individually. This, above all, 174 perfectly meets the possibilities that are already offered by all 175 networking equipment. 177 2. Every packet should be treated as part of a message. In this 178 setting, the packet alone does not have enough information for 179 the computations. Instead, it is important to know the content 180 of the surrounding packets which together form the overall 181 message and might hence also be relevant for the computations. 183 3. Every packet should be treated as part of a byte stream. Here, 184 all previous packets and potentially even all following packets 185 need to be taken into consideration for the computations as the 186 current packet could, e.g., be the first of a group of packets, a 187 packet in the middle or the final packet of a sequence of 188 packets. 190 The flow granularity consequently has a significant impact on how 191 computations can be performed and where. Apart from how the COIN 192 elements should treat the transmitted data, another important aspect 193 is how it can be ensured that the end-hosts know who has altered the 194 data and how. 196 4. Authentication 198 The realisation of COIN legitimizes and actively promotes that data 199 transmitted from one host to another can be altered on the way inside 200 the network. While this can be beneficial if implemented correctly, 201 it also opens the door for foul play as all intermediate network 202 elements - no matter if they are malicious or misbehaving by 203 accident, COIN elements, or 'traditional' middleboxes - could simply 204 start altering parts of the original data and thus potentially cause 205 harm to the end-hosts. What is consequently needed is a mechanism 206 with which the receiving host can verify (a) how and (b) by whom the 207 data has been altered on the way. In fact, these might very well be 208 two distinct mechanisms as one (a) only focusses on the changes that 209 are made to the data while (b) requires a scheme with which COIN 210 elements can be uniquely identified (could very well relate to 211 Section 2) and subsequently authenticated. 213 The challenges at this point are thus the following: 215 1. How are changes to the data within the network communicated to 216 the end-hosts? 218 2. How are the COIN elements that are responsible for the changes 219 communicated to the end-hosts? 221 3. How is it verified that indeed the proclaimed COIN elements have 222 performed the changes and not some impostor? 224 5. Security 226 Today, most, if not all, COIN concepts base on the fact that the data 227 is transmitted in plain text as this makes working on the data easy. 228 This is in contrast to a general development which sees more and more 229 security features added to communication protocols, nicely 230 highlighted by QUIC where the all payload data and almost all header 231 content (except for the spin bit) is already encrypted inside the 232 transport layer. This, in turn, makes COIN concepts infeasible in 233 settings where QUIC connections are used as the COIN elements do not 234 have access to any packet content. As waiving security features is 235 generally not acceptable, the widespread success of COIN might very 236 well also depend on how well security mechanisms like encryption can 237 be integrated into COIN frameworks. 239 Together, the four aspects presented in Section 2 to Section 5 form a 240 set of fundamental properties that should be taken into account for a 241 basic transport-compatible realization of COIN. What is not yet 242 considered is the fact that different transport protocols typically 243 differ in functionality and thus have a significantly different 244 behavior. In the following, we briefly discuss select additional 245 transport features to create awareness for the multifaceted 246 interaction between the transport protocols and COIN elements. 248 6. Advanced Transport Features 250 There is a variety of transport features which are only supported in 251 some concrete transport implementations. Still, they have a 252 significant impact on the behavior and performance of the protocols. 253 One aspect is that some protocols offer reliability while others do 254 not. This is for example visible when comparing UDP, a 255 connectionless protocol without guarantees, to TCP which first sets 256 up a dedicated connection and then ensures the successful reception 257 of all data. When facing UDP transmissions, COIN elements 258 potentially have to cope with lost information while with TCP it is 259 fairly save to say that the packets will reach them at some point. 261 This, however, also makes it more difficult for COIN elements as TCP 262 retransmissions, which are issued once a packet has been detected as 263 lost, are sent drastically out of order with the original packet 264 sequence. 266 Thinking one step further, retransmissions are sent from the original 267 sender of the packet. In a communication setting with COIN elements 268 in between, resending the packet through the complete sequence of 269 elements might not be necessary if, e.g., a packet is lost at the 270 last stage of a sequence of COIN elements. Here, it might be enough 271 if this last element resends the packet, although this in turn means 272 that there have to be storage capabilities on the devices enabling 273 them to store a certain number of packets and have them ready for 274 retransmission. The general question, i.e., which of the nodes in 275 the sequence should actually do the retransmission, has already been 276 worked on in the context of multicast transport protocols. 278 Now focussing on the aspect of storage capabilities, it can be said 279 that different COIN devices have different computational and storage 280 capacities which can become a challenge if they have to hold some 281 packets (potentially for retransmission) or if they are supposed to 282 embed into TCP for which they might be forced to hold some form of 283 TCP's state. Consequently, it is very likely that not every form of 284 transport integration into COIN can be supported by every available 285 COIN platform. The choice of devices included into the communication 286 will hence certainly affect the types of transport protocols that can 287 be operated on the COIN networks. 289 Another aspect is flow and congestion control to avoid overloading 290 the receiving end-host and the network; it is included in TCP, but 291 not in UDP, but has an impact on how the end-hosts can send their 292 data. 294 All in all, there is a wide range of non-essential transport features 295 which nonetheless offer improved performance in certain settings and 296 for certain application combinations. However, as presented, it is 297 likely that not all of the features/types of transport protocols can 298 be supported on every COIN element. A potential approach might be to 299 define different classes of COIN-ready transport protocols which can 300 then be deployed depending on the concretely available networking/ 301 hardware elements. 303 7. Security Considerations 305 TBD 307 8. IANA Considerations 309 N/A 311 9. Conclusion 313 The advent of COIN comes with many new use cases and promises 314 improved solutions for various problems. It is, however, not 315 directly compatible with the end-to-end nature of transport 316 protocols. To enable a transport-based communication, it is thus 317 important to answer key questions regarding COIN and transport 318 protocols, some of which are raised in this document. 320 10. Informative References 322 [DANG] Dang, HT., "NetPaxos: Consensus at Network Speed", DOI: 323 10.1145/2774993.2774999, in SOSR, 2015. 325 [I-D.draft-he-coin-managed-networks-01] 326 He, J., Li, A., and M. Montpetit, "In-Network Computing 327 for Managed Networks: Use Cases and Research Challenges", 328 draft-he-coin-managed-networks-01 (work in progress), July 329 2019. 331 [I-D.draft-kunze-coin-industrial-use-cases-00] 332 Kunze, I., Rueth, J., and K. Wehrle, "Industrial Use Cases 333 for In-Network Computing", draft-kunze-coin-industrial- 334 use-cases-00 (work in progress), July 2019. 336 [I-D.draft-kutscher-coinrg-dir-00] 337 Kutscher, D., Karkkainen, T., and J. Ott, "Directions for 338 Computing in the Network", draft-kutscher-coinrg-dir-00 339 (work in progress), July 2019. 341 [I-D.draft-montpetit-coin-xr-03] 342 Montpetit, M., "In Network Computing Enablers for Extended 343 Reality", draft-montpetit-coin-xr-03 (work in progress), 344 July 2019. 346 [RUETH] Rueth, J., "Towards In-Network Industrial Feedback 347 Control", DOI: 10.1145/3229591.3229592, in ACM SIGCOMM 348 NetCompute, August 2018. 350 [SAPIO] Sapio, A., "Scaling Distributed Machine Learning with In- 351 Network Aggregation", 2019, 352 . 354 Authors' Addresses 356 Ike Kunze 357 RWTH Aachen University 358 Ahornstr. 55 359 Aachen D-50274 360 Germany 362 Phone: +49-241-80-21422 363 Email: kunze@comsys.rwth-aachen.de 365 Klaus Wehrle 366 RWTH Aachen University 367 Ahornstr. 55 368 Aachen D-50274 369 Germany 371 Phone: +49-241-80-21401 372 Email: wehrle@comsys.rwth-aachen.de