The SAHARA Four-Layer Model; Case-studies in Composition Bhaskaran Raman, Jimmy Shih, Randy H. Katz, SAHARA, EECS, U.C.Berkeley

Layered Reference Model for Service Composition End-User Applications Composition Service Applications Services Application Plane Middleware Services End-to-End Network With Desirable Properties Enhanced Paths Connectivity Plane Enhanced Links IP Network

Work in Progress Enhanced Links Congestion Pricing for Access Links Auction-based Resource (Bandwidth) Allocation Traffic Policing/Verification of Bandwidth Allocation

Congestion Pricing at Access Links Internet Local Area Network Computer Access Router QoS $ Setup 10 users 3 QoS (Slow-going, Moderate, & Responsive) differ on degree of traffic smoothing 24 tokens/day, 15 minutes of usage per charge Acceptable Users make purchasing decision at most once every 15 minutes Feasible Changing prices cause users to select different QoS Effective If entice half of users to choose lower QoS during congestion, then reduce burstiness at access links by 25%

Auction-based Resource Allocation Problem Efficiently and effectively allocate resources according to application’s dynamic requirements Approach Leveraging auction schemes and work-load predictions Resource Auctioneer Bidder Application Capabilities Bidders can place bids based on application requirements and contention level. Bidders can place bids for near future resource requirements based on recent history. Bidders can express both utility and priority to auctioneer. Auctioneer can dynamically change application’s priority by changing the token allocation rate. Status On-going work First application: bandwidth allocation in ad hoc wireless networks

Mobile Virtual Network Operator: Composition and Cooperation InterCall M-to-N Relationships Competition one2one 1-to-1 Relationship

Bandwidth Allocation R1 attaches new certificate to the refresh message Problem: scalable (stateless) and robust bandwidth allocation Control Plane: Soft state Per-router per-period certificates for robustness without per-flow state Random sampling to prevent duplicate refreshes Data Plane: Monitor aggregate flows Recursively split misbehaving aggregates misbehaving aggregate – split it

Work in Progress Enhanced Paths BGP Route Flap Dampening BGP Policy Agents Backup Path Allocation in Overlay Networks Host Mobility Multicast Interoperation

BGP: Stability vs. Convergence Problem: Stability achieved through flap damping[RFC2439] Unexpected:flap damping delays convergence! Topology: clique of routers Solution: selective flap damping [sigcomm02] Duplicate suppression: Ignore flaps caused by transient convergence instability Still contains stability Eliminates undesired interaction!

Policy Management for BGP 3-15 minute failover time Slow response to congestion Unacceptable for Internet service composition 8898 AS’s 971 AS’s 897 AS’s 129 AS’s 20 AS’s Lack of distributed route control Need distributed policy management Explicit route policy negotiation Identified current routing behavior Inferred AS relationships, topology Next : gather traffic data, finish code, emulate

Backup Path Allocation in Overlay Networks The Overlay Network The Underlying Network Challenge Disjoint primary and backup path in the overlay network may share underlying links because the overlay network cannot control underlying links used by a path Problem Find a primary and backup path pair with minimal failure probability based on correlated overlay link failures Approach Decouple backup path routing from primary path routing Route backup paths based on failure probability cost which measures the incremental path failure probability caused by using a link in the path Main Result Can be 20-30% more robust compared to shortest disjoint path allocation Status Finished work, submitted to ICNP’02 Randy, please note the animations in the figure. It shows the process of setting up the primary and backup path in the overlay network. I also want to use it to show link sharing in the underlying network.

Host Mobility Using an Internet Indirection Infrastructure The Problem Internet hosts increasingly mobile; need to remain reachable Flows should not be interrupted IP address represents unique host ID & net location ROAM (Robust Overlay Architecture for Mobility) Leverages i3: overlay network triggers & forward packets Efficiency, robustness, location privacy, simultaneous mobility No changes to end-host kernel or applications Cost: i3 infrastructure, and proxies on end-hosts Simulation & Experimental Results Stretch lower than MIP-bi  able to choose nearby triggers 50-66% of MIP-tri when 5-28% domains deploy i3 servers Even 4 handoffs in 10 seconds have little impact on TCP performance (ID, data) (ID, R) Sender (S) (ID, data) (ID, R) Receiver (R)

Multicast Broadcast Federation Goal : compose different non-interoperable multicast domains to provide an end-to-end multicast service. Should work for both IP and App-layer protocols. Approach : overlay of Broadcast Gateways (BGs) BGs establish peering between domains. Inside a domain, local multicast capability is used. Clustered gateways for scalability. Independent data flows and control flow. Source Broadcast Domains CDN IP Mul SSM Clients BG Data Peering Implementation : Linux/C++ event-driven program Easily customizable interface to local multicast capability (~700 lines) Upto 1 Gbps BG thruput with 6 nodes. Upto 2500 sessions with 6 nodes.

Work in Progress Middleware Services Measurement and Monitoring Infrastructure Robust Service Composition Authorization Interworking

Internet Distance Monitoring Infrastructure Problem: N end hosts in different administrative domains, how to select a subset to be probes, and build an overlay distance monitoring service without knowing the underlying topology? Solution: Internet Iso-bar Clustering of hosts perceiving similar performance Good scalability Good accuracy & stability Tested with NLANR AMP & Keynote data Small overhead Incrementally deployable [SIGMETRICS PAPA 02] & [CMG journal 02] Cluster C Cluster B Cluster A Monitor Distance from monitor to its hosts End Host Distance measurements among monitors

Availability in Wide-Area Service Composition Text Source Text to audio Issue: Multi-provider  WA composition Poor availability of Internet path  Poor service availability for client Text Source Text to audio >15sec outage Note: BGP recovery could take several minutes [Labovitz’00] Fix: detect and recover from failures using service replicas Highlight of results: Quick detection (~2sec) possible Scalable messaging for recovery (can handle simultaneous failure recovery of 1000s of clients) See SPECTS’02 paper More recent results on load balancing across service replicas… End-to-end recovery in about 3.6sec: 2sec detection, ~600ms signaling, ~1sec state restoration Composition across providers implies path could stretch across the wide-area For instance, the picture shows a service involving a text-source such as email, and a text-to-speech engine Wide-area Internet path availability is not great (studies by Labovitz, et.al.) This means poor availability for the composed service Make use of service replicas to dynamically switch from one service instance to another We have shown two things: Quick failure detection makes sense (within about 2sec), using aggressive heart-beats Scalable messaging – when 1000s of client sessions have to restored simultaneously, system does not break down due to message flood More details in SPECTS’02 paper The graph shows an experiment we ran across the wide-area, across 8 hosts These hosts represent university hosts in US, commercial end-points, as well as trans-continental links There are two client sessions of the composed text-to-speech application: one with recovery mechanism enabled, one without X-axis shows time, as the sessions proceed Y-axis shows the loss-percentage of audio packets received at the end-client, computed over 5sec intervals The session without any recovery mechanism sees an outage of over 15sec Due to recovery, the green line recovers in about 3.6sec (within bounds of end-client buffering) We have also studied algorithms for load-balancing across service replicas, in this context of dynamic session recovery to improve availability WA setup: UCB, Berk. (Cable), SF (DSL), Stan., CMU, UCSD, UNSW (Aus), TU-Berlin (Germany)

Authorization Control Across Administrative Domains Trusted third party Should grant access? Authorization Authority Service Decision Request - certificates - credentials Policy compliance check Verification Certificates Credentials Credential transformation Domain 2 User Trust peering agreement - credential transformation rule Authorization authority Provides authorization decision service. Manages different verification methods and credentials. Trust peering agreement Credential transformation rule Acceptable verification method

Work in Progress Applications Services Voice Over IP Adaptive Content Distribution (Universal In-Box)

IP Telephony Gateway Selection ITG LS ITG LS Our system architecture is based on that specified in the Telephony Routing over IP framework. There are three types of functional entities: First, Internet Telephony Gateways, or ITGs, act as application layer proxies to provide call transit to the PSTN. These ITGs may be widely distributed Geographically and may offer varying degrees of reachability to various locations on the Internet. Second, End hosts running IP Telephony software perform encoding and signaling for the call. Finally, Location Servers maintain a distributed database of ITG resources in the network. When an ITG advertises a status update to its LS (click) The LS propagates the advertisement to neighboring Administrative domains (click) which propagate the advertisement to their peers until all LSs receive the update. Note that: The IP network interconnecting location servers suffers from packet loss and delay. Because of this, the location server can have out of date information. These entities are grouped into administrative domains, which are operated by a single provider. Call setup takes place as follows: (click) Software running on the user’s pc contacts the LS (click) The LS returns an ITG’s IP address (click) The user sends a connection setup request (click) A call accept or reject is then returned to the client. (click) If the call is accepted, the call is path is setup over the PSTN, (click) and the connection is then established. ITG LS Gateway (ITG) IP Terminal Location Server (LS) ITG LS Load Advertisement Call Session Results: Congestion sensitive pricing decreases unnecessary call blocking, increases revenue, and improves economic efficiency Hybrid redirection achieves good QoS and low blocking probability Goal: High quality, economically efficient telephony over the Internet Questions: How to Perform call admission control? Route calls thru converged net?

SCAN: Scalable Content Access Network Problem: Provide content distribution to clients with small latency, small # of replicas and efficient update dissemination Solution: SCAN Leverage P2P location services to improve scalability and locality Simultaneous dynamic replica placement & app-level multicast tree construction data source data plane Close to optimal # of replicas wrt latency guarantee Small latency & bandwidth for sending updates [IPTPS 02] & [Pervasive 02] cache adaptive coherence always update replica Tapestry mesh client Web server SCAN server network plane

Layered Reference Model for Service Composition Composed Service at Layer i Policy Management Dynamic Resource Allocation Interoperabilty Measurement-based Adaptation Trust Management/ Verification Underlying Composition Techniques Services at Layer i-1 Other Services at Layer i Component Services

Evaluation: Emulation Testbed Idea: Use real implementation, emulate the wide-area network behavior (NistNET) Opportunity: Millennium cluster Rule for 12 App Emulator Node 1 Rule for 13 Lib Rule for 34 Node 2 Rule for 43 Node 3 Node 4 Also have limited (8-node) wide-area testbed