idnits 2.17.1 draft-kunze-coinrg-transport-issues-02.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 (September 08, 2020) is 1327 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-06 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: March 12, 2021 September 08, 2020 7 Transport Protocol Issues of In-Network Computing Systems 8 draft-kunze-coinrg-transport-issues-02 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 March 12, 2021. 42 Copyright Notice 44 Copyright (c) 2020 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Flow granularity . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Advanced Transport Features . . . . . . . . . . . . . . . . . 5 66 7.1. Reliability . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.2. Flow/Congestion Control . . . . . . . . . . . . . . . . . 8 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 11. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 A fundamental design choice of the Internet is that the network 77 should be kept as simple as possible while complexity in the form of 78 processing should be located on end-hosts at the edges of the 79 network. This choice is reflected in the end-to-end principle which 80 states that end-hosts directly address each other and perform all 81 relevant computations while the network only delivers the packets 82 without modifying them. Transport protocols are consequently 83 designed to facilitate the direct communication between end-hosts. 85 In practice, the end-to-end principle is often violated by 86 intransparent middleboxes which alter transmitted packets, e.g., by 87 dropping or changing header fields. Contrary to that, computing in 88 the network (COIN) encourages explicit computations in the network 89 which introduces an intertwined complexity as the computations on the 90 end-hosts depend on the functionality deployed in the network. It 91 further challenges traditional end-to-end transport protocols as they 92 are not designed to address in-network computation entities or to 93 include more than two devices into a communication. Some of these 94 problems are already presented in [I-D.draft-kutscher-coinrg-dir-02]. 96 This draft discusses potential problems for traditional transport 97 protocols in more detail to raise questions that the COIN community 98 needs to solve before a widespread application of COIN functionality 99 is sensible. Collaboration with other IRTF and IETF groups, such as 100 PANRG, the IETF transport area in general, or the LOOPS BOF, can help 101 in finding suitable solutions. 103 2. Terminology 105 COIN element: Device on which COIN functionality can be deployed 107 3. Addressing 109 The traditional addressing concept of the Internet is that end-hosts 110 directly address each other with all computational intelligence 111 residing at the network edges. With COIN, computations move into the 112 network and need to be integrated into the established 113 infrastructure. In systems where the whole network is under the 114 control of the network operator this integration can be implemented 115 by explicitly adjusting the communication schemes based on the COIN 116 functionality. Considering larger scales, this approach of manually 117 adjusting traffic patterns and applications to correctly incorporate 118 changes made by the network is not feasible. 120 What is needed are ways to specify which kind of functionality should 121 be applied to the transmitted data on the path inside the network and 122 maybe even where or by whom the execution should take place. Such 123 functionality could for example be implemented using an indirection 124 mechanism which routes a packet along a pre-defined or dynamically 125 chosen path which then realizes the desired functionality. Related 126 concepts are Segment and Source Routing as well as (Service/Network) 127 Function Chaining/Composition. 129 Main challenges/questions are: 131 1. How should end-hosts address the COIN functionality? 133 2. How can the end-hosts influence where or by whom the 134 functionality is executed? 136 3. How can devices which do not implement COIN functionality be 137 integrated into the systems without breaking the COIN or legacy 138 functionality? 140 Another question is how the transmitted data is to be treated by the 141 devices implementing the functionality. 143 4. Flow granularity 145 Core networking hardware pipelines such as backbone switches are 146 built to process incoming packets on a per-packet basis, keeping 147 little to no state between them. This is appropriate for the general 148 task of forwarding packets, but might not be sufficient for COIN as 149 information that is needed for the computations can be spread across 150 several packets. In a TCP stream, for example, data is dynamically 151 distributed across different segments which means that the data 152 needed for application-level computations might also be split up. In 153 contrast to that the content of UDP datagrams is defined by the 154 application itself which is why the datagrams could either be self- 155 contained or information can be cleverly distributed onto different 156 datagrams. Summarizing, different transport protocols induce 157 different meanings to the packets that they send out which needs to 158 be accounted for in COIN elements as they have to know how the 159 received data is to be interpreted. There are at least three options 160 for this. 162 1. Every packet is treated individually. This respects the 163 possibilities that are already offered by all networking 164 equipment. 166 2. Every packet is treated as part of a message. In this setting, 167 the packet alone does not have enough information for the 168 computations. Instead, it is important to know the content of 169 the surrounding packets which together form the overall message. 171 3. Every packet is treated as part of a byte stream. Here, all 172 previous packets and potentially even all subsequent packets need 173 to be taken into consideration for the computations as the 174 current packet could, e.g., be the first of a group of packets, a 175 packet in the middle or the final packet. 177 The flow granularity consequently has a significant impact on how 178 computations can be performed and where. Apart from how the COIN 179 elements should treat the transmitted data, another important aspect 180 is how it can be ensured that the end-hosts know who has altered the 181 data and how. 183 5. Authentication 185 The realisation of COIN legitimizes and actively promotes that data 186 transmitted from one host to another can be altered on the way inside 187 the network. This opens the door for foul play as all intermediate 188 network elements - no matter if they are malicious or misbehaving by 189 accident, COIN elements, or 'traditional' middleboxes - could simply 190 start altering parts of the original data and potentially cause harm 191 to the end-hosts. What is needed are mechanisms with which the 192 receiving host can verify (a) how and (b) by whom the data has been 193 altered on the way. In fact, these might very well be two distinct 194 mechanisms as one (a) only focusses on the changes that are made to 195 the data while (b) requires a scheme with which COIN elements can be 196 uniquely identified (could very well relate to Section 3) and 197 subsequently authenticated. The Proof of Transit 198 [I-D.draft-ietf-sfc-proof-of-transit-06] concept of the SFC WG could 199 be applicable for proving that a packet has indeed passed the desired 200 COIN elements, although it does not provide means to validate which 201 changes were made by the known nodes. 203 Main challenges/questions are: 205 1. How are changes to the data within the network communicated to 206 the end-hosts? 208 2. How are the COIN elements that are responsible for the changes 209 communicated to the end-hosts? 211 3. How are changes made by the COIN elements authenticated? 213 6. Security 215 Many early COIN concepts require an unencrypted transmission of data. 216 At the same time, there is a general tendency towards more and more 217 security features in communication protocols. QUIC, e.g., encrypts 218 all payload data and almost all header content already inside the 219 transport layer. This makes current COIN concepts infeasible in 220 settings where QUIC connections are used as the COIN elements do not 221 have access to any packet content. Using COIN thus also depends on 222 how well security mechanisms like encryption can be integrated into 223 COIN frameworks. 225 Together, the four aspects presented in Section 3 to Section 6 form a 226 set of fundamental properties for a basic transport-compatible 227 realization of COIN. In the following, we briefly discuss selected 228 additional transport features to create awareness for the 229 multifaceted interaction between the transport protocols and COIN 230 elements. 232 7. Advanced Transport Features 234 Depending on application needs, different transport protocols provide 235 different features. These features shape the behavior of the 236 protocol and have to be taken into account when developing COIN 237 functionality. In this section, we focus on the impact of 238 reliability as well as flow and congestion control. 240 7.1. Reliability 242 Applications require a reliable transport whenever it is important 243 that all data is transmitted successfully. TCP[RFC0793] provides 244 such a reliable communication as it first sets up a dedicated 245 connection and then ensures the successful reception of all data. In 246 contrast, UDP[RFC0768] is a connectionless protocol without 247 guarantees and COIN elements working on UDP transmissions must be 248 robust to lost information. This is not the case for applications on 249 top of TCP, but the retransmissions and the TCP state, which TCP uses 250 to achieve the reliability, make packet processing for COIN more 251 complex due to at least three reasons. 253 The concept of retransmissions bases on the end-to-end principle as 254 retransmissions are performed by the sender if it has determined that 255 the receiver did not receive the corresponding original message. 256 Both participants can then act knowing that parts of the overall data 257 are still missing. For simple COIN elements, which are not aware of 258 the involved TCP states and which do not track sequence numbers, it 259 is difficult to identify (a) that a packet in the sequence is missing 260 and (b) that a packet is a retransmission. One question is whether 261 COIN elements should incorporate an understanding for retransmissions 262 on the basis of existing transport mechanisms or if a COIN-capable 263 transport should include dedicated signals for the COIN elements. 265 Apart from challenges in identifying retransmissions, there is also 266 the fact that they are sent out of order with the original packet 267 sequence. Depending on the chosen flow granularity (see Section 4), 268 COIN elements might have to hold contextual information for a 269 prolonged time once they identify an impeding retransmission. 270 Moreover, they might have to postpone or cancel computations if data 271 is missing and instead schedule later computations. The main 272 question arising from this is: to what extent should COIN elements be 273 capable of incorporating retransmissions into their computation 274 schemes and how much additional storage capabilities are required for 275 this? 277 When incorporating COIN elements into the retransmission mechanisms, 278 it is also an interesting question whether it should be possible to 279 request or perform retransmissions from COIN elements. Considering a 280 setting with COIN elements that are capable of detecting missing 281 packets and retransmission requests, it might improve the overall 282 performance if the COIN element directly requests or performs the 283 retransmission instead of forwarding the packet/request through the 284 complete sequence of elements. In both cases, the aforementioned 285 storage capabilities are relevant so that the COIN elements can store 286 enough information. The general question, i.e., which nodes in the 287 sequence should do the retransmission, has already been worked on in 288 the context of multicast transport protocols. 290 Depending on the extent of realization of the presented 291 retransmission features, COIN elements might almost have to implement 292 some of TCP's state to fulfil their tasks. Considering that 293 different COIN elements have different computational and storage 294 capacities, it is very likely that not every form of transport 295 integration into COIN can be supported by every available COIN 296 platform. The choice of devices included into the communication will 297 hence certainly affect the types of transport protocols that can be 298 operated on the COIN networks. 300 Challenges/questions regarding reliability are: 302 1. Should COIN elements be aware of retransmissions? 304 2. How can COIN elements identify missing packets or 305 retransmissions? 307 3. Should COIN elements be explicitly notified about 308 retransmissions? 310 4. To what extent should COIN elements be capable of incorporating 311 retransmissions into their computation schemes? 313 5. How much storage capabilities are required for incorporating 314 retransmissions? 316 6. How can COIN elements incorporate missing packets into their 317 computations? 319 7. How to deal with state changes in COIN elements caused by data 320 lost later in the communication chain and then retransmitted? 322 8. Should COIN elements be capable of requesting retransmissions/ 323 answering retransmission requests? 325 9. Which devices should perform retransmissions? 327 10. Do COIN elements have to keep transport state? 329 11. How much transport state do COIN elements have to keep? 331 Another aspect is flow and congestion control to avoid overloading 332 the receiving end-host and the network. 334 7.2. Flow/Congestion Control 336 TCP incorporates mechanisms to avoid overloading the receiving host 337 (flow control) and the network (congestion control) and determines 338 its sending rate as the minimum value of what both mechanisms 339 determine as feasible for the system. This approach is based on the 340 notion that computing and forwarding hosts are separated and is 341 challenged by the inclusion of COIN elements, i.e., computing nodes 342 in the network. 344 Flow control bases on explicit end-host information as the 345 participating end-hosts notify each other about how much data they 346 are capable of processing and consequently do not transmit more data 347 as the other host can handle. This only changes if one of the end- 348 hosts updates its flow control information. 350 Congestion control, on the other hand, interprets volatile feedback 351 from the network to guess a sending rate that is possible given the 352 current network conditions. Most congestion control algorithms 353 hereby follow a cyclical procedure where the sending end-hosts 354 constantly increase their sending rate until they detect network 355 congestion. They then decrease their sending rate once and start to 356 increase it again. 358 In this traditional two-fold approach, loss, delay, or any other 359 congestion signal (depending on the congestion control algorithm) 360 induced by COIN elements (only in case that they are the bottleneck) 361 is interpreted as network congestion and thus accounted for in the 362 congestion control mechanism. This means that the sending end-host 363 may repeatedly overload the computational capabilities of the COIN 364 elements when probing for the current network conditions instead of 365 respecting general device capabilities as is done by flow control. 367 Consequently, the question arises whether COIN elements should be 368 able to participate in end-to-end flow control. 370 Main challenges/questions are: 372 1. Should COIN elements be covered by congestion control? 374 2. Should COIN elements be able to participate in end-to-end flow 375 control? 377 3. How could a resource constraint scheme similar to flow control be 378 realized for COIN elements? 380 All in all, there is a wide range of non-essential transport features 381 which offer improved performance in certain settings and for certain 382 application combinations. However, as presented, it is likely that 383 not all of the features/types of transport protocols can be supported 384 on every COIN element. It might make sense to define different 385 classes of COIN-ready transport protocols which can then be deployed 386 depending on the concretely available networking/hardware elements. 387 Alternatively, each of the features could be treated separately and 388 they could then be composed based on the demands of an application 389 at-hand. 391 Overall, the general question summarizing all of the other 392 challenges/question is: 394 Which transport features should be supported by COIN, how can they be 395 identified, and how can they be provided to application designers? 397 8. Security Considerations 399 COIN changes the traditional paradigm of a simple network and the 400 corresponding end-to-end principle as it encourages computations in/ 401 by the network. Approaches designed to protect transmitted data, 402 such as Transport Layer Security (TLS) which is even embedded into 403 newer transport protocols like QUIC, rely on the end-to-end principle 404 and are thus conceptually not compatible with COIN. Additionally, 405 COIN elements often do not support required cryptographic 406 functionality. Thus, there exist no out-of-the-box security 407 solutions for COIN which means new security concepts have to be 408 developed to allow for a secure use of COIN. 410 9. IANA Considerations 412 N/A 414 10. Conclusion 416 The advent of COIN comes with many new use cases and promises 417 improved solutions for various problems. It is, however, not 418 directly compatible with the end-to-end nature of transport 419 protocols. To enable a transport-based communication, it is thus 420 important to answer key questions regarding COIN and transport 421 protocols, some of which are raised in this document. 423 11. Informative References 425 [I-D.draft-ietf-sfc-proof-of-transit-06] 426 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 427 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 428 transit-06 (work in progress), June 2020. 430 [I-D.draft-kutscher-coinrg-dir-02] 431 Kutscher, D., Karkkainen, T., and J. Ott, "Directions for 432 Computing in the Network", draft-kutscher-coinrg-dir-02 433 (work in progress), July 2020. 435 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 436 DOI 10.17487/RFC0768, August 1980, 437 . 439 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 440 RFC 793, DOI 10.17487/RFC0793, September 1981, 441 . 443 Authors' Addresses 445 Ike Kunze 446 RWTH Aachen University 447 Ahornstr. 55 448 Aachen D-50274 449 Germany 451 Phone: +49-241-80-21422 452 Email: kunze@comsys.rwth-aachen.de 454 Klaus Wehrle 455 RWTH Aachen University 456 Ahornstr. 55 457 Aachen D-50274 458 Germany 460 Phone: +49-241-80-21401 461 Email: wehrle@comsys.rwth-aachen.de