| Internet-Draft | ps of overlay routing | July 2022 |
| Deng, et al. | Expires 9 January 2023 | [Page] |
This document considers the limitations of existing technologies in addressing the challenges of low network latency. It analyzes the problem of signaling redundancy on control plane and problem of non-global optimal path selection policy for overlay network and explores possible solutions.¶
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 9 January 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
There are emerging mobile applications, such as online games, audio and video, and AR (augmented reality)/VR (virtual reality), which have higher requirements for low latency, throughput, and packet loss. With the rapid development of mobile Internet services, the research on mobile Internet architecture has become a hot topic. The terminal industry, represented by device-edge-pipe-cloud devices with ultimate interoperability experience in all-scenario, poses great challenges to the current Internet and requires disruptive technologies to support transformation.¶
This document analyzes some existing technologies related to improving the user experience of real-time applications, and hope to find a solution to improve the end-to-end transmission experience to meet the increasing requirements of network delay.¶
There is a significant amount of previous work in terms of improving the end-to-end transmission performance. Some are to control the destination ends, and some are to control the network path. The relevant work is presented in this section.¶
In the request process of Global Server Load Balancer (GSLB) Based on Smart DNS, the root DNS forcibly forwards the DNS to the GSLB device. The GSLB resolves the optimal IP address based on the server load and the user's IP address, sends the DNS response to the local server, and finally sends the response to the user.¶
GSLB based on smart DNS enables an application to control the destination of requests but cannot control the path to the destination. For example, if an application wants to further optimize the path requested by a user due to security or performance considerations, smart DNS cannot meet the preceding requirements.¶
The overlay network technology can further optimize the path to avoid failure or congestion in the path to a certain extent. It is an important means to improve the quality of Internet transmission and user experience and achieve high-quality transmission.¶
The Internet consists of multiple carriers, ISPs, and autonomous domains, which causes the complex business relationships between domains. The transmission paths of the Internet are affected by business relationships and is not the shortest path in the network. For example, transmission between two Asian nodes may be detoured to Europe. This increases the end-to-end latency. At the same time, the Internet routing is not aware of path performance, and thus it is difficult to avoid failure or congestion in the path, or requires a long convergence time.¶
The overlay network technology is proposed to find out the optimal path of the Internet. Software forwarding units are deployed in data centers in different areas of the Internet to connect to each other and schedule each other. In this way, a new virtual overlay network is constructed on the basis of the existing public network (underlay network). An intermediate forwarding node may be referred to as a forwarding relay or a point of presence (PoP) node.¶
Intelligent overlay routing, the key of overlay network technology, directly determines the transmission performance for users accessing the overlay network. It selects appropriate forwarding nodes on the overlay network to form an end-to-end optimal forwarding path for data transmission.¶
In the existing intelligent overlay routing technologies, the optimal path is determined by three subsystems: the ingress PoP selection system, the egress PoP selection system, and the internal overlay routing system. The optimal scheme is computed independently in each subsystem, but the local optimal doesn't mean the global optimal. The sum of each optimal scheme in subsystem can't figure out the best network path. In addition, it takes expensive cost to maintain the routing table status and invoke different systems to perform packet header encapsulation and decapsulation for subsystems.¶
This section describes in detail some possible bottlenecks encountered when dealing with low network latency.¶
Overlay routing can be divided into two segments: access segment and backbone segment. The source in the access segment obtains the address of the access controller through the DNS and requests the address of the access point (ingress or egress). The access controller selects an access point based on factors such as geographic location and latency. The backbone controller in the backbone segment updates the optimal path from any ingress to egress in real time.¶
+-----------------+
+-----------|access controller|--------------+
| +-----------------+ |
| | | |
| | | |
| | | |
| | +----+ +----+ | |
| | +------->|PoP4|-------|PoP3|<------+ | |
+---+ | | | +----+\ /+----+ | | |
|DNS| | | | | \ / | | | |
+---+ | | | | \ / | | | |
| | | | | \ | | | |
| | | | | / \ | | | |
| | | | | / \ | | | |
| | | | +----+/ \+----+ | | | +-----------+
+------+ | | |------->|PoP1|-------|PoP2|<------| | +->|destination|
|source|<-+ | | +----+ +----+ | | +-----------+
+------+ | | | |
| | | |
| | | |
| | +--------------------+ | |
| +-------|backbone conctroller|-----+ |
| +--------------------+ |
| |
access segment| backbone segment | access segment
| |
On the control plane, the source obtains the address of destination and access controller through the DNS, requests for an access point from the access controller, and sends the messages to the destination. Multiple rounds of signaling interaction with the DNS and the controller are required from connection establishment to packet transmission. As shown in the figure, five rounds of signaling interaction are needed and it is redundant.¶
+------+ +---+ +-----------------+
|source| |DNS| |access controller|
+------+ +---+ +-----------------+
| | |
| 1a. request the address | |
| of destination | |
|-------------------------------->| |
| | |
| 1b. return the address | |
|<--------------------------------| |
| | |
|-------+ | |
| |2. select overlay network| |
| | to transmit data | |
|<------+ | |
| | |
| 3a. request the address of | |
| access controller | |
|-------------------------------->| |
| | |
| 3b. return the address | |
|<--------------------------------| |
| | |
| 4a. request the ingress and |
| egress PoP from the controller |
|-------------------------------------------------------->|
| | |
| 4b. return the ingress and egress PoP |
|<--------------------------------------------------------|
| | |
| 5. Encapsulate packets based on the ingress |
| address and send the packets |
|-------------------------------------------------------->|
| | |
In the prior art, an optimal path is calculated in several parts. That is, the Internet gets the optimal routing in access segment and backbone segment, and strings them together as the optimal path. However, the optimal path calculated in this way is not an optimal end-to-end path.¶
+-+ 120.5ms +-+ 19.9ms +-+
|A|-------------|B|------------|C|
+-+ +-+ +-+
| |
| |
90ms | |4.9ms
| |
| |
+-+ +-+ +-+
|D|-------------|E|------------|F|
+-+ 153.4ms +-+ 15.3ms +-+
For example, the nearest PoP would be chosen as the access point (ingress/egress) according to the latency. Take A as the source and C as the destination, and then an optimal path is calculated by the existing overlay routing technology: A->D->E->F->C (263.7ms). However, it is clear that there is a better path here: A->B->C (140.4ms).¶
This section seeks for the possible breakthrough point to achieve lower latency and improve the user experience in real-time applications.¶
As mentioned above, the problem of signaling redundancy on control plane and problem of non-global optimal path may be the obstacles to reduce lower network latency and improve user's experience. A possible solution direction is presented below.¶
To solve the problem of non-global optimal path, the source calculates the global optimal overlay path and delivers to the destination.¶
For details, the source directly delivers routing through DNS. The DNS is redirected to the controller to request an optimal path, and the controller returns a multi-dimensional path vector. In this way, the users can control a delivery path at the source. Also, the intermediate forwarding nodes don't need to maintain any routing table, because all routing status information may be included in a private header of a data packet generated by the source.¶
Request to IANA will be added later.¶
Security issues will be considered later in the design.¶
This becomes an Appendix.¶