idnits 2.17.1 draft-kunze-coinrg-transport-issues-05.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 (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-asai-tsvwg-transport-review-02 == Outdated reference: A later version (-05) exists of draft-irtf-coinrg-use-cases-00 == Outdated reference: A later version (-02) exists of draft-jia-intarea-internet-addressing-gap-analysis-00 == Outdated reference: A later version (-03) exists of draft-jia-intarea-scenarios-problems-addressing-01 == Outdated reference: A later version (-08) exists of draft-king-irtf-challenges-in-routing-03 == Outdated reference: A later version (-04) exists of draft-king-irtf-semantic-routing-survey-02 -- Obsolete informational reference (is this intentional?): RFC 4960 (ref. 'SCTP') (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 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: 28 April 2022 D. Trossen 6 Huawei 7 25 October 2021 9 Transport Protocol Issues of In-Network Computing Systems 10 draft-kunze-coinrg-transport-issues-05 12 Abstract 14 Today's transport protocols offer a variety of functionality based on 15 the notion that the network is to be treated as an unreliable 16 communication medium. Some, like TCP, establish a reliable 17 connection on top of the unreliable network while others, like UDP, 18 simply transmit datagrams without a connection and without guarantees 19 into the network. These fundamental differences in functionality 20 have a significant impact on how COIN approaches can be designed and 21 implemented. Furthermore, traditional transport protocols are not 22 designed for the multi-party communication principles that underlie 23 many COIN approaches. This document raises several questions 24 regarding the use of transport protocols in connection with COIN. 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 28 April 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Technology Areas . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1.1. Research questions and challenges . . . . . . . . . . 4 64 3.1.2. Related concepts and efforts . . . . . . . . . . . . 5 65 3.2. Flow granularity . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. Research questions and challenges . . . . . . . . . . 7 67 3.2.2. Related concepts and efforts . . . . . . . . . . . . 8 68 3.3. Collective Communication . . . . . . . . . . . . . . . . 8 69 3.3.1. Research questions and challenges . . . . . . . . . . 9 70 3.3.2. Related concepts and efforts . . . . . . . . . . . . 9 71 3.4. Authentication . . . . . . . . . . . . . . . . . . . . . 9 72 3.4.1. Research questions and challenges . . . . . . . . . . 10 73 3.4.2. Related concepts and efforts . . . . . . . . . . . . 10 74 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.5.1. Research questions and challenges . . . . . . . . . . 10 76 3.5.2. Related concepts and efforts . . . . . . . . . . . . 10 77 3.6. Transport Features . . . . . . . . . . . . . . . . . . . 11 78 3.6.1. Reliability . . . . . . . . . . . . . . . . . . . . . 11 79 3.6.2. Flow/Congestion Control . . . . . . . . . . . . . . . 14 80 4. Summary of related research and standardization efforts . . . 15 81 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. Addressing . . . . . . . . . . . . . . . . . . . . . . . 17 83 5.2. Flow granularity . . . . . . . . . . . . . . . . . . . . 17 84 5.3. Collective Communication . . . . . . . . . . . . . . . . 17 85 5.4. Authentication . . . . . . . . . . . . . . . . . . . . . 17 86 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . 17 87 5.6. Transport Features . . . . . . . . . . . . . . . . . . . 17 88 5.6.1. Reliability . . . . . . . . . . . . . . . . . . . . . 17 89 5.6.2. Flow/Congestion Control . . . . . . . . . . . . . . . 17 90 6. Summary of Issues Identified . . . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10. Informative References . . . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 A fundamental consideration for the Internet's design is that 100 functions can be implemented correctly and completely only with the 101 knowledge of the applications, as formulated in [E2E]. This choice 102 is reflected in the end-to-end (E2E) principle [RFC1958],[RFC2775] in 103 that end-hosts perform most, if not all, relevant computations. The 104 network only performs transparent, reasonable operations such as 105 delivering the packets without modifying them with transport 106 protocols designed to facilitate the direct communication between 107 those end-hosts. 109 [E2E], however, does consider that "sometimes an incomplete version 110 of the function provided by the communication system may be useful as 111 a performance enhancement". We link this consideration to the field 112 of computing in the network (COIN), which encourages explicit 113 computations in the network, introducing an intertwined complexity as 114 the computations on the end-hosts depend on the functionality 115 deployed in the network. 117 Such thinking, to some extent, challenges traditional ``end-to-end'' 118 transport protocols as they are not designed to address in-network 119 computation entities or to include more than two devices into a 120 communication, even for inherent functionalities provided by the 121 transport protocol. Some of the resulting problems when considering 122 in-network computation in the context of an overall E2E problem are 123 already presented in [I-D.draft-kutscher-coinrg-dir-02]. 125 This draft focusses on the potential opportunities and research 126 questions for the design of transport protocols that may assume the 127 availability of in-network computing capabilities, including the 128 possible collaboration with other IRTF and IETF groups, such as PAN 129 RG, the IETF transport area in general, or the LOOPS BOF, for finding 130 suitable solutions. In particular, the draft first describes how 131 different aspects of transport protocols might be affected by in- 132 network computing functionality before it is analyzed how existing 133 transport protocols map to the identified questions and challenges. 135 2. Terminology 137 COIN element: Device on which COIN functionality can be deployed 139 3. Technology Areas 140 3.1. Addressing 142 The traditional addressing concept of the Internet is that end-hosts 143 directly address each other with all computational intelligence 144 residing at the network edges. With COIN, computations move into the 145 network and need to be integrated into the established 146 infrastructure. In systems where the whole network is under the 147 control of the network operator this integration can be implemented 148 by explicitly adjusting the communication schemes based on the COIN 149 functionality. Considering larger scales, this approach of manually 150 adjusting traffic patterns and applications to correctly incorporate 151 changes made by the network is not feasible. 153 What is needed are ways to specify which kind of functionality should 154 be applied to the transmitted data on the path inside the network and 155 maybe even where or by whom the execution should take place. From an 156 identification perspective, addressing may not only need to specify 157 the set of functionality that is being desired but also enable to 158 provide affinity to a member of the set of computational nodes that 159 provide said functionality. 161 For instance, orchestration functionality may be implemented using an 162 indirection mechanism which routes a packet along a pre-defined or 163 dynamically chosen path which then realizes the desired 164 functionality. One possibility is to directly route on service or 165 functionality identifiers instead of sending individual packets 166 between locator-addressed network elements 167 [I-D.draft-irtf-coinrg-use-cases]. While this aligns the routing 168 more clearly with the communication between computational elements, 169 selecting the 'right' computational endpoint (out of possibly several 170 ones) becomes critical to the proper functioning of the overall 171 service. 173 3.1.1. Research questions and challenges 175 1. How should end-hosts address the COIN functionality? 177 2. How can the treatment of the transmitted data, i.e., which COIN 178 functionality to execute, be represented in the addressing of the 179 request? 181 3. How can end-hosts direct computational requests to different 182 computational endpoints of the same service in different network 183 locations, i.e., decide where the COIN functionality is executed? 185 4. How to decide (and encode the decision) which computational 186 endpoint to choose (from possibly several ones existing in the 187 network)? 189 5. How can devices which do not implement COIN functionality be 190 integrated into the systems without breaking the COIN or legacy 191 functionality? 193 3.1.2. Related concepts and efforts 195 * Segment and Source Routing (see [SPRING-WG]) 197 Source Routing allows a sender to (partially) define the route of a 198 packet through the network. This mechanism can be leveraged to steer 199 the traffic along COIN nodes and thus trigger desired COIN 200 functionality. The SPRING WG is scoped to define procedures around 201 Segment Routing [SR], a modern variant of Source Routing for IPv6 and 202 MPLS. 204 * (Service/Network) Function Chaining/Composition (see [SFC-WG]) 206 Service Function Chaining (SFC) describes a process to first define 207 an ordered list of service functions (e.g., firewalls) and then steer 208 traffic through these functions [SFC-PS]. The SFC WG is tasked with 209 defining suitable orchestration techniques for SFC. The existing SFC 210 architecture [SFC-Arch] and the Network Service Header [SFC-NSH] 211 already provide fundamental mechanisms. Interpreting COIN 212 functionality as service functions could make SFC applicable to COIN 213 at Layer 2 and Layer 3, but also at name-based, e.g., HTTP level 214 [RFC8677] 216 * Internet services over ICN (see [ICNIP]) 218 Work in the ICN RG [ICNRG] has generally studied the addressing of 219 information rather than endpoints, opening up the possibility for 220 providing information from different sources, including in-network 221 elements, such as for caching purposes. The work in [ICNIP] utilizes 222 the ICN capabilities to address services directly as a named entity, 223 including IP endpoints, in order to support concepts like 224 virtualization of service endpoints and provisioning within edge and 225 in-network locations. The solution in [ICNIP] proposes the use of a 226 Layer 2 path-based forwarding with service identifiers used to 227 address the specific service endpoint. 229 * Flexible Addressing (see 230 [I-D.draft-jia-intarea-scenarios-problems-addressing]) 232 Although the work in the INT Area of the IETF does not postulate a 233 specific solution, it outlines a number of communication scenarios 234 and challenges, some of which aligns with those outlined above. The 235 companion draft 236 [I-D.draft-jia-intarea-internet-addressing-gap-analysis] provides a 237 deeper gap analysis of existing solutions (the above mentioned 238 solutions are presented here, too), identifying a number of issues 239 that arise from the specific point solutions realized by those 240 solutions. The authors argue for both flexibility and extensibility 241 of addressing; key aspects that any solution addressing the research 242 questions outlined above would benefit from. 244 * Semantic Routing (see 245 [I-D.draft-king-irtf-semantic-routing-survey]) 247 The survey at [I-D.draft-king-irtf-semantic-routing-survey] provides 248 an overview of efforts on addressing and routing that incorporate a 249 semantic beyond the one defined by IPv6, covering both existing IETF 250 solutions as well as ongoing research, defined as 'semantic routing' 251 in the draft. The companion draft at 252 [I-D.draft-king-irtf-challenges-in-routing] outlines a number of 253 challenges that exist for such extension of the addressing semantic, 254 some of which align with the issues identified in this document. 255 More importantly, the draft discusses the possible deployment of 256 semantic routing solutions, e.g., as an overlay or limited to a 257 single domain (following the Limited Domain concept of [RFC8799]). 258 Some of the challenges identified in 259 [I-D.draft-king-irtf-challenges-in-routing] apply to a COIN 260 environment, while not being limited to it. For instance, the 261 intended scope of any enhanced addressing (e.g., identifying COIN 262 elements on-path in a scenario) or the description of path 263 characteristics that COIN traffic would need to adhere to. 265 3.2. Flow granularity 267 Core networking hardware pipelines such as backbone switches are 268 built to process incoming packets on a per-packet basis, keeping 269 little to no state between them. This is appropriate for the general 270 task of forwarding packets, but might not be sufficient for COIN as 271 information that is needed for the computations can be spread across 272 several packets. In a TCP stream, for example, data is dynamically 273 distributed across different segments which means that the data 274 needed for application-level computations might also be split up. In 275 contrast to that the content of UDP datagrams is defined by the 276 application itself which is why the datagrams could either be self- 277 contained or information can be cleverly distributed onto different 278 datagrams. Summarizing, different transport protocols induce 279 different meanings to the packets that they send out which needs to 280 be accounted for in COIN elements as they have to know how the 281 received data is to be interpreted. There are at least three options 282 for this. 284 1. Every packet is treated individually. This maps to the 285 capabilities of existing networking equipment. 287 2. Every packet is treated as part of a message. In this setting, 288 the packet alone does not have enough information for the 289 computations. Instead, it is important to know the content of 290 the surrounding packets which together form the overall message. 292 3. Every packet is treated as part of a byte stream. Here, all 293 previous packets and potentially even all subsequent packets need 294 to be taken into consideration for the computations as the 295 current packet could, e.g., be the first of a group of packets, a 296 packet in the middle, or the final packet. 298 Along those options above, the question arises how shorter-term 299 'messages' (or transactions) of the computation should be handled 300 compared to the often longer-term management of the network resources 301 needed to transmit the packets across one or more such messages. For 302 instance, error control may be best applied to the individual 303 messages between computational endpoints, while congestion control 304 may be applied across several messages at the level of the relation 305 between the network elements hosting the computational endpoints. In 306 this view, the notion of a 'flow' may separate message or transaction 307 handling from the resource management aspect, where a flow may be 308 divided into sub-flows (said messages or transactions) with error 309 control being applied to those sub-flows but resource management 310 being applied to the overall flow. Such choice of flow granularity 311 would consequently have a significant impact on how and where 312 computations can be performed as well as ensuring that end-hosts know 313 who has altered the data and how. 315 3.2.1. Research questions and challenges 317 1. Which flow granularities are sensible for which scenarios and 318 upper layer protocols? 320 2. How do the different flow granularities map to error and 321 congestion control? 323 3. How is flow granularity used for creating affinity in, e.g., 324 routing choices? 326 4. How may flow granularity information be used in COIN elements, 327 e.g., to support routing and transport protocol realizations? 329 3.2.2. Related concepts and efforts 331 As mentioned above, flow granularities are defined in transport 332 protocols through their semantic for the unit of transfer, which can 333 be a 'datagram' or a 'flow'. Upper layer protocols, such as HTTP, 334 map their application data into this semantic, resulting, for 335 instance, in a flow of HTTP requests. Note that the flow identified 336 by the 5-tuple for the transport connection usually also carries the 337 reverse direction of communication, e.g., in the form of HTTP 338 responses. The introduction of 'TCP re-use' in HTTP/1.1 introduced 339 the capability of sending many HTTP request/response interactions in 340 a single TCP flow. The notion of flow granularity is being used in 341 [DYNCAST] to link the relation of one or more application level 342 interactions to a specific service instance in deployment scenarios 343 where more than one service instance may serve requests for a given 344 service; [DYNCAST] refers to the problem of 'instance affinity', 345 i.e., the need to send one or more such interactions to the same 346 instance before being able to choose another instance (e.g., based on 347 computing or network metrics, as suggested in [DYNCAST]). At this 348 point of the work, the potential realization of such 'instance 349 affinity' and the relation to transport (as well as application) 350 protocols has not been discussed yet. 352 Within the concept of Service Function Chaining (SFC) [SFC-Arch], a 353 chain of services is formed and expressed through the next service 354 header (NSH) [SFC-NSH], which provides entries into a next hop table 355 maintained at each Service Function Forwarder (SFF) [SFC-Arch]. 356 Packet classification takes place at the entry point of the chain, 357 therefore providing a notion of flow granularity where the chain is 358 treated as the 'unit of transfer'. Chaining can take place at Layer 359 2 or Layer 3, but also at a name-based layer (such as HTTP), as 360 proposed in [RFC8677]. 362 3.3. Collective Communication 364 COIN scenarios may exhibit a collective communication semantic, i.e., 365 a communication between one and more computational endpoints, as is 366 for example illustrated by use cases in 367 [I-D.draft-sarathchandra-coin-appcentres-04]. With this, unicast and 368 multicast transmissions become almost equal forms of communication, 369 as also observed in work on information-centric networking (ICN) 370 [ICNRG]. 372 Yet, these many-point relations may be ephemeral down to the 373 granularity of individual service requests between computational 374 endpoints which questions the viability of stateful routing and 375 transport approaches used for long-lived multicast scenarios such as 376 liveTV transmissions. 378 This is particularly pertinent for the transport layer where 379 reliability and flow control among a quickly changing set of 380 receivers is a challenging problem. The ability to divide receiver 381 groups with the support of in-network COIN elements may provide 382 solutions that will cater to the possible dynamics of collective 383 communication among computational endpoints. 385 3.3.1. Research questions and challenges 387 1. How to handle ephemeral transport relations at the request level 388 across more than one endpoint? 390 2. How to separate longer-term resource management from shorter-term 391 transaction handling for, e.g., error and flow control? 393 3. What role could COIN elements play in improving on solutions for 394 questions 1 and 2? 396 3.3.2. Related concepts and efforts 398 As stated above, work in the [ICNRG] has long considered multicast 399 and unicast delivery as two communication models, realized by the 400 same communication method that utilizes the interest-data model of 401 ICN. The work in [ICNIP] utilizes a different approach by relying on 402 path-based forwarding of packets identified through service-level 403 identifiers (such as URLs but also IP addresses), where return path 404 multicast is achieved through binary operations over the path 405 information of incoming service requests. The utilized transport 406 network technology is that of 5GLAN or SDN, where the latter uses an 407 OpenFlow-compatible approach to path-based forwarding with constant 408 state requirements for the in-network forwarders. A similar approach 409 is used in [BIER-MC] albeit at the level of a BIER overlay network. 410 [ICNIP] also discusses, albeit briefly only, the separation of 411 longer-lived resource management from shorter-lived transaction 412 handling to increase efficiency of the ephemeral return path 413 communication at the transport level. 415 3.4. Authentication 417 The realisation of COIN legitimizes and actively promotes that data 418 transmitted from one host to another can be altered on the way inside 419 the network. This opens the door for foul play as all intermediate 420 network elements - no matter if they are malicious or misbehaving by 421 accident, COIN elements, or 'traditional' middleboxes - could simply 422 start altering parts of the original data and potentially cause harm 423 to the end-hosts. What is needed are mechanisms with which the 424 receiving host can verify (a) how and (b) by whom the data has been 425 altered on the way. In fact, these might very well be two distinct 426 mechanisms as one (a) only focusses on the changes that are made to 427 the data while (b) requires a scheme with which COIN elements can be 428 uniquely identified (could very well relate to Section 3.1) and 429 subsequently authenticated. 431 3.4.1. Research questions and challenges 433 1. How are changes to the data within the network communicated to 434 the end-hosts? 436 2. How are the COIN elements that are responsible for the changes 437 communicated to the end-hosts? 439 3. How are changes made by the COIN elements authenticated? 441 3.4.2. Related concepts and efforts 443 * Proof of Transit [SFC-PoT] 445 The Proof of Transit concept of the SFC WG allows for proving that 446 packets have passed a defined path. Using this concept, it could at 447 least be possible to make sure that a packet has indeed passed the 448 desired COIN elements. However, it does not provide means to 449 validate which changes were made by the known nodes. 451 3.5. Security 453 Many early COIN concepts require an unencrypted transmission of data. 454 At the same time, there is a general tendency towards more and more 455 security features in communication protocols. QUIC, e.g., encrypts 456 all payload data and almost all header content already inside the 457 transport layer. This makes current COIN concepts infeasible in 458 settings where QUIC connections are used as the COIN elements do not 459 have access to any packet content. Using COIN thus also depends on 460 how well security mechanisms like encryption can be integrated into 461 COIN frameworks. 463 3.5.1. Research questions and challenges 465 To be added. 467 3.5.2. Related concepts and efforts 469 To be added. 471 3.6. Transport Features 473 Depending on application needs, different transport protocols provide 474 different features. These features shape the behavior of the 475 protocol and have to be taken into account when developing COIN 476 functionality. In this section, we focus on the impact of 477 reliability as well as flow and congestion control to create 478 awareness for the multifaceted interaction between the transport 479 protocols and COIN elements. 481 3.6.1. Reliability 483 Applications require a reliable transport whenever it is important 484 that all data is transmitted successfully. TCP[TCP] provides such a 485 reliable communication as it first sets up a dedicated connection and 486 then ensures the successful reception of all data. In contrast, 487 UDP[UDP] is a connectionless protocol without guarantees and COIN 488 elements working on UDP transmissions must be robust to lost 489 information. This is not the case for applications on top of TCP, 490 but the retransmissions and the TCP state, which TCP uses to achieve 491 the reliability, make packet processing for COIN more complex due to 492 at least three reasons. 494 The concept of retransmissions bases on the end-to-end principle as 495 retransmissions are performed by the sender if it has determined that 496 the receiver did not receive the corresponding original message. 497 Both participants can then act knowing that parts of the overall data 498 are still missing. For simple COIN elements, which are not aware of 499 the involved TCP states and which do not track sequence numbers, it 500 is difficult to identify (a) that a packet in the sequence is missing 501 and (b) that a packet is a retransmission. One question is whether 502 COIN elements should incorporate an understanding for retransmissions 503 on the basis of existing transport mechanisms or if a COIN-capable 504 transport should include dedicated signals for the COIN elements. 506 Apart from challenges in identifying retransmissions, there is also 507 the fact that they are sent out of order with the original packet 508 sequence. Depending on the chosen flow granularity (see 509 Section 3.2), COIN elements might have to hold contextual information 510 for a prolonged time once they identify an impeding retransmission. 511 Moreover, they might have to postpone or cancel computations if data 512 is missing and instead schedule later computations. The main 513 question arising from this is: to what extent should COIN elements be 514 capable of incorporating retransmissions into their computation 515 schemes and how much additional storage capabilities are required for 516 this? 517 When incorporating COIN elements into the retransmission mechanisms, 518 it is also an interesting question whether it should be possible to 519 request or perform retransmissions from COIN elements. Considering a 520 setting with COIN elements that are capable of detecting missing 521 packets and retransmission requests, it might improve the overall 522 performance if the COIN element directly requests or performs the 523 retransmission instead of forwarding the packet/request through the 524 complete sequence of elements. This is especially interesting in the 525 context of collective communication where reliability mechanisms 526 could make use of the multi-source nature of the communication and 527 leverage the presence of many COIN elements in the network, for 528 instance by using network coding techniques, which in turn may 529 benefit from COIN elements participating in the reliability 530 mechanism. In all cases, the aforementioned storage capabilities are 531 relevant so that the COIN elements can store enough information. The 532 general question, i.e., which nodes in the sequence should do the 533 retransmission, has already been worked on in the context of 534 multicast transport protocols. 536 Depending on the extent of realization of the presented 537 retransmission features, COIN elements might almost have to implement 538 some of TCP's state to fulfil their tasks. Considering that 539 different COIN elements have different computational and storage 540 capacities, it is very likely that not every form of transport 541 integration into COIN can be supported by every available COIN 542 platform. The choice of devices included into the communication will 543 hence certainly affect the types of transport protocols that can be 544 operated on the COIN networks. 546 Another aspect to consider is the 'unit' that needs to be reliably 547 transferred. In stream-based transport protocols, such as TCP, 548 packets represent the smallest unit of transfer. However, different 549 choices in the flow granularity and a possible move to larger-than- 550 a-packet messages or transactions, as suggested in Section 3.2, might 551 make other approaches to reliability viable that operate on the basis 552 of such messages. 554 3.6.1.1. Research questions and challenges 556 1. What is the unit of reliable transfer? 558 2. How to utilize more than one computational endpoint in the 559 reliability mechanism? 561 3. Should COIN elements be aware of retransmissions? 563 4. How can COIN elements identify missing packets or 564 retransmissions? 566 5. Should COIN elements be explicitly notified about 567 retransmissions? 569 6. To what extent should COIN elements be capable of incorporating 570 retransmissions into their computation schemes? 572 7. How much storage capabilities are required for incorporating 573 retransmissions? 575 8. How can COIN elements incorporate missing packets into their 576 computations? 578 9. How to deal with state changes in COIN elements caused by data 579 lost later in the communication chain and then retransmitted? 581 10. Should COIN elements be capable of requesting retransmissions/ 582 answering retransmission requests? 584 11. Which devices should perform retransmissions? 586 12. Do COIN elements have to keep transport state? 588 13. How much transport state do COIN elements have to keep? 590 3.6.1.2. Related concepts and efforts 592 * Transmission Control Protocol [TCP] 594 TCP provides reliable, ordered, and error-checked delivery of a byte 595 stream. As such, TCP does not allow for payload changes. This means 596 that COIN elements could only make changes to lower header 597 information. 599 * Stream Control Transmission Protocol [SCTP] 601 SCTP provides ensures a reliable exchange of messages. In contrast 602 to TCP, it decouples reliability from in-order delivery and thus 603 allows for sending messages without ordering. Additionally, it has 604 also been extended to provide partial reliability, i.e., controlling 605 the desired reliability on a per-message basis [SCTP-PR]. 607 * Constrained Application Protocol [CoAP] 609 CoAP is a specialized protocol targeting nodes that are constrained, 610 e.g., in terms of compute power or available bandwidth. It is 611 message-based and distinguishes between confirmable and non- 612 confirmable messages, i.e., similar to SCTP, allows for controlling 613 the reliability on a per-message basis. 615 * User Datagram Protocol [UDP] 617 UDP is a message-based protocol that does not provide any guarantees 618 regarding reliability to the application layer. 620 3.6.2. Flow/Congestion Control 622 TCP incorporates mechanisms to avoid overloading the receiving host 623 (flow control) and the network (congestion control) and determines 624 its sending rate as the minimum value of what both mechanisms 625 determine as feasible for the system. This approach is based on the 626 notion that computing and forwarding hosts are separated and is 627 challenged by the inclusion of COIN elements, i.e., computing nodes 628 in the network. 630 Flow control bases on explicit end-host information as the 631 participating end-hosts notify each other about how much data they 632 are capable of processing and consequently do not transmit more data 633 as the other host can handle. This only changes if one of the end- 634 hosts updates its flow control information. 636 Congestion control, on the other hand, interprets volatile feedback 637 from the network to guess a sending rate that is possible given the 638 current network conditions. Most congestion control algorithms 639 hereby follow a cyclical procedure where the sending end-hosts 640 constantly increase their sending rate until they detect network 641 congestion. They then decrease their sending rate once and start to 642 increase it again. 644 In this traditional two-fold approach, loss, delay, or any other 645 congestion signal (depending on the congestion control algorithm) 646 induced by COIN elements (only in case that they are the bottleneck) 647 is interpreted as network congestion and thus accounted for in the 648 congestion control mechanism. This means that the sending end-host 649 may repeatedly overload the computational capabilities of the COIN 650 elements when probing for the current network conditions instead of 651 respecting general device capabilities as is done by flow control. 653 In the context of COIN, the granularity of flows may see a division 654 into sub-flows or messages to better represent the used computational 655 semantic as discussed in Section 3.2. This raises the question 656 whether flow and congestion control should be applied to longer term 657 flows (of many sub-flows or messages) or directly to sub-flows. 658 Eventually, this could possibly lead to a separation of error control 659 (for sub-flows) and flow control (for longer-term flows). A 660 subsequent challenge is then how to reconcile the possible volatile 661 nature of sub-flow relations (between computational endpoints) with 662 the longer-term relationship between network endpoints that will see 663 a flow of messages between them. This is particularly pertinent in 664 collective communication scenarios, where many forward unicast sub- 665 flows may lead to a single multicast sub-flow response albeit only 666 for that one response message. Reconciling the various unicast 667 resource regimes into a single (ephemeral) multicast one poses a 668 significant challenge. 670 Consequently, the question arises whether COIN elements should be 671 able to participate in end-to-end flow control. 673 3.6.2.1. Research questions and challenges 675 1. Should COIN elements be covered by congestion control? 677 2. Should COIN elements be able to participate in end-to-end flow 678 control? 680 3. How could a resource constraint scheme similar to flow control be 681 realized for COIN elements? 683 4. How to reconcile message-level flexibility in transport relations 684 between computational endpoints with longer-term resource 685 stability between network elements participating in the 686 computational scenario? 688 3.6.2.2. Related concepts and efforts 690 * Transmission Control Protocol [TCP] 692 TCP implements flow and congestion control. The traffic is 693 controlled using TCP's receiver and congestion windows. 695 * Separation of Data Path and Data Flow 697 [I-D.draft-asai-tsvwg-transport-review-02] proposes to explicitly 698 divide transport protocols into two parts: a data path and a data 699 flow layer. Essentially, the data path layer is responsible for 700 handling path-related tasks, such as congestion control, and as such 701 spans multiple flows. The data flow layer on top then handles flow- 702 related tasks such as retransmissions and flow control. As indicated 703 by the early stage of the document, the concrete structure is still 704 up for debate. Yet, explicitly dividing congestion and flow control 705 could give the opportunity to devise more sophisticated approaches to 706 incorporate COIN elements. 708 4. Summary of related research and standardization efforts 709 +-----------------+--------------------------------------------------+ 710 | Issue | Efforts | 711 +=================+==================================================+ 712 | Addressing | Segment and Source Routing: | 713 | | - [SPRING-WG] | 714 | | - Segment Routing [SR] | 715 | | (Service/Network) Function Chaining/Composition: | 716 | | - [SFC-WG] | 717 | | - SFC Problem Statement [SFC-PS] | 718 | | - SFC Architecture [SFC-Arch] | 719 | | - SFC Network Service Header [SFC-NSH] | 720 | | - Internet Services over IP [ICNIP] | 721 +-----------------+--------------------------------------------------+ 722 | Flow | Service Function Chaining [SFC-Arch], [SFC-NSH] | 723 | Granularity | Use cases and problem statement | 724 | | for dynamic anycast [DYNCAST] | 725 +-----------------+--------------------------------------------------+ 726 | Collective | Information-centric networking [ICNRG] | 727 | Communication | Internet Services over IP [ICNIP] | 728 | | HTTP multicast over BIER [BIER-MC] | 729 +-----------------+--------------------------------------------------+ 730 | Authentication | SFC Proof of Transit [SFC-PoT] | 731 +-----------------+--------------------------------------------------+ 732 | Reliability | Transmission Control Protocol [TCP] | 733 | | Stream Control Transmission Protocol [SCTP] | 734 | | Constrained Application Protocol [CoAP] | 735 | | User Datagram Protocol [UDP] | 736 +-----------------+--------------------------------------------------+ 737 | Flow/Congestion | [I-D.draft-asai-tsvwg-transport-review-02] | 738 | Control | | 739 +-----------------+--------------------------------------------------+ 741 Figure 1: Related research and standardization efforts. 743 5. Gap Analysis 745 This section provides a gap analysis within the identified technology 746 areas with respect to existing IETF solutions and ongoing efforts in 747 transport protocols that were summarized in the previous section. 749 The goal of such analysis is to identify issues with those existing 750 solutions through and within COIN environments. From the viewpoint 751 of structuring the gap analysis, approaches such as those taken in 752 [I-D.draft-jia-intarea-internet-addressing-gap-analysis] may be used 753 as examples as well as direct (if suitable) input into the gap 754 analysis performed here. 756 5.1. Addressing 758 TBD 760 5.2. Flow granularity 762 TBD 764 5.3. Collective Communication 766 TBD 768 5.4. Authentication 770 TBD 772 5.5. Security 774 TBD 776 5.6. Transport Features 778 5.6.1. Reliability 780 TBD 782 5.6.2. Flow/Congestion Control 784 TBD 786 6. Summary of Issues Identified 788 This section will summarize the main issues across the investigated 789 transport technology areas of the previous section. 791 7. Security Considerations 793 COIN changes the traditional paradigm of a simple network and the 794 corresponding end-to-end principle as it encourages computations in/ 795 by the network. Approaches designed to protect transmitted data, 796 such as Transport Layer Security (TLS), which is even embedded into 797 newer transport protocols like QUIC, rely on the end-to-end principle 798 and are thus conceptually not compatible with COIN without a 799 consistent view on how in-network compute elements would fit into the 800 traditional end-to-end model. 802 Additionally, COIN elements often do not support required 803 cryptographic functionality. 805 Thus, there may be a need for new security concepts specific to COIN 806 environment that may have to be developed to allow for a secure use 807 within COIN environments. 809 8. IANA Considerations 811 N/A 813 9. Conclusion 815 The advent of COIN may bring many new use cases, as documented in 816 [I-D.draft-irtf-coinrg-use-cases], with promises of improved 817 solutions for various problems. The concept of in-network computing 818 capabilities, however, is not directly compatible with the end-to-end 819 nature of transport protocols, thereby posing a number of key 820 questions regarding COIN and transport protocols. 822 Those key questions, positioned across key technology areas for 823 transport protocols, lead us to look at possible gaps that may be 824 found in existing solutions when it comes to suitably supporting COIN 825 environments and scenarios. The gap analysis performed in this 826 document and the issues identified as a result of this analysis are 827 positioned as possible input into shaping a research agenda for new 828 transport protocols that have in-network computing capabilities in 829 mind and support them securely as well as the best performance 830 possible. 832 10. Informative References 834 [BIER-MC] Trossen, D., Rahman, A., Wang, C., and T. T. Eckert, 835 "Applicability of BIER Multicast Overlay for Adaptive 836 Streaming Services", Work in Progress, Internet-Draft, 837 draft-ietf-bier-multicast-http-response-06, 10 July 2021, 838 . 841 [CoAP] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 842 Application Protocol (CoAP)", RFC 7252, 843 DOI 10.17487/RFC7252, June 2014, 844 . 846 [DYNCAST] Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 847 (Dyncast) Use Cases and Problem Statement", Work in 848 Progress, Internet-Draft , February 2021, 849 . 852 [E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 853 in system design", ACM Transactions on Computer 854 Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402, 855 November 1984, . 857 [I-D.draft-asai-tsvwg-transport-review-02] 858 Asai, H., "Separation of Data Path and Data Flow Sublayers 859 in the Transport Layer", Work in Progress, Internet-Draft, 860 draft-asai-tsvwg-transport-review-02, 15 September 2021, 861 . 864 [I-D.draft-irtf-coinrg-use-cases] 865 Kunze, I., Wehrle, K., Trossen, D., and M. Montpetit, "Use 866 Cases for In-Network Computing", Work in Progress, 867 Internet-Draft, draft-irtf-coinrg-use-cases-00, 17 868 February 2021, . 871 [I-D.draft-jia-intarea-internet-addressing-gap-analysis] 872 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., and P. 873 Mendes, "Gap Analysis in Internet Addressing", Work in 874 Progress, Internet-Draft, draft-jia-intarea-internet- 875 addressing-gap-analysis-00, 12 July 2021, 876 . 879 [I-D.draft-jia-intarea-scenarios-problems-addressing] 880 Jia, Y., Trossen, D., Iannone, L., Shenoy, N., Mendes, P., 881 3rd, D. E. E., and P. Liu, "Challenging Scenarios and 882 Problems in Internet Addressing", Work in Progress, 883 Internet-Draft, draft-jia-intarea-scenarios-problems- 884 addressing-01, 12 July 2021, 885 . 888 [I-D.draft-king-irtf-challenges-in-routing] 889 King, D. and A. Farrel, "Challenges for the Internet 890 Routing Infrastructure Introduced by Changes in Address 891 Semantics", Work in Progress, Internet-Draft, draft-king- 892 irtf-challenges-in-routing-03, 14 June 2021, 893 . 896 [I-D.draft-king-irtf-semantic-routing-survey] 897 King, D. and A. Farrel, "A Survey of Semantic Internet 898 Routing Techniques", Work in Progress, Internet-Draft, 899 draft-king-irtf-semantic-routing-survey-02, 28 June 2021, 900 . 903 [I-D.draft-kutscher-coinrg-dir-02] 904 Kutscher, D., Karkkainen, T., and J. Ott, "Directions for 905 Computing in the Network", Work in Progress, Internet- 906 Draft, draft-kutscher-coinrg-dir-02, 31 July 2020, 907 . 910 [I-D.draft-sarathchandra-coin-appcentres-04] 911 Trossen, D., Sarathchandra, C., and M. Boniface, "In- 912 Network Computing for App-Centric Micro-Services", Work in 913 Progress, Internet-Draft, draft-sarathchandra-coin- 914 appcentres-04, 26 January 2021, . 918 [ICNIP] Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and 919 J. Riihijarvi, "Internet Services over ICN in 5G LAN 920 Environments", Work in Progress, Internet-Draft, draft- 921 trossen-icnrg-internet-icn-5glan-04, 1 October 2020, 922 . 925 [ICNRG] "Information-Centric Networking, IRTF Research Group", 926 . 928 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 929 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 930 . 932 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 933 DOI 10.17487/RFC2775, February 2000, 934 . 936 [RFC8677] Trossen, D., Purkayastha, D., and A. Rahman, "Name-Based 937 Service Function Forwarder (nSFF) Component within a 938 Service Function Chaining (SFC) Framework", RFC 8677, 939 DOI 10.17487/RFC8677, November 2019, 940 . 942 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 943 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 944 . 946 [SCTP] Stewart, R., Ed., "Stream Control Transmission Protocol", 947 RFC 4960, DOI 10.17487/RFC4960, September 2007, 948 . 950 [SCTP-PR] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 951 Conrad, "Stream Control Transmission Protocol (SCTP) 952 Partial Reliability Extension", RFC 3758, 953 DOI 10.17487/RFC3758, May 2004, 954 . 956 [SFC-Arch] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 957 Chaining (SFC) Architecture", RFC 7665, 958 DOI 10.17487/RFC7665, October 2015, 959 . 961 [SFC-NSH] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 962 "Network Service Header (NSH)", RFC 8300, 963 DOI 10.17487/RFC8300, January 2018, 964 . 966 [SFC-PoT] Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 967 Youell, "Proof of Transit", Work in Progress, Internet- 968 Draft, draft-ietf-sfc-proof-of-transit-08, 1 November 969 2020, . 972 [SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 973 Service Function Chaining", RFC 7498, 974 DOI 10.17487/RFC7498, April 2015, 975 . 977 [SFC-WG] "Service Function Chaining, IETF Working Group", 978 . 980 [SPRING-WG] 981 "Source Packet Routing in Networking, IETF Working Group", 982 . 984 [SR] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 985 Decraene, B., Litkowski, S., and R. Shakir, "Segment 986 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 987 July 2018, . 989 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 990 RFC 793, DOI 10.17487/RFC0793, September 1981, 991 . 993 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 994 DOI 10.17487/RFC0768, August 1980, 995 . 997 Authors' Addresses 999 Ike Kunze 1000 RWTH Aachen University 1001 Ahornstr. 55 1002 D-52074 Aachen 1003 Germany 1005 Email: kunze@comsys.rwth-aachen.de 1007 Klaus Wehrle 1008 RWTH Aachen University 1009 Ahornstr. 55 1010 D-52074 Aachen 1011 Germany 1013 Email: wehrle@comsys.rwth-aachen.de 1015 Dirk Trossen 1016 Huawei Technologies Duesseldorf GmbH 1017 Riesstr. 25C 1018 D-80992 Munich 1019 Germany 1021 Email: Dirk.Trossen@Huawei.com