The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTOChangchun University of Science and TechnologyChangchun130022P. R. Chinamore60@163.comChangchun University of Science and TechnologyChangchun130022P. R. Chinaqihui@cust.edu.cnChangchun University of Science and TechnologyChangchun130022P. R. Chinadixiaoqiang@cust.edu.cn
Transport
altoSDN, Controller, MPTCP, MPQUIC, ALTOThis document aims to study and implement MPTCP (MultiPath Transmission Control Protocol) and MPQUIC (MultiPath Quick UDP Internet Connection) using ALTO for software-defined networking. In an software-defined network, ALTO (application layer traffic optimization) server collects network cost indicators (including link delay, availability, network traffic, bandwidth, etc.) and the controller extract MPTCP or MPQUIC packet header and allocate MPTCP or MPQUIC packet to suitable transmission path according to the obtained network state, reducing the probability of transmission path congestion and improving path utilization. The traditional TCP protocol only uses one path between the server and the client to transmit data. In order to realize the simultaneous transmission of data between multiple paths between the server and the client, the International Internet Engineering Task Force proposed and standardized MultiPath TCP (MPTCP) . MPTCP realizes 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 in order to increase the MPTCP protocol. Therefore, 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 Quick UDP Internet Connection (QUIC) . QUIC has many new features, such as: 0-RTT, forward error correction, connection migration, flexible congestion control, multiplexing without head-of-line blocking, easy deployment, and more. MultiPath QUIC (MPQUIC) is a multi-path transmission protocol designed on the basis of QUIC. Software Defined Network (SDN) is a new network innovation architecture implemented by virtualization. By separating control and forwarding, it breaks the closedness of traditional network equipment, and uses programming to make network management more concise and efficient. flexible. Application Layer Traffic Optimization (ALTO) can obtain and provide global network information to the controller, such as network traffic, link delay, etc. The main multipath transmission protocols MPTCP and MPQUIC have their own characteristics . The application of multipath transmission in SDN can greatly improve the transmission throughput.The purpose of this research is to realize the coupling control of MPTCP or MPQUIC sub-flows in software-defined networks, and allocate the optimal path according to the network status information obtained by ALTO, so as to improve bandwidth utilization and resource allocation fairness, effectively alleviate network congestion and achieve load balancing between paths.At present, some scholars have studied the model of deploying MPTCP or MPQUIC in software-defined network, \ \ , but their SDN controller cannot manage the headers of MPTCP and MPQUIC data packets at the same time, and cannot achieve unified management of MPTCP and MPQUIC links.The ALTO protocol can easily obtain various network states (including multiple SDNs, dynamic networks) from SDN without the internal details of the network provider, and deliver controller decisions \ , which is already a mature solution.The purpose of this document is to:Describe the model that the controller can extract 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. 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 .In a software-defined network, the default controller cannot extract MPTCP or MPQUIC data packets. If MPTCP or MPQUIC are deployed and there are multiple transmission paths, the controller only selects one of the paths to transmit data, and the other paths are idle (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.The principle of multi-path transmission control model based on SDN controller MPTCP and MPQUIC using ALTO is shown in Figure 1.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 or CID of MPTCP and MPQUIC according to the data packet (For details, see Section 4), 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.
The flow chart of the SDN-based MPTCP-aware and MPQUIC-aware multi-path transmission control model using ALTO is shown in Figure 2. The transmission control model is realized by the following steps:
Step 1. 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 <key:value>; 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 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 2. When the data packet p of a certain MPTCP or MPQUIC subflow 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 12; 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 3. 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 7, if not, go to step 4.
Step 4. 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 5. 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,1),...,s_(i,j),...>, s_(i,j) represents the i available path The switch numbered j, where i belong to [1,m],j belong to [1,T].
Step 6. 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 <key:value> The form is saved to the mapping table flows, and go to step 10.
Step 7. 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 8. 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 9. 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 10. 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=<s_(i,1),...,s_(i,j-1),s_(i.j),s_(i,j+1),...>, 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 11. The controller sends the reverse flow table to all switches on the route route and sets the route route=r_i=<s_(i,1),...,s_(i,j-1),s_(i,j),s_(i,j+1),...>, 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 12. 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 2 is executed when the forwarding fails or the processing of other subsequent data packets returns.
The transmission control model uses the default security mechanism of SDN\ALTO\MPTCP\MPQUIC in the network, and does not modify the default security mechanisms such as encryption and authentication models , , and .TBD.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 multiple software-defined networks, and can also be applied to satellite networks, marine networks, etc. to transmit data.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.Multipath TCP (MPTCP) Application Interface ConsiderationsMultipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications.Application-Layer Traffic Optimization (ALTO) ProtocolApplications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.Software-Defined Networking (SDN): Layers and Architecture TerminologySoftware-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.TCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.Multipath Extension for QUICConinck Q D , Bonaventure O . MultipathTester: Comparing MPTCP and MPQUIC in Mobile Environments[C]// 2019 Network Traffic Measurement and Analysis Conference (TMA). 2019.Kumar P , Chen J , Dezfouli B . QuicSDN: Transitioning from TCP to QUIC for Southbound Communication in SDNs[J]. 2021.Faigl, Z. , Z. Szabo , and R. Schulcz . "Application-layer traffic optimization in software-defined mobile networks: A proof-of-concept implementation." IEEE(2014):1-6.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.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.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,