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