Internet-Draft ps of overlay routing July 2022
Deng, et al. Expires 9 January 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-deng-overlay-routing-ps-00
Published:
Intended Status:
Informational
Expires:
Authors:
S. Deng, Ed.
Huawei
G. Li
Huawei
Y. Cui
Tsinghua University

Overlay Routing Problem Statement

Abstract

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.

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 9 January 2023.

Table of Contents

1. Introduction

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.

2.1. Global Server Load Balancer Based on Smart DNS

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.

2.2. Intelligent Overlay Routing

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.

3. Challenges and Problem Statement

This section describes in detail some possible bottlenecks encountered when dealing with low network latency.

3.1. Signaling Redundancy on Control Plane

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
               |                                       |
Figure 1: Overlay Routing

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                |
      |-------------------------------------------------------->|
      |                                 |                       |
Figure 2: Signaling Redundancy on Control Plane

3.2. Non-global Optimal Path Selection Policy

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   +-+
Figure 3: Non-global Optimal Path Selection Policy

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).

4. Candidate Solution Directions

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.

5. IANA Considerations

Request to IANA will be added later.

6. Security Considerations

Security issues will be considered later in the design.

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Additional Stuff

This becomes an Appendix.

Authors' Addresses

Shangling Deng (editor)
Huawei
D2-03,Huawei Headquarters
Shenzhen
China
Geng Li
Huawei
HuaWei Bld., No.3 Xinxi Rd.
Beijing
China
Yong Cui
Tsinghua University
4-104, FIT Building
Beijing
China