Separation of Data Path and Data Flow Sublayers in the Transport Layer
draft-asai-tsvwg-transport-review-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Author | Hirochika Asai | ||
Last updated | 2020-11-01 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-asai-tsvwg-transport-review-00
Network Working Group H. Asai Internet-Draft Preferred Networks Intended status: Standards Track 2 November 2020 Expires: 6 May 2021 Separation of Data Path and Data Flow Sublayers in the Transport Layer draft-asai-tsvwg-transport-review-00 Abstract This document reviews the architectural design of the transport layer. In particular, this document separates the transport layer into two sublayers; the data path and the data flow layers. The data path layer provides functionality on the data path, such as connection handling, path quality and trajectory monitoring, waypoint management, and congestion control. The data flow layer provides additional functionality upon the data path layer, such as flow control for the receive buffer management, retransmission for reliable data delivery, and transport layer security. The data path layer multiplexes multiple data flow layer protocols and provides data path information to the data flow layer to control data transmissions, such as prioritization and inverse multiplexing for multipath protocols. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Asai Expires 6 May 2021 [Page 1] Internet-Draft Data Path and Data Flow Layers November 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transport Layer Functionality Review . . . . . . . . . . . . 3 2.1. Conventional Layering . . . . . . . . . . . . . . . . . . 3 2.2. Data Path-aware Networking . . . . . . . . . . . . . . . 4 2.3. Resource Management: Flow Control and Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Multipath Protocols . . . . . . . . . . . . . . . . . . . 6 2.5. Reliable Data Communication . . . . . . . . . . . . . . . 6 2.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Specifications of Data Path Layer and Data Flow Layer . . . . 8 3.1. Data Path Layer . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. In-band trajectory monitoring . . . . . . . . . . . . 8 3.1.2. Waypoint management . . . . . . . . . . . . . . . . . 9 3.1.3. Bidirectional connection establishment . . . . . . . 9 3.1.4. Data path quality (congestion) monitoring and congestion control . . . . . . . . . . . . . . . . . 10 3.1.5. Data flow multiplexing . . . . . . . . . . . . . . . 10 3.1.6. Packet Duplication . . . . . . . . . . . . . . . . . 10 3.2. Data Flow Layer . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Retransmission for reliable data communication . . . 11 3.2.2. Flow control for receive-buffer management . . . . . 11 3.2.3. Flow prioritization . . . . . . . . . . . . . . . . . 11 3.2.4. End-to-end security . . . . . . . . . . . . . . . . . 11 3.2.5. Inverse multiplexing for multipath protocols . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Multipath Transport Protocols . . . . . . . . . . . . . . 12 4.2. Congestion Control Acceleration . . . . . . . . . . . . . 13 4.3. In-Network Computing . . . . . . . . . . . . . . . . . . 14 4.4. Flow Arbitration . . . . . . . . . . . . . . . . . . . . 15 5. Implementation Considerations . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Asai Expires 6 May 2021 [Page 2] Internet-Draft Data Path and Data Flow Layers November 2020 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction This document specifies two sublayers of the transport layer; the data path and the data flow layers. In this document, the transport layer's data path functionality, such as bidirectional connection handling, waypoint management, and congestion control, is separated from the data flow functionality, such as flow control for the receive buffer management, retransmission for reliable data delivery, and transport layer security. This document reviews the transport layer's functionality from the viewpoint of data paths and data flows in Section 2. It then specifies the data path layer and the data flow layer in Section 3. The data path and data flow layers provide the data path and the data flow functionality, respectively. This document reviews the transport layer to clarify the transport layer's functionality and to invent data flow layer protocols for advanced Internet technologies, such as middleboxes and in-network computing. Hence, this document does not intend to obsolete the transport layer or violate the current Internet architecture. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Transport Layer Functionality Review This section reviews the conventional layering and transport layer functionality. It then summarizes the transport layer functionality by distinguishing data paths and data flows. 2.1. Conventional Layering RFC 1122 [RFC1122] defines three communication layers, link layer, Internet layer, transport layer, and the interfaces between these layers. Link-layer protocols provide hop-by-hop data communications. Internet layer protocols such as the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), and the Internet Group Management Protocol (IGMP) provide fragmentation, hop-by-hop datagram forwarding, and end-to-end datagram delivery. RFC 1123 [RFC1123] defines the interface between the application layer and the transport layer. The Internet design follows the end-to-end principle to keep the simplicity of the Internet layer. Thus, the main functionality of the Internet layer is to provide end-to-end reachability. It does not guarantee datagram integrity, which means that packet loss, Asai Expires 6 May 2021 [Page 3] Internet-Draft Data Path and Data Flow Layers November 2020 duplication, corruption, or reordering may occur. Over the Internet layer, the transport layer implements such functionality to provide datagram integrity on the end-hosts to achieve end-to-end communications. +-------------------+ +-------------------+ | Application layer |<------------------------->| Application layer | +-------------------+ +-------------------+ | Transport layer |<------------------------->| Transport layer | +-------------------+ +-------------------+ +-------------------+ | Internet layer |<->| Internet layer |<->| Internet layer | +-------------------+ +-------------------+ +-------------------+ | Link layer |<->| Link layer |<->| Link layer | +-------------------+ +-------------------+ +-------------------+ End-host Router End-host Figure 1: Conventional layering of Internet architecture The transport layer provides various functions over the IP. User Datagram Protocol (UDP) [RFC0768] and Transmission Control Protocol (TCP) [RFC0793] are the most commonly used transport layer protocols. UDP is a connectionless transport protocol with a minimum header. TCP implements flow control according to the receiver's buffer capacity, retransmission for reliable communication, congestion control by a packet delivery status such as packet loss and delay. The transport layer may implement an end-to-end security function, Transport Layer Security (TLS) [RFC8446]. Figure 1 illustrates the conventional layering of Internet architecture. A router forwards an IP datagram to a next-hop router corresponding to the destination address. In this way, the Internet layer protocol, IP, provides end-to-end reachability through hop-by- hop routing. The transport layer provides additional functions for end-to-end communications. 2.2. Data Path-aware Networking As described above, the Internet layer's main functionality has been end-to-end reachability with hop-by-hop packet forwarding based on destination IP address. Therefore, it is unaware of data paths, i.e., trajectories of packets. Best-effort communications over ``dumb'' networks without the quality of service (QoS) have been the Internet principle [RFC2768]. This end-to-end principle of the Internet has achieved a scalable architecture. However, computer networks' advancement introduced QoS and middleboxes to achieve high- quality data communication and optimize communication over distributed and heterogeneous computer networks. These technologies require to be aware of data paths associated with data flows. Asai Expires 6 May 2021 [Page 4] Internet-Draft Data Path and Data Flow Layers November 2020 The Internet layer has been extended to support QoS. Differentiated Services, DiffServ [RFC2474], is one of the technologies to implement QoS. It enables autonomous and scalable service discrimination using an IP header field, differentiated services codepoint (DSCP), to implement QoS for a data path. Segment Routing [RFC8402] enables data path configuration for individual flows by leveraging the source routing paradigm. Thus, Segment Routing is another technology to treat QoS. Middleboxes are more complex than QoS. They add various functions such as firewalls, TCP offloading, transcoding, and content caches to a data path. These functions require to be aware of waypoints to be activated. Routing technologies with packet classification using the IP and the transport protocol headers have collectively been leveraged to route traffic through the middleboxes as the IP layer is not aware of data paths. If a middlebox is transparent to end-hosts, it should be installed at the network gateway or redirected by policy-based routing or segment routing to activate the function. Otherwise, an end-host should specify the middlebox as a target end- host. In addition to these middleboxes, distributed computing technologies, such as in-network computing and multi-access edge computing (MEC), also require to be aware of data paths. In summary, advanced computer networks require to treat data paths for QoS, middleboxes, and distributed computing. Packet classification for data path treatment may use the header information of transport layer protocols such as port numbers as well as IP header fields. 2.3. Resource Management: Flow Control and Congestion Control As the Internet layer does not provide resource management functionality, transport layer protocols may implement it, such as flow control and congestion control. Both flow control and congestion control mechanisms control packet transmission for resource management. However, the target resource is different. They control packet transmission according to the receiver's buffer capacity and the network bandwidth capacity, respectively. Asai Expires 6 May 2021 [Page 5] Internet-Draft Data Path and Data Flow Layers November 2020 For example, in TCP's flow control, a receiver announces the remaining receive buffer size as the window size. Hence, flow control is not aware of network bandwidth capacity. On the other hand, congestion control is performed based on data communication quality information, such as packet loss and delay. The underlying Internet layer may provide congestion information by the Explicit Congestion Notification (ECN) [RFC3168]. In this manner, transport layer protocols control congestion depending on the data path's network resources. Therefore, congestion control is associated with a data path, while flow control is associated with the end-hosts. As discussed above, congestion control should be performed on the associated data path. However, in current transport layer protocols such as TCP, Datagram Congestion Control Protocol (DCCP) [RFC4340], and Stream Control Transmission Protocol (SCTP) [RFC4960], an individual flow independently performs congestion control even if the same data path multiplexes multiple flows. Therefore, multiple flows cannot collectively perform congestion control for the data path. For example, when a data path multiplexes a TCP and a UDP flows, the TCP flow's congestion control may affect the other UDP flow's quality. Moreover, transport layer protocols utilize network resources on a fair basis. Thus, flow prioritization cannot be implemented at the transport layer, although a QoS technology such as DiffServ may be leveraged. 2.4. Multipath Protocols Multipath TCP [RFC8684] and SCTP utilize multiple data paths over multiple endpoint addresses. As these multipath protocols are unaware of data paths, they distinguish the data paths by endpoint IP addresses. Accordingly, multiple flows of these protocols may use an identical data path without recognizing it. Multipath protocols are also responsible for inverse multiplexing to split a data stream into multiple data paths. This inverse multiplexing is independent of data paths except for congestion control. 2.5. Reliable Data Communication Transport layer protocols may implement retransmission and reordering functions to recover lost or reordered datagrams for reliable data communication. This functionality is independent of data paths, and consequently, should be implemented over data paths. Instead, ``smart'' end-hosts or middleboxes may implement it. Asai Expires 6 May 2021 [Page 6] Internet-Draft Data Path and Data Flow Layers November 2020 An end-host may transmit a duplicate packet for improving reliability [RFC8655]. This functionality is also independent of data paths. However, a router in a data path may be capable of duplicating a packet because the duplication process does not require significant computing resources, unlike retransmission. 2.6. Security The transport layer may implement an end-to-end security function, such as Transport Layer Security (TLS) [RFC8446] Datagram Transport Layer Security (DTLS) [RFC6347]. As TLS does not encrypt the underlying transport protocol header, middleboxes such as TCP offloading can still work. However, some protocols implementing a transport layer protocol over DTLS, such as SCTP over DTLS used in WebRTC Data Channel [I-D.ietf-rtcweb-data-channel], encrypt the transport layer header, and consequently, have difficulty cooperating with these middleboxes. 2.7. Summary As described above, the transport layer functionality is summarized by distinguishing data paths and data flows as follows: The following functionality is categorized as data path functions. * In-band trajectory monitoring * Waypoint management * Bidirectional connection establishment * Data path quality (congestion) monitoring and congestion control * Data flow multiplexing * Packet duplication The following functionality is categorized as data flow functions. * Retransmission for reliable data communication * Flow control for receive-buffer management * Flow prioritization * End-to-end security * Inverse multiplexing for multipath protocols Asai Expires 6 May 2021 [Page 7] Internet-Draft Data Path and Data Flow Layers November 2020 3. Specifications of Data Path Layer and Data Flow Layer As summarized in Section 2.7, this document separates data paths and data flows from the transport layer. Hence, this document divides the transport layer into two sublayers; the data path and the data flow layers. This section specifies the functionality of these two sublayers. 3.1. Data Path Layer The data path layer provides the functionality to make the transport layer aware of data paths upon the Internet layer. The data path layer forwards packets without manipulating the payload. It means that the data path layer does not provide fragmentation, segmentation, or reassembly. Instead, the Internet layer or the data flow layer provide these functions. The data path layer may implement in-band trajectory monitoring, bidirectional connection establishment, data path quality monitoring and congestion control, data flow multiplexing, and packet duplication. A data path layer protocol may implement other functions related to data paths. 3.1.1. In-band trajectory monitoring The data path layer may provide an in-band trajectory monitoring function. The in-band trajectory monitoring function enables an upper-layer protocol to detect path change events and a single point of failure for multipath protocols. DPH: Data path layer protocol header +--------+ *--------------* *--------------* +--------+ | Host A |-----| DPR1 (ID: 3) |-----| DPR2 (ID: 4) |-----| Host B | +--------+ *--------------* *--------------* +--------+ | | | v | +-----+-+-+----...----+ | | DPH |3|4| Payload | | +-----+-+-+----...----+ v +-----+-+----...----+ | DPH |3| Payload | +-----+-+----...----+ Figure 2: Appending data path router identifiers to distinguish the data path Asai Expires 6 May 2021 [Page 8] Internet-Draft Data Path and Data Flow Layers November 2020 One approach to implement this functionality is prepending, appending, or XOR-ing device identifiers like in-band network telemetry or in-situ OAM [I-D.ietf-ippm-ioam-data] by data path layer protocol's routers. Figure 2 shows an example of in-band trajectory monitoring. A router that handles a data path layer protocol appends the router identifier to the header. In case the upper-layer protocol does not require the path information but path change events, the router can apply an XOR operation with a hashed identifier to a fixed-length field. Other alternative approaches may be used. The latter approach separates the control plane and the data plane. The control plane manages the data path, and the data plane monitors if packets pass through the dedicated data path. The data path control may leverage underlay protocols such as Segment Routing. 3.1.2. Waypoint management The data path layer may support waypoint management functionality. The in-band trajectory monitoring functionality described above does not provide the functionality to designate the data path's waypoints. However, some middleboxes such as firewalls and in-network computing require to designate waypoints to activate the in-network functions. A data path layer protocol may define a specification to control the waypoints of a data path. There are two approaches to designate waypoints over the Internet layer; 1) setting a waypoint as the destination IP address and 2) using routing technologies such as source routing and policy-based routing. The former approach includes Network Address Translation (NAT) [RFC3022] and proxy services. The latter approach may leverage underlay protocols to designate waypoints, such as Segment Routing and IPv6 Type 2 Routing Header [RFC6275]. Other alternative approaches may be used in a data path layer protocol. 3.1.3. Bidirectional connection establishment The data path layer should support both unidirectional and bidirectional paths. A bidirectional path may be symmetric or asymmetric. As the characteristics of unidirectional and bidirectional paths are different, some data path layer protocols may only support either unidirectional or bidirectional paths. A data path protocol supporting bidirectional data paths should implement a handshake mechanism to establish a bidirectional connection, such as a 3-way handshake of TCP and a 4-way handshake of SCTP. It may provide a 0-RTT connection establishment feature such as TLS 1.3 [RFC8446] and TCP Fast Open [RFC7413]. Asai Expires 6 May 2021 [Page 9] Internet-Draft Data Path and Data Flow Layers November 2020 3.1.4. Data path quality (congestion) monitoring and congestion control The data path layer should implement congestion control. However, Data path layer protocols supporting only unidirectional paths may not implement congestion control because it cannot implement congestion or data path quality reporting. Congestion control is performed based on data path quality or congestion reporting from the receiver end-host or intermediate nodes that process a data path layer protocol. Data path quality or congestion signals may be packet losses, delay, or ECN, as used in many transport layer protocols. Other signals or metrics, such as in-band network telemetry information, may be used. 3.1.5. Data flow multiplexing The data path layer enables us to collectively handle different characteristics (e.g., service level requirements) of transport layer protocols such as stream and datagram protocols. 3.1.6. Packet Duplication On a lossy data path, a data path layer protocol may implement packet duplication for improving reliability. However, the data path layer should not provide retransmission because it requires significant resources. 3.2. Data Flow Layer The data flow layer may implement various functions for end-to-end data communication over the data path layer. Data flow layer protocols may be stream, datagram, or message-oriented protocols. Middleboxes, MEC nodes, or in-network computing nodes may process data flow layer protocols. Therefore, a node processing data flow layer protocols should be as ``smart'' as end-hosts. A data flow layer protocol may implement a retransmission function for reliable data communication, a flow control mechanism for receive-buffer management, flow prioritization for effective network resource utilization, a security extension such as TLS and DTLS, and a multipath transport protocol using multiple bidirectional paths over the data path layer. Asai Expires 6 May 2021 [Page 10] Internet-Draft Data Path and Data Flow Layers November 2020 3.2.1. Retransmission for reliable data communication A data flow layer protocol may provide retransmission for reliable data communication. To this end, a node implementing the data flow layer protocol must equip a transmit buffer for retransmission to retransmit lost corrupted packets. It must also equip a receive buffer to reassemble a stream and a message from a sequence of packets in a stream and message-oriented data flow layer protocols. The receive buffer also handles packet reordering and duplication. 3.2.2. Flow control for receive-buffer management Flow control is necessary for receive-buffer management. Therefore, a data flow layer protocol may implement the flow control mechanism. A receiver node advertises the available receive-buffer size in the data flow layer, like TCP's window size, when implementing the flow control mechanism. A sender node controls the transmission so that transmitted data do not exceed the receive-buffer size. 3.2.3. Flow prioritization The prioritization of data flows multiplexed in a data path layer protocol may be implemented on the data flow layer using the data path layer information, such as monitored data path quality or congestion. A data flow layer protocol may provide a service code point or priority so that nodes processing the data flow protocol discriminate a flow. 3.2.4. End-to-end security A data flow layer protocol may implement the end-to-end security function. TLS and DTLS can be used for stream and datagram protocols, respectively. 3.2.5. Inverse multiplexing for multipath protocols A multipath data flow protocol may leverage multiple bidirectional data paths established by data path layer protocols. The data flow layer is responsible for the inverse multiplexing functionality. Therefore, the multipath data flow protocol divides a stream, a message, or a datagram into these multiple data paths. Note that the data path layer performs congestion control for each data path, while the data flow layer performs flow control. Asai Expires 6 May 2021 [Page 11] Internet-Draft Data Path and Data Flow Layers November 2020 4. Use Cases This document does not specify any data path protocols or data flow protocols, but the data path and data flow layers' architectural design. For better understanding, this section describes the use cases of the data path and the data flow layers. In the use cases, a data path router (DPR) and a data flow layer node (DFN) denote a router that processes a data path layer protocol and a node that processes a data flow layer protocol, respectively. 4.1. Multipath Transport Protocols Hosts A and B communicate with each other over multiple data paths; Path R1-DPR3-DPR2 and Path DPR4-DPR2. R1 is an IP router. DPR2, DPR3, and DPR4 are data path routers that treat data path layer protocols. *----* *------* +--| R1 |-----| DPR3 |--+ +--------+_/ *----* *------* \_*------* +--------+ | Host A |_ _| DPR2 |-----| Host B | +--------+ \ *------* / *------* +--------+ +-------------| DPR4 |--+ *------* Figure 3: An example of multipath data communication Figure 3 shows an example of multipath data communication over two data paths. The end-hosts A and B establish two bidirectional data paths; A-R1-DPR3-R2-B and A-DPR4-DPR2-B, and they use a data flow layer protocol over these data paths for end-to-end communication. The data path layer protocols monitor the data path quality and perform congestion control for each data path. The data flow layer protocol performs flow control and inverse multiplexing into these data paths. Multipath transport protocols may leverage in-band trajectory monitoring to detect a shared waypoint. We assume that the data path routers manipulate the header of a data path layer protocol. They add the router identifier to the data path layer protocol's header to report the trajectory to the end-hosts. When sending packets from end-host A to end-host B over these paths, each packet reports trajectory A-DPR3-DPR2-B or A-DPR4-DPR2-B. In this way, end-host B recognizes two different data paths and detects a shared data path router, DPR2, on the multiple paths, potentially a single point of failure for end-to-end communication. Asai Expires 6 May 2021 [Page 12] Internet-Draft Data Path and Data Flow Layers November 2020 4.2. Congestion Control Acceleration Some TCP congestion control acceleration functions proxy TCP sessions to shorten the perspective latency. The acceleration functions acknowledge receipt of packets. Using a loss-based congestion control algorithm, both congestion control and flow control use the acknowledgments (ACKs). For congestion control, missing ACKs report packet losses, and consequently, they present the data path quality to control the transmission rate to avoid congestion. For flow control, ACKs report successful data delivery. Then, the sender can release part of the transmit buffer. Otherwise, the sender retransmits the lost data. +-------------------+ +-------------------+ | Application layer |<------------------------->| Application layer | +-------------------+ +-------------------+ | Data flow layer |<------------------------->| Data flow layer | +-------------------+ +-------------------+ +-------------------+ | Data path layer |<->| Data path layer |<->| Data path layer | +-------------------+ +-------------------+ +-------------------+ | Internet layer |<->| Internet layer |<->| Internet layer | +-------------------+ +-------------------+ +-------------------+ | Link layer |<->| Link layer |<->| Link layer | +-------------------+ +-------------------+ +-------------------+ Sender Accelerator Receiver Figure 4: An example of a communication model for congestion control acceleration Figure 4 illustrates an example of a communication model for congestion control acceleration using the data path layer. The accelerator or the receiver reports the data path quality to the sender on the data path layer to perform congestion control. There are various ways to measure data path quality. For example, data path routers may use the buffer capacity in the same way as ECN. If a data path router can detect packet losses for a connection of data path layer protocols, the packet losses or statistics may be used to report the data path quality. The data path quality report by the accelerator enables the fast response of congestion control algorithms. The data flow layer is responsible for retransmission for reliable communication and flow control for receive-buffer management. Asai Expires 6 May 2021 [Page 13] Internet-Draft Data Path and Data Flow Layers November 2020 4.3. In-Network Computing In-network computing [I-D.kunze-coin-industrial-use-cases] is a novel distributed computing paradigm. It requires to be aware of the data path's waypoints because computing components are placed in between end-hosts. The message-oriented protocol may adopt the pub/sub communication model, widely used in machine-to-machine communication. The data path layer establishes a data path while designating the waypoints to perform in-network computing. The data flow layer over the data path implements a message-oriented protocol or a stream protocol to feed data into in-network computing nodes. The message- oriented protocol may adopt the pub/sub communication model, widely used in machine-to-machine communication. App., DF, DP, IP, and Link denote the application layer, the data flow layer, the data path layer, the IP, and the link layer, respectively. H1 and H2 are end-hosts, C1 and C2 are in-network computing nodes, P1 is a data path router, and R1 is an IP router. +------+ +------+ | App. |<--------------------------------------------->| App. | +------+ +------+ +------+ +------+ | DF |<------------>| DF |<------------>| DF |<->| DF | +------+ +------+ +------+ +------+ +------+ | DP |<->| DP |<->| DP |<------------>| DP |<->| DP | +------+ +------+ +------+ +------+ +------+ +------+ | IP |<->| IP |<->| IP |<->| IP |<->| IP |<->| IP | +------+ +------+ +------+ +------+ +------+ +------+ | Link |<->| Link |<->| Link |<->| Link |<->| Link |<->| Link | +------+ +------+ +------+ +------+ +------+ +------+ +----+ *----* *----* *----* *----* +----+ | H1 |-----| P1 |-----| C1 |-----| R1 |-----| C2 |-----| H2 | +----+ *----* *----* *----* *----* +----+ Figure 5: An example of communication model of in-network computing Figure 5 illustrates an example of the communication model of in- network computing. A data path is established between H1 and H2. A data path layer protocol designates C1 and C2 as the waypoints. Over the established data path, H1 transmits messages to H2 using a data flow layer protocol. C1 and C2 process the messages according to the programs running on C1 and C2. Asai Expires 6 May 2021 [Page 14] Internet-Draft Data Path and Data Flow Layers November 2020 4.4. Flow Arbitration The separation of the data path and the data flow layer enables flow- level prioritization. As the data path layer is responsible for congestion control, the multiplexed data flows over a data path can collectively perform resource arbitration for the data path bandwidth capacity. For example, a data path multiplexes two data flows; one of them requires a constant data rate, and the other is tolerant of delayed data delivery. Flow control can prioritize the former data flow and decrease the transmission rate when the data path layer detects congestion. This flow arbitration is crucial in coexisting deadline- based and best-effort flows. H1, H2, H3, and H4 are end-hosts. R1, R2, and R3 are IP routers. P1 is a data path router that support the data path quality monitoring function. +----+ *----* +----+ | H1 |--+ +--| R2 |-----| H3 | +----+ \_*----* *----*_/ *----* +----+ _| R1 |-----| P1 |_ +----+ / *----* *----* \ *----* +----+ | H2 |--+ +--| R3 |-----| H4 | +----+ *----* +----+ Figure 6: An example of flow arbitration over multiple data paths Moreover, the data path layer may support data path quality monitoring for multiple data paths. If data path routers monitor multiple data paths' bandwidth capacity, they can report the estimated capacity to arbitrate multiple flows over the data paths. Figure 6 shows an example flow arbitration over multiple data paths. Suppose data flows X and Y are over the data paths H1-R1-P1-R2-H3 and H2-R1-P1-R3-H4, respectively; the data path router P1 can monitor the data path quality such as packet losses for these data paths. If the bandwidth utilization reaches the capacity, the data path router requests resource arbitration. A flow may reduce the data rate using the flow control mechanism in the data flow layer if its priority is not high. Thus, these two flows can autonomously perform the flow arbitration. This flow arbitration may fail and perform best-effort communication, such in case both flows are the high priority and do not reduce the data rate. Asai Expires 6 May 2021 [Page 15] Internet-Draft Data Path and Data Flow Layers November 2020 5. Implementation Considerations Although this document does not specify the data path layer and the data flow layer protocols, it discusses the implementation of these protocols' specifications. The data path layer may be implemented over UDP for interoperability with the current Internet operations because other protocols than ICMP, TCP, and UDP may be filtered on the Internet. Data path layer protocols must implement the maximum transmission unit (MTU) discovery [RFC8899]. LH: Link-layer protocol header, IPH: IP header, UDPH: UDP header, DPH: Data path layer protocol header, DFH: Data flow layer protocol header +----+-----+------+-----+-----+------------------+-----------+ | LH | IPH | UDPH | DPH | DFH | Payload | (Trailer) | +----+-----+------+-----+-----+------------------+-----------+ Figure 7: An implementation of data path layer and data flow layer protocols over UDP Figure 7 illustrates an example packet format of data path layer and data flow layer protocols over UDP. In this figure, the UDP header is not intended to provide the transport layer's functionality but is introduced for interoperability with existing middleboxes on the Internet. A data path layer protocol may use hop-by-hop UDP connections to designate waypoints like an overlay network. Otherwise, data path routers require to leverage routing technologies such as Segment Routing and policy-based routing to support waypoint management. 6. IANA Considerations This document does not have IANA Considerations. 7. Security Considerations End-to-end encryption becomes critical to Internet protocols for privacy and security. The data path layer must be visible to intermediate nodes, such as routers and middleboxes, by design to process and manipulate a data path layer protocol. Therefore, this document proposes to implement transport layer security at the data flow layer. It exposes data path information. Therefore, data path layer protocols must not include privacy-sensitive information in the protocol header. Asai Expires 6 May 2021 [Page 16] Internet-Draft Data Path and Data Flow Layers November 2020 Data path layer protocols may not be visible to intermediate nodes if an underlay protocol encrypts the payload. For example, IPsec [RFC6071] encrypts the payload of IP datagrams. In such cases, intermediate nodes cannot process or manipulate data path layer protocols. 8. Acknowledgements We thank Kenichi Murata, Ryokichi Onishi, Yusuke Doi, and Masahiro Ishiyama for their comments and review of this document. 9. References 9.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>. [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. Asai Expires 6 May 2021 [Page 17] Internet-Draft Data Path and Data Flow Layers November 2020 [RFC2768] Aiken, B., Strassner, J., Carpenter, B., Foster, I., Lynch, C., Mambretti, J., Moore, R., and B. Teitelbaum, "Network Policy and Services: A Report of a Workshop on Middleware", RFC 2768, DOI 10.17487/RFC2768, February 2000, <https://www.rfc-editor.org/info/rfc2768>. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. Asai Expires 6 May 2021 [Page 18] Internet-Draft Data Path and Data Flow Layers November 2020 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>. [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>. 9.2. Informative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields for In-situ OAM", Work in Progress, Internet-Draft, draft- ietf-ippm-ioam-data-10, 13 July 2020, <http://www.ietf.org/internet-drafts/draft-ietf-ippm-ioam- data-10.txt>. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channels", Work in Progress, Internet-Draft, draft-ietf- rtcweb-data-channel-13, 4 January 2015, <http://www.ietf.org/internet-drafts/draft-ietf-rtcweb- data-channel-13.txt>. [I-D.kunze-coin-industrial-use-cases] Kunze, I. and K. Wehrle, "Industrial Use Cases for In- Network Computing", Work in Progress, Internet-Draft, draft-kunze-coin-industrial-use-cases-03, 8 September 2020, <http://www.ietf.org/internet-drafts/draft-kunze- coin-industrial-use-cases-03.txt>. Author's Address Asai Expires 6 May 2021 [Page 19] Internet-Draft Data Path and Data Flow Layers November 2020 Hirochika Asai Preferred Networks, Inc. 1-6-1 Otemachi, Chiyoda, Tokyo 100-0004 Japan Email: panda@wide.ad.jp Asai Expires 6 May 2021 [Page 20]