1. Proposal: A General Infrastructure for Efficient Application-Level Protocols Steven Czerwinski
Goal: To investigate ways to make application-level protocols less sensitive to low bandwidth and high latencies and to create an infrastructure to support the solution.

2. The Problem: Inefficient Protocols
Protocol standardization leads to inefficiencies
Compromise leads to “no one wins” situations
Different situations have different bandwidth needs
But protocols are often developed with only a few settings
RTT sensitivity arises from mismatch of client’s needs
Multiple protocol commands issued to perform a client action
Client must check result of each command before issuing next
Standardization favors text-based protocols
But text-based are not bandwidth efficient
Mailbox Sync
Message Move
Message Fetch
44 ms
320 ms
22 ms
160 ms
6 ms
75 ms
2 ms latency
70 ms latency
IMAP Operation Times across Different Connections

3. Common solutions Code migration Data migration
Home Server
Code migration
Examples: SQL, postscript, etc..
Pro: Solves mismatch problem
Con: Usually tied to particular language
Data migration
Examples: web caching
Pro: Reduces RTT to “server”
Con: Incremental solution
Mobile code
(high latency)
Client
Home Server
Cache Agent
Client

4. Proposed System Generalized meta-protocol
Support access to XML structured data
Higher-level protocols layered on top
Infrastructure to support data and code migration
Data access is done via a mobile scripting language
Trusted access servers scattered throughout network
Code is passed by reference
Scripting language allows for complex behavior
Create cache validation and tentative commits as fundamental operations
Introspection of code allows for optimization

5. Architecture Code Server Home Server Client Local Access Server
User State
(Permanent Home of user’s data)
Local Access Server
CodeURL=netscape-imap-4.2 init czerwin password
Authenticate czerwin password foreach folder x in (Match <folder>yes</folder> <user>czerwin</user>) send tags x <foldername> <foldersize><unread>
Client
Login accepted, (INBOX, 25, 5), (Ninja, 20, 0) ...

6. Access language environment
Functional based for lowest common denominator
Client functions receive parameters, return results
Control structures and looping included
XML manipulation operations built into language
Cache validation operations
Operations to hash sets of data for comparing states
Query operations only return deltas when possible
Tentative commit & conflict resolution operations
Allow tentative commits to form branches
Support shared libraries, negotiated at handshake
Performance enhancing code (such as compression) can be optionally linked in

7. Adaptability and Optimization
Opportunities for adaptability
Trade off between code migration and data migration
Avoid data migration when bandwidth to client is small
Aggressively migrate code when client is computationally poor
Initial requests sent to remote server until data migrated
Optimization
High-level data access commands allow for optimization
Profiling of data access patterns allows for pre-fetching and optimistic concurrency
Allow for application level hints for optimization
Common client libraries preloaded into servers

8. Alternative: Data structure library
Access remote state via data structure library
Data structures hide cache, connectivity, commit issues
Protocols built on top of data structures
Pros
Easier protocol development
Data always in binary form
Cons
Library language dependent
No code migration
Client Device
Client App
(Data structure Library)
Associate Array
Local Access Server
Home Server

9. Where to begin? Measure and trace current protocols
Detailed analysis of all the latencies involved
Benchmark different clients use of the same protocol
Possible protocols: IMAP, LDAP, HTTP (suggestions?)
Solve problem for one protocol
Build flexible proxies that mimic code migration and perform data migration
Design access language
Is it possible to design with a small set of operations?
Model protocol implementations on infrastructure
Use collected traces to determine actual performance