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.
Edge and middlebox discovery have strong commonalities. In fact, Det @cite_7 use modified traceroute for identifying hidden middleboxes along a network path. @cite_24 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.
@cite_24 @cite_7
2144241614 2129094430 2108673686 2067209328
Middleboxes such as firewalls, NAT, proxies, or Deep Packet Inspection play an increasingly important role in various types of IP networks, including enterprise and cellular networks. Recent studies have shed the light on their impact on real traffic and the complexity of managing them. Network operators and researchers have few tools to understand the impact of those boxes on any path. In this paper, we propose tracebox, an extension to the widely used traceroute tool, that is capable of detecting various types of middlebox interference over almost any path. tracebox sends IP packets containing TCP segments with different TTL values and analyses the packet encapsulated in the returned ICMP messages. Further, as recent routers quote, in the ICMP message, the entire IP packet that they received, tracebox is able to detect any modification performed by upstream middleboxes. In addition, tracebox can often pinpoint the network hop where the middlebox interference occurs. We evaluate tracebox with measurements performed on PlanetLab nodes. Our analysis reveals various types of middleboxes that were not expected on such an experimental testbed supposed to be connected to the Internet without any restriction. Many topology discovery systems rely on traceroute to discover path information in public networks. However, for some routers, traceroute detects their existence but not their address; we term such routers anonymous routers. This paper considers the problem of inferring the network topology in the presence of anonymous routers. We illustrate how obvious approaches to handle anonymous routers lead to incomplete, inflated, or inaccurate topologies. We formalize the topology inference problem and show that producing both exact and approximate solutions is intractable. Two heuristics are proposed and evaluated through simulation. These heuristics have been used to infer the topology of the 6Bone, and could be incorporated into existing tools to infer more comprehensive and accurate topologies. Traceroute is widely used to detect routing problems, characterize end-to-end paths, and discover the Internet topology. Providing an accurate list of the Autonomous Systems (ASes) along the forwarding path would make traceroute even more valuable to researchers and network operators. However, conventional approaches to mapping traceroute hops to AS numbers are not accurate enough. Address registries are often incomplete and out-of-date. BGP routing tables provide a better IP-to-AS mapping, though this approach has significant limitations as well. Based on our extensive measurements, about 10 of the traceroute paths have one or more hops that do not map to a unique AS number, and around 15 of the traceroute AS paths have an AS loop. In addition, some traceroute AS paths have extra or missing AS hops due to Internet eXchange Points, sibling ASes managed by the same institution, and ASes that do not advertise routes to their infrastructure. Using the BGP tables as a starting point, we propose techniques for improving the IP-to-AS mapping as an important step toward an AS-level traceroute tool. Our algorithms draw on analysis of traceroute probes, reverse DNS lookups, BGP routing tables, and BGP update messages collected from multiple locations. We also discuss how the improved IP-to-AS mapping allows us to home in on cases where the BGP and traceroute AS paths differ for legitimate reasons. Middleboxes are widely deployed in today's enterprise networks. They perform a wide range of important network functions, including WAN optimizations, intrusion detection systems, network and application level firewalls, etc. Depending on the processing requirement of traffic, packet processing for different traffic flows may consume vastly different amounts of hardware resources (e.g., CPU and link bandwidth). Multi-resource fair queueing allows each traffic flow to receive a fair share of multiple middlebox resources. Previous schemes for multi-resource fair queueing, however, are expensive to implement at high speeds. Specifically, the time complexity to schedule a packet is O(log n), where n is the number of backlogged flows. In this paper, we design a new multi-resource fair queueing scheme that schedules packets in a way similar to Elastic Round Robin. Our scheme requires only O(1) work to schedule a packet and is simple enough to implement in practice. We show, both analytically and experimentally, that our queueing scheme achieves nearly perfect Dominant Resource Fairness.