Active Names:Flexible Location and Transport of

Wide-Area Resources

Amin VahdatDuke University

Mike DahlinUniversity of Texas

Amit Aggarwal and Tom AndersonUniversity of Washington

http://www.cs.utexas.edu/users/less/bb/

Motivation

C N N

C N N

C N N

C N N

C N N

C N N C N N

DNS•Name IP Address

New naming abstractions: •Server selection, content selection, customization, device presentation, disconnected operation,...

Same name, different services•Traditional naming is only one step in larger process

Adding Flexibility Under Current Infrastructure

•HTTP redirect•DNS round robin•URN’s with sed scripts to mangle names •Cisco Local Director/Distributed Director•Mobile IP•Web caches/Active Caches•HTTP content negotiation•Dynamic distillation• ...

Each adds flexibility to one step in name bindingBut how do you combine services?

End-to-End, Flexible, Composable Name Resolution

DNS• Name IP Address

• Everyone gets same translation

• Protocol/path used to access service is fixed

Active Names • End-to-end

Translate from what user types to what data appear• Programmable

General-purpose programs for name resolution• Composable

Server and client customize path between them

Outline

Motivation

Architecture

Applications and Experiments

Conclusions

Active Names: Basic Idea

•Names identify a Namespace to interpret them•Namespace Programs have two tasks

1) Determine name and namespace to evaluate next2) Transport and transform data to that namespace

NameData

NamespacePrograms

Name’Data’

Location 1: DelegationDelegation: Hierarchical Namespaces

•Each namespace has jurisdiction over its names

•Delegation policy is namespace specifice.g., HTTP reply specifies namespace to handle future requests to subordinate URLse.g., DNS delegates based on administrative ownership

HTTP ServerCustomization CNN Customizer

Yahoo Customizer

Generic HTTP

Location 2: After Methods

Composability•Combine namespace programs

Integrate extensions provided by different parties (e.g., client+server)

After methods•Continuation-passing style of programming•Programs bundle remaining work into “after methods” before passing control

e.g. [modem-customizer|proxy|client] [proxy|encode|-decode|client]

Transport: Programming Model

Stream data model•Pipelining

Continuation-passing style•Return path may differ from request path•Minimize WAN communication

RequestReply

Client Program 1 Program 2

Data

Performance GainsApplication-customized transport protocolsLocation-independent programs

•Each program decides where it runs•Choose location to optimally utilize resources

(e.g., -encoding+transcoding to optimize slow link)•Customize close to client instead of at server

(e.g., to generate dynamic content near client)

3-way RPC

Client Proxy Server

Server

Client Proxy

Virtual MachineResolverNW

$Local Resources

NamespacesHttp QRPC

Transcode Hit Count

...

Resolver Virtual MachineMicrokernel Approach

Java-based virtual machine •Sandbox namespaces•Access to other namespaces via Resolver•Controlled access to local resources

Hoard

Server Select

CNN

Yahoo

Applications and Experiments

Server selection:•End-to-end approach and extensibility

Mobile distillation:•Location independence

Distillation+ad rotation+hit counting: •Composability

Server Selection

DNS Round-Robin• Randomly choose replica• Avoid hotspots

Distributed Director• Route to nearest replica• Geographic locality

Active Naming• Previous end-to-end

performance• Adaptive

BerkeleyReplica

SeattleReplica

BerkeleyClients

Server Selection Performance

Optimal server selection varies with offered load• Low load: choose closest server• High load: distribute load randomly

Active Names framework provides• End-to-end measurements• Flexible algorithms

0

0.05

0.1

0.15

0.2

0.25

0.3

0 5 10 15Offered Load (active clients)

Res

pons

e T

ime

(s) Nearest

Active

Random

ComposabilityRecall: name resolution

• name service representative(s) result

Many entities customize name resolution• Client: device presentation, cache hierarchy to use,

hoarding, ...• Server: customization, server selection, consistency,

disconnected server, ...• Cache system: replica location, active caching, ...• Server replication system/Mirrors: service placement,

server selection, …• Cooperating services: content | language translator,

meta-search, ...

Composability: HTTP Caching

Reason % of Misses Possible StrategyCompulsory 19%-45% AN to widen cooperation,

prefetch,replicate server, transcode

Query/CGI 0%-34% AN ProgramCookie 35% AN for hit counting,

customization“Uncachable” 6%-9% AN for hit counting,

consistencyRedirect 4% AN server selectionConsistency:Slow Hit

2%-30% AN to improve consistency

HTTP cache hit rates 30%-50%• No “magic bullet” for making more web data cachable

• Use Active Names to combine strategies

Experiment

Composability•Server wants to make “uncachable” data cachable

Use ServerCustomization module to insert AdRotate module and HitCount module into pipeline

•Client on modem wants to improve miss timesUse ClientCustomization module to insert

DistillImage module into pipeline

0

5

10

15

20

25

30

1 3 5 7 9

11 13 15 17 19

RequestR

espo

nse

Tim

e (s

)

Composability Results

• Early requests: Distillation makes misses faster• Later requests: Server cust. makes misses into hits • Combined server and client strategies best

0

5

10

15

20

25

30

Request

Resp

onse

Tim

e (s

)

ServerCust: ON Distillation: OFFServerCust: OFF Distillation: OFF

Per-Request Times Cumulative Avg. Times

ServerCust: ON Distillation: ONServerCust: OFF Distillation: ON

Status and Future WorkStatus: Active Names Framework

•Framework for distributing name resolution programs across WAN

http://www.cs.utexas.edu/users/less/bb/

Issues• Infrastructure

Improved cache consistency and distributed stateResource allocationDebuggingSecure RMI

•Distributed servicesServer placement and selection algorithmsNetwork mapping

• ...

ConclusionsActive Name: • Mobile programs to locate services and transport data• Programmability addresses needs of WAN services

Design emphasizes• Efficiency in WAN

Pipelining, n-way RPC, location independence• Extensibility, composability

Delegation, continuation-passing style

Related Work

Point solutions• see above

Extensible frameworks• Ninja (Gribble et. al)• Intentional naming (Balakrishnan et. al)• Active networks (…)• Transaction monitors

Status and Future Work

Status: Active Names• Framework for distributing name resolution programs

across WAN

Issues• Stringent cache consistency requirements• Server placement and selection algorithms• Resource allocation• Debugging• Simplify distributed security

Active Naming ApproachUnified end-to-end framework to match new name resolution abstraction•Extensible and composable

• General-purpose programs for name resolution• Service and client control name resolution• Service and client control transport of data

•Efficient in WAN

Example: Mobile Distillation

Clients name a single object

Returned object based on client• Network connection, screen

Current approach [Fox97]• Proxy maintains client profile• Requests object, distills

Active naming• Transmit name + applet• Flexible distillation point• Tradeoff computation/bandwidth• Support mobile clients

Client-Specific Naming

Variables: Network Screen

0

10

20

30

2 3 4 6 8 10 12 15 20

Number of Clients

Dis

till

atio

n L

aten

cy (

s)

Active

Server

Proxy

Importance of Location Independence I

Distill 59 K image to 9 K

Clients/Proxy at UC Berkeley

Server at Duke

Active Policy tracks then beats best static policy

0

10

20

30

40

2 4 6 8 10 12 15 20

Number of Clients

Dis

tilla

tion

Late

ncy

(s)

Active

Server

Proxy

Importance of Location Independence II

Server loaded with 10 competing processes

No longer makes sense to perform all distills at server

Dynamic placement of computation for optimal performance

Active Naming Vision

Today: Name is static binding to physical location and object (DNS, LDAP)

Want: dynamic, flexible binding to service/data• Server selection among geographic replicas (CISCO, IBM,

etc.)• Client customization (e.g., distillation, custom CNN)• Server customization (e.g., hit counting, ad rotation, etc.)

An Active Name is a mobile program that invokes a service or acquires data• Flexibly support various naming semantics• Minimize wide-area communication

Active Name ArchitectureResolver Virtual Machine

Local Resources

NamespaceNameAfter Methods

Data

Location

Transport

Namespace’Name’After Methods’Data’

NamespaceProgram

Namespace Program

Active Name

Active Name Resolution

NamespaceNameAfter Methods

Data

LocationTransport

Namespace Program Namespace’

Name’After Methods’

Data’

Namespace Program: A filter with two tasks:• Locate next filter to run• Transport data to next filter

Multi-Way RPC

Goal: minimize latency• Usually have to pass results down a

hierarchy• Adds latency• Store and forward delays

Multi-Way RPC via after methods• Last after method transmits result

back to client• Minimize latency• Use capabilities for security

P

C P

P

S P

P

C P

P

S P

Multi-Way RPC

Traditional

Request

Request

Response

Response

Advantages

• End-to-end semantics• Location independence• Extensibility and composability • Minimize wide-area communication

RequestClient Program 1 Program 2

Data

Change the Socket API?

Name resolution v. service access • Traditional model separates resolution from service access

ipaddr = gethostbyname(“www.cs.utexas.edu”);socket = connect(ipaddr, 80);write(socket, “GET /index.html HTTP/1.0\n\n”);read(socket, buffer);

• Active names integrates location and transportbuffer = Resolver.Eval(“(HTTP) www.cs.utexas.edu/index.html”);

Hide physical address from programmer• Allows for reorganization under the hood• End-to-end approach

Security•Protection between active name programs provided by Java’s type safety mechanism.

•Caller passes a certificate to the callee granting it a subset of its rights.

•Transitive closure of the certificates determines the rights of a principal.

•For instance, each caller might grant its callee the right to respond to the client.

Composability Results

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Request

Re

spo

nse

Tim

e (

s)

ServerCust: ON Distillation: OFFServerCust: OFF Distillation: OFF

ServerCust: ON Distillation: ONServerCust: OFF Distillation: ON

• Combined server and client strategies give best performance

Composability Results

0

5

10

15

20

25

30

Request Number

Re

sp

on

se

Tim

e (

s)

ServerCust: ON Distillation: OFFServerCust: OFF Distillation: OFF

ServerCust: ON Distillation: ONServerCust: OFF Distillation: ON

• Combined server and client strategies give best performance

Extensible caches:Reason % of Misses Possible Strategy

Compulsory 44.8% (DEC) Widen cooperation, Prefetch

Query/CGI ~20% (UW) AN Program

Cookie ~35%(UW) AN for hit counting,customization

“Uncachable” ~9% (UW) AN for hit counting,consistency

Redirect 3.7% (DEC) AN server selection

Misc. 11.5% (DEC) Error handling, etc.

No “magic bullet”: need composability

Background and MotivationGoal: programmable name --> result binding

Active naming• Common framework for interposing program on name-to-

object translation• Set of applications

Note: Much in common with Active Networks, Detour

ProgramName Data

Wide Area Naming Today

Client Cache1 Name

DNSServer

2 Host Binding

HTTPServer

3 URL Redirect

4 URL HTTPServer

5 Name Program 6 Data

Name translation often just one step in larger request

Extending WAN Data-delivery Architectures

Many proposed improvements; few used• Server multiplexing [CISCO, Smart Clients,

HTTP Redirect, Ammar et. al, ...]

• Flexible cache consistency [Tannenbaum et. al, Yin et. al]

• Multimedia caching• Dynamic distillation [Brewer et. al]

• Delta-encoding [Mogul et. al]

• Active caches and hit counting [Cao, Mogul, …]

“Monolithic” protocol structure

Requirements and Goals“Forward compatibility”/easy to deploy new services

• Dynamically download, safely execute code• No central code repository

Compose services• After methods• Namespace delegation

Minimize/hide network latency• “3-way RPC”/Continuation-passing• Pipeline-data model• Location independence

Core System

Virtual Machine

ResolverNW $

Local Resources

NamespacesHttp

DNS

Distiller

HitCount

...

BackwardsCompatibilityFront-ends

Httpd

DNS

…Utilities

•“Microkernel” approach

Goal: Add New ServicesDynamically download/safely execute code

Resolver::Eval(ActiveName, …) • ActiveName uniquely identifies NamespaceProgram and

Name“Find Namespace and evaluate name”

• Resolver downloads and instantiates Namespaceor finds Namespace in cache

• Resolver calls Namespace.Eval(name, …)Namespace executes in a sandboxNamespace can access Resolver and LocalResources

No central code repository• Fetch via HTTP (or AName?)

Goal: Hide NW Latency3-way RPC

Pipeline-data model• InputStream Eval(ActiveName, InputStream, …)

Location independence• Programs may be executed anywhere• Programs can decide where they want to run

Request Namelet1 Namelet2

FrontEnd

HttpHttp

Http CNN

DecompDelta Dec

client proxy $

Delta Enc.Comp Http

Fallacy: URL --> ObjectAssumption needed for caching

• Reality: WWW is not fetch(objName)It is closer to execute(programName, args)

• Customization, Ad rotation– URL + cookie --> object – URL + MIME header --> object

• Hit counting– URL --> object + side effect

• Dynamic page generation– URL --> program output

• Volume/channel prefetching

Impact:• Many requests uncachable• Was this HTTP interface a mistake?

Security

Current: simple model• Each namespace owns its state• Namespaces can only touch Resolver, LocalResources

CRISIS library needed?• Delegation, fine-grained access control

e.g. I want remote job to be able to access exactly one file on local machine

• InterfaceStack inspection (Java)?Authenticated InputStreams (CRISIS)?

Resource management

Phase 1: requests should consume bounded resources• Associate request stream with a resource container

Other issues• Per request v. per-namespace restrictions

Is it: cycles, bandwidth v. state?

• Multi-resource restrictions• Multi-machine coordination• Real-time guarantees