By Cheng-Lin Tsao Felipe Santos Ruhull Alam Bhuiyan Planet Lab By Cheng-Lin Tsao Felipe Santos Ruhull Alam Bhuiyan

Context and Problem The purpose of this project is to analyze the path diversity of real Internet and evaluate its potential benefits. Path Analysis To collect data using scriptroute on each member Diversity Analysis Determine diversity of paths between any source and destination pairs Overlay Routing Analyze the potential benefits of multi-path routing in overlay network

‘gt_siva’ Slice Architecture Planet Lab 1. We use the local machine to collect data from servers from all the members 2. We analyze the diversity on the local machine 3. We analyze multi-path routing with source routing server and client pairs in each member. Explain the term member, which is the node in our slice. Differentiate between member and intermediate nodes. Stage 2: Diversity Analysis Stage 1: Path Analysis Stage 3: Overlay Routing Local Machine

Our Member Nodes How did choose the members? Ansser: a. We could login to the server as the key was been able to propagate through the server. b. We can collect data with the member. c. To establish geological diversity in our members. d. We have node in Asia, North America, South America, Europe, Australia.

Work outline

Work done Scriptroute : Ruby Script Platform to deploy and combine multiple network test tools simultaneously Deployed Scriptroute to 41 nodes (in our slice) sr-quartet – each measurement consists of a random variable whose standard deviation and variance are taken into account in order to minimize error – in our tests average of 5 – 10%

Work done Need to physically locate each node Initially planed on using the built-in scriptroute function built-in to sr-rockettrace to determine location – most nodes/hops failed to return its location Netgeo (http://www.caida.org/tools/utilities/netgeo/) Database and collection of Perl scripts used to map IP addresses and AS numbers to geographical locations Performs multiple WHOIS lookups to ARIN/APNIC/RIPE for the specified IP address and those it believes are geographically close to the specified address and returns latitude/longitude, city, state, country … Java API – simply call method providing an IP address and it returns the node location

Work done Path Analysis

Work done Diversity Analysis Breadth-first-search D A B C E Node-disjoint paths Bottleneck-disjoint paths Breadth-first-search Preferring fewer intermediate members Element = list of intermediate members Starting with empty list Generating sub-trees Pruning sub-trees C D E CD CE DC EC

Work done Overlay routing Using data from path analysis Setting up routes according to diversity analysis Virtual channel TCP sockets Measure achievable end-to-end throughput D A B data data data data data data data data data data data ACEB data data data data E C L

Results Path Analysis (number of paths) Member To From GT, US 19 Duke, US MIT, US Stanford, US 21 Internet2-Chicago, US 18 Internet2-Huston, US Internet2-Seattle, US AT&T, US 17 McGill, US 20 TRLab, Canada TU-Berlin, Germany Member To From U. of Zunich, Switzerland 21 U. of London, UK Tech. U. of Madrid, Spain IBBT Ghent U., Belgium Academia Sinica, Taiwan 19 Kaist, Korea U. of Tokyo, Japan U. of HK, Hong Kong Tsinghua U., China 16 17 USTC, China RNP, Brazil

Results Diversity Analysis No node-disjoint paths found Single outbound router (default gateway) Some have multiple inbound routers Member Out In GT 1 Duke MIT 3 Stanford I-Chicago 4 I-Huston I-Seattle AT&T 2* Member Out In McGill 1 2* TRLab TU-Berlin Unizh ULondon UPM IBBT Sinica 2 Member Out In Kaist 1 UTokyo HKU 2 THU USTC 3* RNP *: one router unknown

Results Diversity analysis 18 bottleneck-disjoint paths (BDP) GTStanford GTStfd GTMITStfd GTI-ChicagoStfd GTI-HustonStfd GTI-SeattleStfd GTAT&TStfd GTMcGillStfd GTTRLabStfd GTIBBTStfd GTSinicaStfd GTUTokypStfd GTHKUStfd GTRNPStfd GTDukeKAISTStfd GTUPMI-HustonULondonStfd GTI-HustonTRLabAT&TULondonStfd GTI-HustonTHUAT&TULondonStfd GTI-HustonUSTCAT&TULondonStfd

Results Overlay Routing Throughput of bottleneck-disjoint paths New paths don’t affect old paths GTStanford 1 2 4 8 Direct 3.682 3.681 3.532 3.129 MIT 2.643 2.571 2.308 I-Chicago 3.441 3.1 I-Huston 5.264 4.673 I-Seattle 3.291 AT&T 1.218 McGill 2.4 TRLab 2.316 time: 100 sec unit: Mbps

Results Overlay Routing BDP > random alternative paths Improve 700%+ throughput over direct

Overall implications Some middle-boxes affect path analysis Node-disjoint paths are possible but need support from network layer Multiple bottleneck-disjoint paths exist between two members Bottleneck-disjoint paths aggregate bandwidth through independent bottlenecks Bottleneck-disjoint paths provide higher throughput than random alternative paths

Summary and Future Works Collected path data on PlanetLab Analyzed path diversity Evaluated overlay routing Future works More accurate path analysis, location information Online diversity analysis Node-disjoint paths by setting the routing table Considering bandwidth/delay/jitter/loss in algorithm