alto Z. Xing Internet-Draft H. Qi Intended status: Standards Track X. Di Expires: 24 January 2024 Changchun University of Science and Technology 23 July 2023 The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO draft-xing-alto-sdn-controller-aware-mptcp-mpquic-08 Abstract This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. 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 24 January 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Xing, et al. Expires 24 January 2024 [Page 1] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Original transmission control mode of MPTCP or MPQUIC in SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Delivering functions by ALTO . . . . . . . . . . . . . . . . 4 5. Architectural Framework . . . . . . . . . . . . . . . . . . . 4 6. Implementation and Deployment . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The conventional TCP protocol only uses one path between a server and a client to exchange data. In order to realize the simultaneous transmission of data via multiple paths between a server and a client, the IETF standardized MPTCP [RFC8684] . MPTCP uses multiple paths between hosts to transmit data at the same time, but it is necessary to modify the operating system kernel to change the protocol stack of both parties or use an application proxy [RFC8803] in order to increase the MPTCP protocol. MPTCP has disadvantages such as difficulty in deployment. In order to solve the drawbacks in the transmission network and adapt to the faster development of the Internet, Google proposed the HTTP/3 protocol which is QUIC [RFC9000]. QUIC has many new features, such as: 0-RTT, forward error correction, connection migration, flexible congestion control, multiplexing without head-of-line blocking, and more. MPQUIC [MPQUIC] is a multi-path transmission protocol designed on the basis of QUIC. SDN [RFC7149] is a new network innovation architecture. By separating control and forwarding, it breaks the closedness of traditional network equipment, and uses programming to make network management more concise and programmability. ALTO [RFC7285] can Xing, et al. Expires 24 January 2024 [Page 2] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 obtain and expose global network information to a controller, such as network traffic, link delay, etc. MPTCP and MPQUIC have their own characteristics [MultipathTester]. Realize the coupling control of MPTCP and MPQUIC subflows in the context of SDN, and obtain the network state information and allocate the optimal path according to the information conveyed in the ALTO Protocol, so as to improve the bandwidth utilization and resource allocation fairness, effectively alleviate the network congestion and realize the load balance between paths. At present, some scholars have studied the model of deploying MPTCP or MPQUIC in software-defined network, [QUICSDN] \ [SDN_for_MPTCP] \ [SDN_MPTCP], but their SDN controller cannot manage the headers of MPTCP and MPQUIC data packets at the same time, and cannot manage of MPTCP and MPQUIC links at the same time.The ALTO Protocol can easily obtain various network states (including multiple SDNs, dynamic networks) from controller without the internal details of the network provider, and deliver controller decisions [SDN_ALTO_proof] \ [SDN_ALTO], which is already a successful solution. The purpose of this document is to: Describe the model that an SDN controller can use to MPTCP or MPQUIC data packets in the software-defined network. According to the global information obtained by the AlTO, the controller allocates MPTCP or MPQUIC data packets with efficient transmission path. 2. Terminology 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 [RFC2119]. 3. Original transmission control mode of MPTCP or MPQUIC in SDN In a software-defined network, the original controller cannot extract MPTCP or MPQUIC data packets. If MPTCP or MPQUIC as a server/client is deployed in SDN with a original controller and there are multiple transmission paths, the controller only selects one of the paths to exchange data, and the other paths are "idle" (i.e., there is only one path to transmit data). The utilization rate is low, and it is impossible to transmit data on multiple paths at the same time, resulting in low transmission efficiency. Xing, et al. Expires 24 January 2024 [Page 3] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 4. Delivering functions by ALTO An ALTO server is used to obtain network status information, and an SDN controller is considered as an ALTO client. The ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate). 5. Architectural Framework The architectural framework of multi-path transmission model based on SDN controller MPTCP and MPQUIC using ALTO is shown in Figure 1. Xing, et al. Expires 24 January 2024 [Page 4] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 +--------------Network Status Acquisition----------------+ | ALTO Server | | (Network topology, traffic distribution, | | link delay/bandwidth) | +---------------^----------------------------------------+ | +------ALTO Protocol----+ | +-----------Control Plane-(ALTO Client)-v----------------+ | +-------------------------------------------+ | | | Extract MPTCP / MPQUIC header module | | | | (Extract packet header) | | | +---------------------+---------------------+ | | | | | token or CID | | | | | +---------------------v---------------------+ | | | Path selection module | | | +--> (Select the appropriate path from <--+ | | | | the candidate paths - assigned path) | | | | | +---------------------+---------------------+ | | | | | Allocated | | | +-----Allocate path------+ path | | | | | | | | | +---------v----------+ +-----------v--------+ | | | | | Flow rules | | Link management | | | | | | generation module | | module | | | | | | (All switch | |(Manage the mapping +--+ | | | | assignment flow | |table flows and save| | | | | tables for the | | the connection | | | | | selected path) | | information) | | | | +---------+----------| +--------------------+ | +-|------------|-----------------------------------------+ Network | status +----Flow rules-----+ | | | +---------------Data Plane----v-------------+ | | +------------------+ +------------------+ | | | | SDN switch | | SDN switch | | +--+ | (Forwarding flow | | (Forwarding flow | | | | rules and obtain | | rules and obtain | | | | network status) | | network status) | | | +------------------+ +------------------+ | +-------------------------------------------+ Figure 1: Schematic diagram of SDN-based MPTCP-aware and MPQUIC-aware transmission control model using ALTO Xing, et al. Expires 24 January 2024 [Page 5] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 The SDN-based MPTCP and MPQUIC transmission control using ALTO model consists of three parts. * The first part is the network status acquisition module, which acquires basic network status information from ALTO. * The second part is the control plane, that is the SDN controller, also the client of ALTO, which includes extracting MPTCP / MPQUIC header module, path selection module, flow rules generation module and link management module. The main function is to extract the header identifier token of MPTCP (or CID of MPQUIC) according to the data packet (token from MPTCP unencrypted header and CID from MPQUIC unencrypted header, see Figure 2-3 for details), obtain the global information of the whole network according to ALTO and allocate suitable paths and put flow rules to switches according to the global information of the entire network, and manage the links of the entire network at the same time. * The third part is the data plane which is some OpenFlow switches. It executes the flow rules issued by the controller and realizes the forwarding of data packets. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-----+-+---------------+ | Kind | Length = 12 |Subtype| |B| Address ID | +---------------+---------------+-------+-----+-+---------------+ | Receiver's Token (32 bits) | +---------------------------------------------------------------+ | Sender's Random Number (32 bits) | +---------------------------------------------------------------+ Figure 2: MPTCP Header Packet Format Long Header Packet { Header Form (1) = 1, Fixed Bit (1) = 1, Long Packet Type (2), Type-Specific Bits (4), Version (32), Destination Connection ID Length (8), Destination Connection ID (0..160), Source Connection ID Length (8), Source Connection ID (0..160), Type-Specific Payload (..), } Figure 3: QUIC Header Packet Format Xing, et al. Expires 24 January 2024 [Page 6] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 6. Implementation and Deployment +---------------------+ +----------------------------+ | Create a flow table | |The packet p arrives at s1, | +----------+----------+ | and s1 performs flow rules <---+ | | item matching on p | | | +--------------+-------------+ | +----------v----------+ | | |Obtain Network Status| | | |Extract packet header|<-----+ | | +----------+----------+ | v | | | /\ | +-----------+------------+ | / \ | | | | +---NO-----Match successful? | v v v \ / | /\ /\ /\ \/ | / \ / \ / \ YES | MP_CAPABLE CID MP_JOIN | | \ / \ / \ / | | \/ \/ \/ +------------v--------------+ | | | | |Forward packet according to|-+ | | v |the flow rules instruction | | | +------+------+ +------------^--------------+ | | |Extract token| | | | +------+------+ | | | | | | | | | | +------v----+ +-----v-------+ | | | key=Q+CID | | key=T+token | | | +-----+-----+ +------+------+ | | | | | | +------+-------+ | | | | | v | | /\ | | / \ | | Is there a key | | +--in the flow table?--+ | | | \ / | | | NO \/ YES | | | | | | +------v----------+ +-------v------+ | | |Extract source IP| | | | | |destination IP | | Path of all | | | |source port | | subflows in | | | |destination port | | value,RL | | | |and subflow | | | | | |identifier | | | | Xing, et al. Expires 24 January 2024 [Page 7] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 | +-------+---------+ +-------+------+ | | | | | | | | | | +-------v---------+ +-------v-------+ | | |Add the subflow | |Extract the | | | |meta information | |subflow meta | | | |to value and then| |information | | | |save | |and add it to | | | |to the flow rules| |value | | | +-------+---------+ +-------+-------+ | +-------->| | | | | | +-------v---------+ +-------v------+ | | | |Allocate a new| | |Allocate the | |path to p, and| | |first path to p | |route does not| | |route | |belong to RL | | +-------+---------+ +-------+------+ | | | | +----------+----------+ | | | | | +---------------------v----------------------+ | |Put forward and reverse flow rules to switch|----+ +--------------------------------------------+ Figure 4: The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware multi-path transmission control model using ALTO The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware multi- path transmission control model using ALTO is shown in Figure 4. The transmission control model is realized by the following steps: * Step 1. The ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate, etc.), which are recorded as: G (V, e), network topology g, V is the vertex and E is the edge. * Step 2. The connection ID(CID) is the connection identifier of MPQUIC, and can be obtained from the QUIC header(connection ID, see Figure 3 for details). The SDN controller creates a mapping table flows for storing MPTCP or MPQUIC connection information, and each entry structure of the mapping table flows is ; wherein key is the unique identifier of MPTCP or MPQUIC connection, When the packet comes from MPTCP, key=T+token; and when the packet comes from MPQUIC, key=Q+CID (The letters T and Q are used to distinguish MPTCP and MPQUIC). value is a set of sub-stream meta-information, each item in the set is a sub-stream Xing, et al. Expires 24 January 2024 [Page 8] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 meta-information; each sub-stream meta-information consists of source IP, destination IP, source port, destination port, MPTCP (or MPQUIC) sub-stream identifier and the path route composition. * Step 3. When the data packet p from the MPTCP or MPQUIC server reaches the first switch s1, the first switch s1 extracts the header field of the data packet p, extracts the source IP, source port, destination IP and the destination port matches the source IP, source port, destination IP and destination port of the flow table in the first switch s1 respectively, and judges whether the matching is successful. If so, go to step 13; if not, then the first switch s1 encapsulates the data packet p and forwards it to the SDN controller, and at the same time adds the data packet p to the waiting queue. * Step 4. After receiving the data packet p, the SDN controller extracts the header field of the data packet p, extracts the connection identifier of the data packet, and generates a key value, where when the data packet comes from MPTCP, key=T+token; When the packet comes from MPQUIC, key=Q+CID. Then query whether there is a key in the mapping table flows, if so, go to step 8, if not, go to step 5. * Step 5. Extract the source IP, destination IP, source port, and destination port of the data packet p and generate a key value, where when the data packet comes from MPTCP, key=T+token; and when the data packet comes from MPQUIC, key=Q+CID . * Step 6. ALTO to get basic network information. The controller calculates the threshold T according to the global network state information (network topology, number of switches, etc.). Using the depth-first traversal algorithm, find the available path set R={r_1,...,r_i,...,r_m } from all source nodes whose length does not exceed a certain threshold T to the destination node, r_i is the i available path, in the available path set Select a shortest path r_i in R as the path route of the sub-flow, where r_i=, s_(i,j) represents the i available path The switch numbered j, where i belong to [1,m],j belong to [1,T]. Xing, et al. Expires 24 January 2024 [Page 9] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 * Step 7. Use the MPTCP and MPQUIC connection identifiers as the unique identifier key of the MPTCP and MPQUIC connections, where the key is the unique identifier of the MPTCP and MPQUIC connections. When the data packet comes from MPTCP, key=T+token; and the data packet comes from In MPQUIC, key=Q+CID. The source IP, source port, destination IP, destination port, MPTCP, MPQUIC sub-flow identifier and path route of the data packet p are added to the set value of sub-flow meta information as sub-flow meta- information, and then the The form is saved to the mapping table flows, and go to step 11. * Step 8. The SDN controller updates the flows table according to the global information of the network, and takes out the value from the connection identifier, and then composes all paths in the value into a set RL={r_1,r_2,...}. * Step 9. The SDN controller searches for a suitable disjoint path for the data packet p according to the method in Step 5, and sets the found path as route=r_i, where r_i not belong to RL. * Step 10. Extract the source IP, destination IP, source port, destination port, and MPTCP, MPQUIC sub-flow identifiers of the data packet p, and convert the source IP, source port, destination IP, destination port, MPTCP (or MPQUIC) sub-flow identifiers and the path route is added to the value as sub-flow meta information. * Step 11. The SDN controller uses the source IP, source port, destination IP and destination port to issue the flow table to all switches in the route route, and set the route route=r_i=, for the switch s_(i,j), the flow entry sent is the source IP, source port to the destination, the data packets of IP and destination port are forwarded to s_(i,j+1). * Step 12. The controller sends the reverse flow table to all switches on the route route and sets the route route=r_i=, for the switch s_(i,j) ,the flow table entry sent is to forward the data packets from the destination IP, destination port to source IP, and source port to s_(i,j-1). * Step 13. The switch already contains a flow entry for processing the data packet p, and forwards the data packet according to the rules defined by the flow entry, and completes the processing of the data packet p. Step 3 is executed when the forwarding fails or the processing of other subsequent data packets returns. Xing, et al. Expires 24 January 2024 [Page 10] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 7. Security Considerations The transmission control model uses the default security mechanism of SDN\ALTO\MPTCP\QUIC in the network, and does not modify the default security mechanisms such as encryption and authentication models [RFC7149], [RFC7285], [RFC6824] and [RFC9000]. 8. IANA Considerations TBD. 9. Discussion The SDN transmission control model proposed in this document can simultaneously identify MPTCP and MPQUIC data packets and allocate optimal paths according to the network status obtained by ALTO, which expands the application scope of MPTCP and MPQUIC. In order to verify its comprehensive transmission performance, a fat-tree data center network is designed. The transmission control method proposed in this document improves the throughput by about 3 times compared to the default transmission control method. This model also supports data transmission in a software-defined networks with multiple path, and can also be applied to satellite networks, marine networks, etc. to transmit data. 10. Acknowledgments The authors thank all reviewers for their comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, . Xing, et al. Expires 24 January 2024 [Page 11] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [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, . [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", RFC 8803, DOI 10.17487/RFC8803, July 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 11.2. Informative References [MPQUIC] "Multipath Extension for QUIC", . [MultipathTester] "Coninck Q D , Bonaventure O . MultipathTester: Comparing MPTCP and MPQUIC in Mobile Environments[C]// 2019 Network Traffic Measurement and Analysis Conference (TMA). 2019.", . [QUICSDN] "Kumar P , Chen J , Dezfouli B . QuicSDN: Transitioning from TCP to QUIC for Southbound Communication in SDNs[J]. 2021.", . [SDN_ALTO] "V. K. Gurbani, M. Scharf, T. V. Lakshman, V. Hilt and E. Marocco, "Abstracting network state in Software Defined Networks (SDN) for rendezvous services," 2012 IEEE International Conference on Communications (ICC), 2012, pp. 6627-6632.", . [SDN_ALTO_proof] "Faigl, Z. , Z. Szabo , and R. Schulcz . "Application- layer traffic optimization in software-defined mobile Xing, et al. Expires 24 January 2024 [Page 12] Internet-Draft SDN MPTCP-aware MPQUIC-aware using ALTO July 2023 networks: A proof-of-concept implementation." IEEE(2014):1-6.", . [SDN_for_MPTCP] "Hussein A , Elhajj I H , Chehab A , et al. SDN for MPTCP: An enhanced architecture for large data transfers in datacenters[C]// IEEE International Conference on Communications. IEEE, 2017.", . [SDN_MPTCP] "7. K. Gao, C. Xu, J. Qin, S. Yang, L. Zhong and G. Muntean, "QoS-driven Path Selection for MPTCP: A Scalable SDN-assisted Approach," 2019 IEEE Wireless Communications and Networking Conference (WCNC), 2019, pp. 1-6,", . Authors' Addresses Ziyang Xing Changchun University of Science and Technology Changchun Email: xzynet@gmail.com Hui Qi Changchun University of Science and Technology Changchun Email: qihui@cust.edu.cn Xiaoqiang Di Changchun University of Science and Technology Changchun Email: dixiaoqiang@cust.edu.cn Xing, et al. Expires 24 January 2024 [Page 13]