eDisco: Discovering Edge Nodes Along the Path

05/04/2018
by   Aleksandr Zavodovski, et al.
0

Edge computing is seen as an enabler for upcoming applications requiring low latency offloading, such as augmented reality, and as a key building block for Internet of Things. Edge computing extends the centralized cloud computing model by distributing servers also close to the users, at the edge of the network. A key challenge for the clients remains on how to discover the nearby edge servers and how to access them. In this paper, we present eDisco, DNS-based edge discovery, that leverages existing protocols and requires no modifications to deployed infrastructure. eDisco enables service providers and clients to discover edge servers, and determine the optimal edge deployment configuration.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

01/26/2018

Characterizing Docker Overhead in Mobile Edge Computing Scenarios

Mobile Edge Computing (MEC) is an emerging network paradigm that provide...
07/17/2019

Edge server placement with capacitated location allocation

Edge computing in the Internet of Things brings applications and content...
08/18/2021

Multi-Variant Execution at the Edge

Edge-cloud computing offloads parts of the computations that traditional...
05/09/2019

Open-source RANs in practice: an over-the-air deployment for 5G MEC

Edge computing that leverages cloud resources to the proximity of user d...
01/08/2020

Watching the Weak Link into Your Home: An Inspection and Monitoring Toolkit for TR-069

TR-069 is a standard for the remote management of end-user devices by se...
06/20/2021

A Survey on Serverless Computing

The Internet is responsible for accelerating growth in several fields su...
09/24/2021

Deployment and configuration of MEC apps with Simu5G

Multi-access Edge Computing (MEC) is expected to act as the enabler for ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

The introduction of cloudlets [23] and fog [5] served as a starting point for the recent developments in edge computing, pushing it as a key enabler for IoT, augmented reality, vehicular networking, and numerous other more specific use cases [18, 6]. By bringing the edge servers close to the users, novel applications and services requiring very low latencies become feasible, and the growing popularity of these kinds of applications is driving the development of edge computing. To fully leverage edge computing, two key challenges need addressing.

First is the placement of the edge servers which has already seen a fair amount of research, e.g., [7, 19, 2]. The main research questions on this topic revolve around various placement algorithms, determining good or optimal locations, and trying to approach the problem from the point of view of the edge service provider. While important to address and understand, they only cover part of the whole problem space of edge computing.

The second challenge relates to how the users and devices can discover the edge servers, to actually use them. This is the challenge we address in this paper, and we have identified the following requirements for an efficient discovery solution. First and foremost, it should work out-of-the-box with existing infrastructure, servers, and clients, in order to facilitate the adoption of edge computing. Second, as end-to-end encryption becomes prevalent on the Web, solutions clinging to on-path interception of requests are not feasible, mandating an end-to-end approach. Third, the solution should be efficient and flexible, and allow for different applications and services to be developed on it. In essence, we need a standardized edge discovery protocol that matches these requirements.

In this paper we present eDisco (Edge Discovery Protocol), a DNS-based solution that successfully addresses the key requirements from above. We use DNS SRV-records to indicate the locations of edge servers, which allows both cloud and other service providers to determine possible locations for onloading and for clients and any other devices to locate possible offloading locations. eDisco does not require any changes to any existing infrastructure, clients, servers, or protocols; only the entity installing an edge server needs to add the corresponding SRV records into their DNS zone. eDisco is a light-weight and efficient solution and meets the requirements specified above. We believe that eDisco can serve as an enabler for edge computing by allowing all players to start offering edge computing services and give a boost to edge-aware distributed application development. Further, eDisco is an another step towards ”overthrowing the Internet feudalism”, as Liu et al. [16] pessimistically characterize the present state of the Internet.

The rest of this paper is organized as follows. Section 2 describes the basic design and operation of eDisco. Section 3 discusses the practical implementation issues of eDisco, in particular in terms of collecting the required information. In Section 4 we discuss eDisco’s applicability to various use cases and review related work in Section 5. Finally, Section 6 concludes the paper.

2 Edge Discovery Protocol (eDisco)

(a) Edge discovery first phase, actual edge discovery.
(b) Edge discovery second phase, negotiation and deployment.
Figure 1: Edge discovery, onloading case. eDisco actions of edge orchestrator are shown in red. Solid line is used for bandwidth-intensive traffic, dotted line for low bandwidth.

We introduce eDisco via a concrete example of computational onloading, where service residing in a cloud is pushed closer to the end users. We use this scenario as an example, as it illustrates all the facets of eDisco; other use cases, e.g., traditional offloading and others are simpler and are discussed in Section 4. For convenience, we split the scenario in two phases: actual discovery (Figure 0(a)) and deployment of services (Figure 0(b)).

The design goal of eDisco is to allow for the service provider to spot (all) possible locations of edge servers between its own servers and the clients, and use this information to determine which of these possible locations it wishes to use for deploying its services.

The first phase, actual discovery, is the core functionality of eDisco and requires only usage of common networking protocols and tools, namely, DNS and traceroute. The process is illustrated in Figure 0(a) and is described below in detail. The service provider (e.g., a cloud provider) observes requests from clients coming from different parts of the network. We assume the provider runs an orchestrator to manage the process.

The second phase, deployment, during which the service is relocated to newly detected edge follows the discovery phase. This part optimizes the deployment of services and handles redirection of clients to the onloaded edge services.

While the actual client redirection happens in real-time, the discovery and deployment processes are executed in rounds. This is sufficient since the goals of discovery and deployment are to find installed servers, which does not change very frequently; hence it is enough to run them in periodically occurring rounds. As shown later in this Section, building of the network tree requires collecting data from a possibly large number of network nodes and domains, it is likely that the minimum duration of a round would be measured in minutes; we believe this to be sufficient for most use cases.

Structuring the whole process in rounds is actually beneficial since it allows for all parties to determine the (temporal) extent of their participation; the rounds define possible points at which to change the service offerings. The first phase of the round creates a map of the network with possible deployment points and the second phase performs the actual deployment. Client redirection happens in real-time and follows the setup of the current round. Next, we examine the protocol flow in detail.

2.1 Edge Server Discovery Phase

The first phase of eDisco aims to discover all possible edge servers associated on a client’s path and build an aggregation tree composed of all clients. The phase is depicted in Figure 0(a) and is summarized in Algorithm 1. The explanation of steps follows below.

Step 1: Collect client IP addresses from requests.

Step 2: Run traceroutes to client IP addresses to build the router level tree. Identify domains of the routers.

Step 3: Retrieve DNS SRV records for the identified domains to get addresses of possible edge servers in the tree.

Result: A tree from the cloud to clients identifying locations of edge servers, their IP addresses, and port numbers.

Algorithm 1 eDisco discovery phase

Step 1: Determine paths to clients: For every client that sends a request, the orchestrator sends out a traceroute to identify the path from the cloud to the client. It must be noted, that eDisco utilizes traceroute only as a tool to build a network graph of user to cloud connection which can be easily replaced by crowdsourced methodologies or active network sniffing tools such as netstat. We discuss the limitations of the current approach in Section 4.1; for now, we assume traceroute to be sufficient for the functionality of eDisco.

Step 2: Determine on-path DNS zones: The traceroutes give us the routers on the path to the client and using either DNS PTR records or augmenting this with whois information for routers with no PTR records, we can identify the domains along the path.

Step 3: Locate the edge servers: Once we have the list of domains, we perform a DNS SRV lookup using our new edge type SRV record defined below, which returns the addresses of edge servers in that domain, i.e., possible locations where services could be onloaded.

This step is central to the working of eDisco discovery phase. eDisco relies on the assumption that majority of edge providers will add SRV edge type of record to DNS in attempt to gain from the discovery of their edge infrastructure, but given that they wish to attract clients, they have a strong incentive to do so (and ensure the PTR records are accurate as well). We provide examples of DNS SRV records, containing IP addresses of edge servers, in Figure 2. Each SRV record is arranged according to the following format:

_service.  _protocol.name. TTL  DNSclass  SRV  priority  weight  port  target

Figure 2 shows that DNS zone domainA hosts two edge servers: serverA and serverB.

_edge._tcp.domainA.com. 86400 IN SRV 10 30 5060 serverA.domainA.com.
_edge._tcp.domainA.com. 86400 IN SRV 10 10 5060 serverB.domainA.com.
_edge._udp.domainA.com. 86400 IN SRV 10 30 1720 serverA.domainA.com.
_edge._udp.domainA.com. 86400 IN SRV 10 10 1720 serverB.domainA.com.
serverA.domainA.com.  86400 IN A 192.168.121.30
serverB.domainA.com.  86400 IN A 192.168.121.31
Figure 2: DNS SRV Record for Edge Servers

Servers support both TCP and UDP, but serverB should be preferred (priority 10 vs. 30). With this information, the orchestrator can build a graph (a tree) from its location to the locations of all known clients, and indicate on the tree the possible addresses of edge servers that would be on the path between the client and the cloud.

2.2 Negotiation and Deployment Phase

The second phase of eDisco aims to onload the selected service on the edge servers located in the first phase. The communication flow is depicted in Figure 0(b) and has been summarized in Algorithm 2. The deployment phase of eDisco is processed in three steps.

Step 1: Identify which services should be onloaded to edge servers and onto which servers they should go.

Step 2: Optionally negotiate deployment of services and revise placement if the original placement is not feasible (details not covered in this paper)

Step 3: Deploy services, either containers or VMs. Redirect clients to deployed instances using HTTP 302 response.

Result: Service containers or VMs deployed on selected edge servers, and clients are redirected correctly.

Algorithm 2 eDisco deployment phase

Step 1: Identify candidate services for onloading: Onloading starts by identifying the services whose relocation to the edge would be the most beneficial. Figure 0(b) shows cloud provider hosting two services, X and Y. The services run, for example, as Docker containers, or inside dedicated VMs; for both cases, there are efficient live migration techniques [9, 15, 8]. The selection of service to onload can be based on multiple metrics, e.g., bandwidth consumed, processing requirements, QoS, geographical diversity of users subscribed to the service. In Figure 0(b), the orchestrator determines to onload service X.

Step 2: Server selection and service request: Next, we select candidate locations in the tree for deploying the services identified in the first step. Considering the metrics used to determine the services, we can similarly identify locations in the network tree for deploying these services. This is a straight-forward (albeit possibly complex) optimization process, specific to the particular service or set of services; hence we omit the details of this process and simply assume that it can be performed.

Next, we must ensure that the selected locations are available to host the onloaded services. The cloud initiates a request to the selected edge servers to ensure that they have sufficient capacity to host the services. In case of insufficient capacity, we choose alternative locations.

Step 3: Deployment and redirection: In this step, we migrate the selected container to the decided edge server. For stateless services, we copy the required container or VM from cloud machine to the new host edge server. For live migration, various techniques have been developed for Docker containers [15, 9, 17] and VMs [8, 13], considering specifically edge environments.

Clients are redirected using an appropriate HTTP response. When the cloud provider wishes to redirect a client, instead of the normal reply with the requested content, it replies with a 302 Moved temporarily response URL that indicates the IP address and port of the selected edge server. This can be augmented with a TTL-field to ensure that the redirection is valid for only as long as the deployment of the service on edge can be guaranteed (e.g., until the end of this round of the protocol).

3 eDisco in Practice

As discussed in Section 2, eDisco relies on a graph composed of network connections via intermediate edge servers from all clients to the cloud. As the construction of the tree and its correctness is paramount to the functioning of eDisco, we now show how this tree can be constructed.

We ran our tests from an instance of Amazon Web Services (AWS) running in Frankfurt, Germany. This node represents the cloud, and as clients we picked the 100 universities from the Times Higher Education ranking[24]. We chose the main websites of these universities to represent the clients, to simulate a situation where the service running on the cloud has global interest. From the AWS instance, we ran traceroutes to these IP addresses and built the network graph. To simplify the graph, we grouped nodes into /24 subnets. Since there are no DNS SRV edge records, we merely assume every node in this graph would be a potential edge server location. Figure 3 shows a subset of the tree.

The central node in the figure is the AWS instance from where all the traceroutes were sent, and the other points are the discovered routers or clients nodes. The size of a point indicates the betweenness centrality of the node, i.e., gives an indication of how many paths to clients pass through that node.111We only calculated the betweenness centrality for the paths originating at the center since those are the only paths of interest to us. Ideally, we should deploy edge servers on nodes with high betweenness centrality (i.e., they serve many clients) and that are as close to the clients as possible (i.e., to minimize latency). Balancing this tradeoff is very much application specific, but it is something the orchestrator would need to take into account when making onloading decisions. For example, in the figure both nodes “C” and “D”, as well as “E” and “F” have the same betweenness centrality, but nodes “D” and “F” should be preferred in deployment, as they are closer to the clients at the edge.

Figure 3: Network aggregate tree from cloud to clients via intermediate edge servers.

4 Discussion

We now discuss practical aspects of eDisco and expand on its use cases.

4.1 Network Topology Exploration

eDisco relies on traceroute for its exploration of the paths to the clients. It uses the ICMP protocol, and some routers choose to ignore the ping messages sent by traceroute, resulting in us getting an incomplete picture of the network. Likewise, not all routers in the network have a DNS PTR record that would enable us to map their IP addresses to domain names. While the whois service helps in trying to map IP addresses to domains, it is not guaranteed to provide a unique (and correct) domain name for a given IP address.

However, we do not see this as a major issue for eDisco. Our rationale is that since the deployed edge servers are intended to be used, the entity deploying them has a strong incentive to ensure that the DNS records are correct and that the information is available.

4.2 Use Cases

eDisco is not limited to computational onloading that we have just examined. As mentioned above, we chose that as the example scenario because it showcases the full potential of eDisco; other use cases we discuss below are more straightforward to implement.

A typical scenario for edge computing is offloading, where a client having limited capacity transfers computational tasks to an edge server. In this case, the client simply queries its current domain for the DNS SRV edge records, getting a list of possible nearby edge servers as a result. While this solution does not require the client to use traceroute, it only enables discovery in the current domain. As an extension, the client could explore the network via traceroute towards a cloud in the network to get additional domains, but this would induce additional overhead.

There are numerous showcases of contextual edge applications, such as providing 360° panoramic view at the stadium by aggregating individual users’ video streams [18], improving the customer experience at a shopping mall [6], and others. The discovery of those applications is generally enabled by external means, such as billboards, emails and so on, but with eDisco, it is possible to query edge servers for contextual applications, in the manner described above.

4.3 eDisco Opportunities

Edge computing needs open and standardized infrastructures and protocols in order for its potential to be truly realized. This implies a world where clients and platform and service providers can discover, deploy, and use services flexibly and at run-time.

We believe eDisco is an excellent match for discovering edge services since it requires no modifications to existing infrastructure or clients. It works efficiently and enables providers to flexibly onload their services as well as client-side offloading and contextual edge service discovery. It is entirely based on existing protocols and can operate in any environment.

eDisco provides the crucial technical building block for wide-spread deployment of edge services, and it needs to be complemented with additional work on determining agreements between the various providers and addressing security issues that may arise in these kinds of environments.

5 Related Work

Our primary use case, computational onloading, is discussed by [4, 11], among others. Bhardwaj et al. [4] implement the edge discovery as a backend service that hosts a directory of available devices. That requires a centralized catalog approach we choose to avoid. In [11], the discovery is seen as identification of available capacities from the set of already known resources.

Edge and middlebox discovery have strong commonalities. In fact, Detal et al. [10] use modified traceroute for identifying hidden middleboxes along a network path. Abujoda et al. [1] suggest a custom protocol for discovery of middleboxes, criticizing traceroute for low speed. As a drawback, all middleboxes need to run specific controller software to enable discovery. Nevertheless, despite the issues with traceroute, we consider the superior alternative since it obviates the need for installing additional software.

Mobile Edge Computing (MEC) [12, 14, 3, 21] is an ongoing standardization effort for edge computing in the area of mobile applications. In MEC, there is a strong assumption that edge servers are located at cellular base stations, which makes discovery easy, but their operation may be difficult in the presence of end-to-end encrypted connections. eDisco allows for discovery in MEC as well, and it can be triggered by the cloud.

Varghese et al. [25] present a concept of an EaaS (Edge-as-a-Service) platform, offering a discovery protocol. However, the approach relies on specific master controller nodes: to utilize edge, one must know the particular provider of EaaS beforehand to be able to discover the edge resources. Work by A. Salem et al. [22] suggests Kinaara, an edge computing framework also offering discovery capabilities. Discovery is enabled by special mediator nodes, that keep a connection to the cloud. They do not discuss how mediators are discovered. Mortazavi et al. suggest the concept of path computing [20], which is quite similar to our view of edge environment, where edge resources reside on a path from the cloud to an end user. Their framework, CloudPath, addresses many practical issues, but edge discovery does not happen on the fly: the developer is actually responsible for specifying the mappings between application functions and actual computing facilities in the deployment descriptor file. We suppose that frameworks presented in [25], [20], and [22] can potentially gain from utilizing the eDisco, which will remove the necessity for highly specialized components, adds more agility, and improves the overall user experience since eDisco is capable of discovering previously unknown resources.

6 Conclusion

Discovery of edge services is a vital part of making edge computing a reality. In this paper, we have presented eDisco, a DNS-based edge discovery protocol that enables efficient discovery of edge nodes, both for service providers and clients. eDisco uses existing protocols and services and requires no modifications to the infrastructure or client devices. We leverage standard tools, such as traceroute and DNS and because of this, eDisco can be deployed in the networks as they are. We have shown a practical feasibility study that demonstrates the basic concepts of eDisco. As part of our future work, we plan on implementing the service placement components of eDisco and make the solution available.

References

  • [1] A. Abujoda and P. Papadimitriou. Midas: Middlebox discovery and selection for on-path flow processing. In Communication Systems and Networks (COMSNETS), 2015 7th International Conference on, pages 1–8. IEEE, 2015.
  • [2] T. Bahreini and D. Grosu. Efficient placement of multi-component applications in edge computing systems. In SEC, 2017.
  • [3] M. T. Beck, M. Werner, S. Feld, and S. Schimper. Mobile edge computing: A taxonomy. In Proc. of the Sixth International Conference on Advances in Future Internet, pages 48–55. Citeseer, 2014.
  • [4] K. Bhardwaj, M.-W. Shih, P. Agarwal, A. Gavrilovska, T. Kim, and K. Schwan. Fast, scalable and secure onloading of edge functions using airbox. In Edge Computing (SEC), IEEE/ACM Symposium on, pages 14–27. IEEE, 2016.
  • [5] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli. Fog computing and its role in the internet of things. In Proceedings of the first edition of the MCC workshop on Mobile cloud computing, pages 13–16. ACM, 2012.
  • [6] S. Carlini. How the Internet of Things and Edge Computing Will Help Revolutionize the Shopping Experience. https://blog.schneider-electric.com/datacenter/2016/06/03/iot-edge-computing/, 2016.
  • [7] A. Ceselli, M. Premoli, and S. Secci. Mobile edge cloud network design optimization. IEEE/ACM Transactions on Networking, 25:1818–1831, 2017.
  • [8] L. Chaufournier, P. Sharma, F. Le, E. Nahum, P. Shenoy, and D. Towsley. Fast transparent virtual machine migration in distributed edge clouds. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing, SEC ’17, pages 10:1–10:13, New York, NY, USA, 2017. ACM.
  • [9] CRIU. Docker - CRIU. https://criu.org/Docker, 2018.
  • [10] G. Detal, B. Hesmans, O. Bonaventure, Y. Vanaubel, and B. Donnet. Revealing middlebox interference with tracebox. In Proceedings of the 2013 Conference on Internet Measurement Conference, IMC ’13, pages 1–8, New York, NY, USA, 2013. ACM.
  • [11] F. Esposito, A. Cvetkovski, T. Dargahi, and J. Pan. Complete edge function onloading for effective backend-driven cyber foraging. In Wireless and Mobile Computing, Networking and Communications (WiMob),, pages 1–8. IEEE, 2017.
  • [12] ETSI. Mobile-Edge Computing. https://portal.etsi.org/portals/0/tbpages/mec/docs/mobile-edge_computing_-_introductory_technical_white_paper_v1%2018-09-14.pdf, 2014.
  • [13] K. Ha, Y. Abe, T. Eiszler, Z. Chen, W. Hu, B. Amos, R. Upadhyaya, P. Pillai, and M. Satyanarayanan. You can teach elephants to dance: Agile vm handoff for edge computing. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing, SEC ’17, pages 12:1–12:14, New York, NY, USA, 2017. ACM.
  • [14] Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young. Mobile edge computing—a key technology towards 5g. ETSI white paper, 11(11):1–16, 2015.
  • [15] B. I. Ismail, E. M. Goortani, M. B. A. Karim, W. M. Tat, S. Setapa, J. Y. Luke, and O. H. Hoe. Evaluation of docker as edge computing platform. 2015 IEEE Conference on Open Systems (ICOS), pages 130–135, 2015.
  • [16] T. Liu, Z. Tariq, J. Chen, and B. Raghavan. The barriers to overthrowing internet feudalism. In Proceedings of the 16th ACM Workshop on Hot Topics in Networks, pages 72–79. ACM, 2017.
  • [17] L. Ma, S. Yi, and Q. Li. Efficient service handoff across edge servers via docker container migration. In SEC, 2017.
  • [18] Mobile Europe. Nokia brings AR to sports stadium with MEC platform. https://www.mobileeurope.co.uk/press-wire/nokia-bring-ar-to-sports-stadium-with-mec-platform, 2017.
  • [19] N. Mohan and J. Kangasharju. Edge-fog cloud: A distributed cloud for internet of things computations. In Cloudification of the Internet of Things (CIoT), pages 1–6. IEEE, 2016.
  • [20] S. H. Mortazavi, M. Salehe, C. S. Gomes, C. Phillips, and E. de Lara. Cloudpath: A multi-tier cloud computing framework. In Proceedings of the Second ACM/IEEE Symposium on Edge Computing, SEC ’17, pages 20:1–20:13, New York, NY, USA, 2017. ACM.
  • [21] D. Sabella, A. Vaillant, P. Kuure, U. Rauschenbach, and F. Giust. Mobile-edge computing architecture: The role of mec in the internet of things. IEEE Consumer Electronics Magazine, 5(4):84–91, 2016.
  • [22] A. Salem, T. Salonidis, N. Desai, and T. Nadeem. Kinaara: Distributed discovery and allocation of mobile edge resources. In Mobile Ad Hoc and Sensor Systems (MASS), 2017 IEEE 14th International Conference on, pages 153–161. IEEE, 2017.
  • [23] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. The case for vm-based cloudlets in mobile computing. IEEE pervasive Computing, 8(4), 2009.
  • [24] Times Higher Education. World University Rankings. https://www.timeshighereducation.com/world-university-rankings/2018/world-ranking, 2018.
  • [25] B. Varghese, N. Wang, J. Li, and D. S. Nikolopoulos. Edge-as-a-service: Towards distributed cloud architectures. arXiv preprint arXiv:1710.10090, 2017.