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

2. 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

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

4. 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%

5. 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

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

7. 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

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

9. 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!

10. 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

11. 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.

12. 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)

13. 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.

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

15. 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

16. 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 , 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)

17. 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

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

19. 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?

20. 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

21. 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

22. 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