(R)evolution of the computing continuum - A few challenges

Editor's Notes

• #4: CDF = cumulative Distribution Function of responses times (3 runs) E2E = Eye to Eye VR < 20 ms
• #5: Todo: ordres de grandeurs comparatifs
• #12: Une version simplifiée du edge mais pouvons nous déjà opérer une telle infrastructure?
• #14: First application: OpenStack Can we operate an edge infrastructure with a single instance (aka. a single controlplane) of OpenStack?
• #15: Une version simplifiée du edge mais pouvons nous déjà opérer une telle infrastructure? Good results and Openstack, impossible to provision VMs when having network disconnection One version of OpenStack on every site
• #16: Etudier un système biologique (qui évolue tout les 6 mois de maniere drastique)
• #17: Nova is the OpenStack project that provides a way to provision compute instances (aka virtual servers). Glance: OpenStack Image service Last scenario when Andy wants to launch a VM instance which is only available on site 2
• #19: Having a solution without changing the code
• #20: Etudier un système biologique (qui évolue tout les 6 mois de maniere drastique)
• #21: Cheops: new dedicated service acting as a proxy
• #23: Etudier un système biologique (qui évolue tout les 6 mois de maniere drastique)
• #24: Etudier un système biologique (qui évolue tout les 6 mois de maniere drastique)
• #25: K8S = Kubernete
• #43: ILP = CPLEX, First fit with backtrack, Genetic alg., Xia et al., Choco
• #47: If we look to the state of the art, when a client wants to access a specific content, it has to request a remote node to provide at least one node identity to retrieve this content from. After retrieving the content, the client can create another replica to improve the performance of future accesses, but it must then recontact the indexing service to notify of the creation of this new replica. This approach has two drawback. - First, accessing a remote node to request content location(s) raises hot spots and availability issues. But most importantly, it results in additional delays [3,12] that occur even before the actual download started. Second, the client gets a list of content locations at the discretion of content indexing services. Without information about these locations, it often ends up downloading from multiple hosts, yet only keeping the fastest answer. In turn, clients either waste network resources, or face slower response time. A naive approach would be that every node indexes and ranks every live replica along with its location information. When creating or destroying a replica, a node would notify all other nodes by broadcasting its operation This flooding approach is counter performant as a node may acknowledge the existence of replicas at the other side of the network while there already exists a replica next to it. A promising approach would be to use epidemic propagation by limiting the propagation only to a subset of relevant nodes. To better understand this idea, let’s discuss a concrete example.
• #48: In this example, we consider a Node R that creates a new content and that efficiently advertises its content by epidemic propagation. At the end of the epidemic phase, every node can request R to get the content if needed Let’s consider that Node G gets the content and creates a second replica splitting the red set in two (now we have a set of nodes in red that should request R and a set in Green that should requests G in order to get the closest replica host. In this example, we consider the geographical distance but the notion of distance can be defined in a more advanced way considering latency, throughput, robustness etc.). Now, let’s consider that Node B creates another replica. Node B needs to notify only a small subset of nodes (resulting a 3 sets, red, green and blue) Finally, let’s consider G destroys its replica. Nodes that belonged to its partition must find the closest partition they are in, resulting at the end in two sets (red and blue). While it makes sense for Node G to broadcast its removal, Node B and Node R cannot afford to continuously advertise their replica to fill the gap left open by Node G. A better approach would consist in triggering notifications at bordering nodes of red and blue partitions once again. In other words, the indexing problem can be seen as a distributed and dynamic partitioning problem.
• #49: This dynamic partitioning raises additional challenges related to concurrent operations where removed partitions could block the propagation of other partitions. So the problem that should be tackled is: how can we maintain such a logical partitioning in a dynamic environment where nodes can add…. Node can join… While limiting the scope of the messages between nodes as much as possible (network confinement)
• #50: Just to give you an idea of the consistency issue, let’s consider the following example. In the first part (a)): nodes a and c create a new replica of a the same content. The colors illustrate in which partition node belong to (black no partition). So node a belongs to the blue partition and node c to the green one. Both nodes send a creation message to their neighbour (here b). b) Let’s consider node b receives the notification of node a, so it joins the blue partition and forwards the notification towards C (alpha a3,3 since distance equals AB+BC: 2+1). Meanwhile, node a and node c delete the replica and so send a new notification related to the removal to b (respectively deltaA and deltaB). Once again nodes evolve independently from the broadcasted messages. c) The creation notification from c to b (alpha c1) is finally received on b and so b will join the green partition since the distance is better and forward this message to A (alpha c3). The removal message from node a is received on b. Since node b belongs to the green partition, it does not consider the notification related to the removal of the replica sent by node a (deltaA is discarded). Remind that the goal is to mitigate the network traffic as much as possible. Meanwhile, node c receives the initial creation of node a. Since it does not have the replica anymore, it joins the blue partition (here we have a first inconsistency, since b believes its closest replica is on node C while node C believes it is on node a going through node b, which is obviously not possible). Anyway let’s continue the scenario. d) node A receives the initial notification of node c, since it does not have the replica anymore, it joins the green partition (although the content has been already deleted at C but there is no way for node A to be aware of that). Node b receives the removal notification from node c and so leaves the green partition and forwards the notification to node A. e) node A receives the removal notification and leaves in its turn the green partition. f) at the end node C belongs to a partition that does not exist anymore and of C have children, they would stay in the wrong partition too.
• #51: Without diving into details, nor presenting the algorithm, the idea is to make echos to creation and removals notifications. If a node receives a notification that it has already proceed and that it knows it is deprecated it will make an echo of the previous message (in the previous case, the removal notification that has been discarded on node B will be triggered once again to node C). For further details please refer to the article.