Routing Scalability Mingwei Hu Tarek Elgamal

Background Routing Scheme A mechanism that can delivers network packets from any node to any other nodes in the network A distributed algorithm: Each node has a runs its own routing algorithm Decide how to forward packets Maintains a local routing table Network packet header Source address Destination address

Background Traditional routing algorithms (shortest-path) Link State Creates a topology of the network and runs Dijkstra's Algorithm to determine the shortest path Distance Vector More distributed than LS; does not know the topology of the network Each node only knows neighbors’ routing tables Runs Bellman-Ford algorithm to construct routing table

Background Stretch of a Routing Scheme Worst ratio between the length of a path on which the message is routed and the length of the shortest path from source to destination Why is it important to know the stretch of a routing scheme?

Problems with traditional routing algorithms

Problems with hierarchy routing solution Hierarchy leads to higher stretch The higher the stretch, the less optimal the routing scheme is Hierarchy leads to location-dependent addresses This complicates management, mobility, and multihoming

Our goals

Low Stretch The protocol should find paths that are close to the shortest possible Not possible to route on shortest paths using O(n) state per node Desire stretch to be bounded by a small constant in worst case.

Our goals Location-independent addresses (Flat Names) Protocol should route on arbitrary node name with no relationship with the node’s location This can eliminate management burden of location-based address assignment Flat name can be self-certifying Distributed Hash Table can provide a consistent hashing database over a set of well known nodes, but stretch is large

Previous scalable routing protocols

Distributed Compact Routing (Disco) Guarantees: Scalability Low stretch Flat names Disco has three components: Name-dependent distributed compact routing protocol (NDDisco) A name resolution module Distributed location database to achieve name-independence

Name-dependent distributed compact routing protocol (NDDisco) Guarantees: Worst-case stretch of 5 on the first packet Worst-case stretch of 3 on subsequent packets Cannot guarantee: Name-independency

Name-dependent distributed compact routing protocol (NDDisco)

Address of a node v: (Lv, lv->v): Lv: identifier of closest landmark to v Lv->v: explicit route consisting of labels of hops along the lv -> v

Name-dependent distributed compact routing protocol (NDDisco) Routing from source s to destination t if: t is a landmark or t is in s’s vicinity, then route along shortest path from s to t else: extracts lt from t’s address and route along s -> lt -> t The first packet has worst-case stretch of 5 Upon t receives s’s packet If s is in t’s vicinity, then t informs s the shortest path s->t

Name resolution Every node is aware of its own address (lv, lv->v) Insert address into the database and other nodes can query

Distributed Name Database

Name-independent compact routing Routing from source s to destination t if: t is a landmark or t is in s’s vicinity, then route along shortest path from s to t Else if: s knows t’s address, then route using NNDisco Else: S computes h(t) Find a node w in V(s) s.t. h(w) has the longest prefix match with h(t) W is in G(t) Route along the path s -> w -> lt -> t For first packet, stretch is 7. Similar to NNDisco, stretch will be <= 3 after the first packet

Result Mean stretch and Mean state with number of nodes

NIRA: A New Inter- Domain Routing Architecture Presented by: Tarek Elgamal

Internet Alice Bob Hi Alice Today’s Internet

Internet SecondHopper RouteRight Here RouteForLess Alice Bob Hey, it is my happy hour, route for free Best second hop in town Know what? comcast has a blackhole ahead What if user can choose the sequence of ISPs for their packets Hi Alice

Motivation Foster competition between ISPs Technical benefits: End hosts on overlay network can often find more optimal Internet paths Multihomed sites (i.e. connected to multiple ISPs) improve quality and reduce monetary cost

Application Scenarios High throughput and low latency at the expense of cost Examples: Online games, video conferencing High latency and low cost Examples: peer-to-peer file downloads Multipath routing for critical applications Example: Calling 911

Is that possible ? The paper argues that allowing user to choose their routes is technically possible Key contribution is addressing the following challenges: Practical payment schemes (bilateral contracts between multiple ISPs) Scalable route discovery Efficient route representation Handling route failures Packet Forwarding Security (not well discussed)

Route Discovery Topology Information Propagation Protocol (TIPP): -Distribute to users their providers and the providers’ providers until the "core” ( tier-1 providers) -Propagate link states when topology changes -Notifies a user of the working conditions of routes (e.g., unreliable routes)

Route Discovery NRLS(Name to Route lookup Service) How can I reach Alice ? N3  R3  B1 N3  R3  R2  B1 TIPP tells Bob his “upgraph” to the core -N1  R1  B1 -N1  R2  B1 Bob queries NRLS to find Alice’s “upgraph” - NRLS is analogous to DNS but resolves name to path of ISPs End-to-End route: Bob “uphill” + Alice “downhill” N1  R1  B1  R3  N3 uphill Downhill

Route Representation Alternatives: -Sequence of Ases (same as BGP) flexible but variable length - Hierarchical address (Used by NIRA): long (128 bits) and fixed length e.g., IPv6 (1:2:3::1000) (96 bit inter-domain, 32 bit intra-domain) “::” refers to contiguous zeros Bob use the source address 1:1:1::1000 (uphill) and destination address 1:3:1::2000 (down hill) NIRA employs IPv6 but it can support the first alternative if IPv6 did not pick up.

Handling Route Failure TIPP proactively notifies a user of the working conditions of routes failures - User has failure information before deciding the path if a router detects that a route is unavailable: Tries its best to send a send a message to original sender User propose alternative path upon receiving the message If a router is congested, the user should set timeout to resend the packet

Packet Forwarding If a user choose the path: N1  R1  B1  B2  R3  N3 Forwarding decision for “  ” will be decided by “core” provider B1 Core graph is dense Overhead on user to decide core- level routing

Scalability Systems store the addresses where it can be reached in NRLS Users query destination the same way in DNS Is NRLS lookup service a scalability bottleneck ? Internet topology (at the domain level) changes at a low frequency Changes in topology is due to business relationship so it can be controlled

Evaluation Measurements are done through Simulations Main Highlights from the evaluation: 1. Nira is scalable About 90% of the domains have less than 100 forwarding entries. (Practical for the current internet scale) 2. Low Message Overhead Average time between failure detection and receiving last notification is 10ms to 110ms. (Proportional to link delay) 3. Latency to send a connection setup packet such as a TCP SYN is negligible

Discussion Questions What are other scenarios where a user would like to choose the routing path between ISPs ? Do you think deploying such architecture will have an impact on the quality of service for internet users ? Why ? Why not ?

Discussion Questions (2)