190 likes | 362 Views
Mapping Logical Network Routing to Physical Network Routing *. Valentin Mesaros (UCL), Luc Onana (KTH) Peter Van Roy (UCL), Seif Haridi (KTH). *.
E N D
Mapping Logical Network Routing to Physical Network Routing * Valentin Mesaros (UCL), Luc Onana (KTH) Peter Van Roy (UCL), Seif Haridi (KTH) * Most ideas taken from article “NetProber: A component for enhancing efficiency of overlay networks in P2P systems”, to appear in IEEE P2P’02. 2nd PEPITO workshop, Stockholm Jun. 2002
Contents • The mapping problem • Principles of our solution: NetProber • Some simulation results • Related work • Conclusions • How far can we go? • Further work Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
The Mapping Problem • general facts (the current status) • - the logical nodes do not (want to) have knowledge about underlying network • - the logical network is usually randomly constructed • problems • - mismatching - depending on a QoS param (e.g., # hops, latency, bandwidth) • consequence • - inefficient use of the underlying network [Ripeanu01] • * many more physical hops needed for logical routing than for physical routing • * physical links may be employed more times than necessary (i.e., stressed links) • - increase of latency • * awkward randomly connections lead to increasing the communication latency Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Logical Network over Physical Network:graphical notation BL AL GL FL B D G E A F C H B A G 2 F 3 Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
E A E D A 2 B D 2 B C C b. more efficient mapping a. inefficient mapping The Mapping Problem: example • - consider the Gnutella overlay network {A,B,C,D,E} • a broadcast msg. (TTL=4) from A passes 4 times link (B,D)(stressed link) • - there are much more physical messages generated in case (a) than in (b) Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Our Solution: principles • use information about the underlying network • - # of hops between two nodes • - latency/bandwidth between nodes • peers try to find the physically closest neighbors (proximity selection) • a complementary component (NetProber) is associated with each peer • - NetProber tries to collect/process info about the underlying network Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Our Solution: algorithm • core: algorithm • - if the neighbor’s neighbor is closer to me than my neighbor, connect to it • and disconnect from my neighbor • - can be run with different depths • location: where to run the algorithm • - each peer runs the algorithm with respect to each of its neighbors • control: when to run the algorithm • - run the algorithm when a certain event occurs (e.g., new connection, latency • change, periodically) Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Overlay Goodness • d-good node: • - a node N such that in every path of length d from N, • the closest node is already a neighbor of N • - it is computed with respect to a certain depth d • overlay network goodness Gd: • - the ratio of the number of good nodes over the number of nodes • in the overlay network C is a good node G2 = 0.2 E A D 2 B C Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
overlay routing peer B peer A boundary NetProber abstraction IP routing NetProber B NetProber A NetProber • component for enhancing efficiency of overlay networks and • increasing its goodness • component to be attached to peers • responsible for finding a closer neighbor • make use of the underlying network (IP) Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
NetProber:how it works G F npG npF A C 2 npC npA B npB D npD Msgs exchanged: • A tries to find a closer neighbor w.r.t. C, • run an algorithm instance (depth 2), • npA suggests A to switch from C to B A -> npAFindBetterNeighbor(C) npA -> npCNetProbeRequest npC -> npANetProbeReply(Neighbors, Param) npA -> npB,npFNetProbeRequest npB,npF -> npCNetProbeReply(Param) npA -> A Suggestion(C,B) Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
1 | NL(k) | cost_logic(i,j) cost_physic(i,j) # physical hops on logical path (i,j) # physical hops on physical path (i,j) 11 5 6 2 5 1 The Mismatching Factor - Let R(i,j)be = - Let NL(k) be the set of nodes reached from node k doing a broadcast level L NL(k) = { j | i0, i1, i2, …, im logical nodes such that i0=k, mL, (ir, ir+1) logical edge} - Let MFL(k)be R(k,j) , where j NL(k) - The ideal value for MFL(k) is 1 F G Example: (MF of node A) A R(A,B) = = 5 C 2 R(A,D) = = 3 B D MF3(A) = = 2.2 Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Simulations • the simulator • - simulate the physical and logical networks, and NetProber in Mozart • - physical nodes are connected via Oz ports • - the logical nodes are attached to physical nodes • the physical network • - generated with Inet-3.0 (from real Internet data) • - # nodes = 3100, # edges = 4904, graph diameter = 9 • the logical networks • - randomly generated: a new node connects to a node already in the network • - # nodes = 50, 150, 250, 500, 1000 Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Related Work • entry optimization in Tapestry [Zhao01] • - switch from primary to closer (in latency) secondary neighbors • - procedure run at joining, and periodically afterwards • - costly in time • binning applied in CAN[Ratnasamy02] • - peers organize in bins with respect to their distance (in latency) to • certain well known landmarks • - there is no optimization inside a bin • overlay efficiency optimization in Narada [Chu00] • - each member periodically probes (in latency) every other • - switch to a new neighbor for better performances • - it performs badly for large groups ( > 300 ) Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Different distance metrics disadvantages advantages # of hops • - limited access • - rapidly-oscillating • do not lead to accurate results • hard to provide • difficult to measure • - one-shot measurement • accurate • easy to process • - easy to access • practical • - practical latency bandwidth Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Conclusions • randomly constructed P2P networks can make efficient use of the underlying network • possible mapping measures • - overlay goodness • - mismatching factor • complementary adaptive component for peers: NetProber • the use of # of hops as a metric gives good results in simulations • - the overlay goodness improves • - less physical msgs. are generated when addressing nodes in the system • optimality • - running the algorithm with depths 2, 3 gives significant improvements Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
How Far Can We Go • optimality • - for tree physical networks, NetProber with depth 2 gives the global optimum • (best with given number of logical edges) • - for physical networks with redundant paths, depth 3 and higher gives significant • improvements for depth 2, A does not see that E is close A D E w1 w2 B C Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
C B D How Far Can We Go (II) • “leaf” effect • - unless the logical nodes are located on the roots of the sub-trees of • the physical network, MF can not reach 1 Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Further Work and Open Questions • Adapting NetProber for faults (site problems, network problems) • What is the correct goodness measure(s)? • how to better combine different distance metrics? • What should be put in the DSS? Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002
Bibliography Y.Chu, S.Rao, and H.Zhang. A case for end system multicast. In Proc. of ACM SIMETRICS, June 2000 [Chu00] S.Ratnasamy et al. Topologically-aware overlay construction and server selection. In Proc. of IEEE INFOCOM, June 2002. [Ratnasamy02] M. Ripeanu. Peer-to-Peer architecture case study: Gnutella Network. Tech. Report, University of Chicago, July 2001. [Ripeanu01] B.Zhao, J.Kubiatowicz, and A.Joseph. Tapestry: An infrastructure for fault-tolerant wide-area location and routing. Tech. Report UCB/CSD-01-11041, U.C. Berkeley, April 2000. [Zhao01] Mapping logical routing to physical routing - 2nd PEPITO workshop, Stockholm Jun. 2002