# Presentation: 013564

## Coupling Prefix Caching and Collective Downloads for Remote Scientific Data

- Xiaosong Ma,1,2 _**Sudharshan Vazhkudai**_,1 Vincent Freeh,2 Tyler Simon,2 Tao Yang,2 and Stephen Scott 1
- 1 Oak Ridge National Laboratory
- 2 North Carolina State University
- ICS’06 Technical Paper Presentation
- Session: Memory I
- June 30, 2006
- Cairns, Australia

## Outline

- Problem space: Client-side caching
- The Prefix caching problem
- FreeLoader backdrop
- Prefix caching
- Architecture
- Model
- Collective downloads
- Performance

## Problem Space: Client-side Caching

- HTTP caches
- Proxy caches (Squid), CDNs (Akamai)
- Benefits
- Reduces server bandwidth consumption, load and latency
- Improves client perceived throughput
- Helps exploit locality
- Benefits amplified for large, media downloads
- What of scientific data, then?
- Data Deluge!
- User access traits on large scientific data
- Local processing/viz of data
**Implies downloading remote data **
**(FTP, GridFTP, HSI, wget)**
- Shared interest among groups of researchers
**A Bioinformatics group collectively analyze and visualize a sequence database for a few days: ****Locality of interest!**
- More and more, applications are latency intolerant
- Transient in nature
- Examples: FreeLoader (ORNL/NCSU), IBP (UTK), DataCapacitor (IU), TSS (UND)

## The Prefix Caching Problem

- HTTP Prefix Caching
- Multimedia, streaming data delivery
- BitTorrent P2P System: leechers can download and yet serve
- Benefits
- Bootstrapping the download process
- Store more datasets
- Allows for efficient cache management
- Enabling Trends: Scientific data properties
- Usually write-once-read-many
- Remote source copy held elsewhere
- Primarily sequential accesses
- Challenges
- Clients should be oblivious to dataset being partially available
- Performance hit?
- How much of the prefix of a dataset to cache?
- So, client accesses can progress seamlessly
- Online patching issues
- Client access to remote patching I/O mismatch
- Wide-area download vagaries
- Can we do something similar for large scientific data accesses?

## Backdrop: FreeLoader Collaborative Desktop Storage Cache

## Prefix Caching Architecture

- Capability-based resource aggregation
- Persistent storage & BW-only donors
- Client serving: parallel get
- Remote patching using URIs
- Better cache management
- Stripe entirely when space available
- When eviction is needed, only stripe a prefix of the dataset
- Victims based on LRU:
- Evict chunks from the tail until a prefix
- Entire datasets evicted only after all such tails are evicted

## Prefix Size Prediction

- Goal: Eliminate client perceived delay in data access
- What is an optimal prefix size to hide the cost of suffix patching?
- Prefix size depends on:
- Dataset size, S
- In-cache data access rate by the client, Rclient
- Suffix patching rate, Rpatch
- Initial latency in suffix patching, L
- Client access rate indicative of time to patch, S/Rclient = L + (S – Sprefix)/Rpatch
- Thus, Sprefix = S(1 – Rpatch/Rclient) + LRpatch

## Collective Download

- Why?
- Wide-area transfer reasons:
- Storage systems and protocols for HEC are tuned for bulk transfers (GridFTP, HSI)
- Wide-area transfer pitfalls: high latency, connection establishment cost
- Client’s local-area cache access reasons:
- Client accesses to the cache use a smaller stripe size (e.g., 1MB chunks in FreeLoader)
- Finer granularity for better client access rates
- Can we derive from collective I/O in parallel I/O

## Collective Download Implementation

- Patching nodes perform bulk, remote I/O; ~ 256MB per request
- Reducing multiple authentication costs per dataset
- Automated interactive session with “Expect” for single sign on
- FreeLoader patching framework instrumented with Expect
- Protocol needs to allow sessions (GridFTP, HSI)
- Need to reconcile the mismatch in client access stripe size and the bulk, remote I/O request size
- Shuffling
- Patching nodes, p, redistribute the downloaded chunks among themselves according to the client’s striping policy
- Redistribution will enable a round-robin client access
- Each patching node redistributes (p – 1)/p of the downloaded data
- Shuffling accomplished in memory to motivate BW-only donors
- Thus, client serving, collective download and shuffling are all overlapped

## Testbed and Experiment setup

- UberFTP stateful client to GridFTP servers at TeraGrid-PSC and TeraGrid-ORNL
- HSI access to HPSS
- Cold data from tapes
- FreeLoader patching framework deployed in this setting

## Collective Download Performance

| PW=10; I/O=256M | Download | Download + Shuffle | Client access |
| --- | --- | --- | --- |
| HPSS | 13.6 | 12.3
-9.6% | 11.7
-4.9% |
| Tera-ORNL | 79.7 | 75.1
-5.8% | 74.7
-1.3% |
| Tera-PSC | 21.9 | 20.2
-7.8% | 20
-1.0% |

## Prefix Size Model Verification

| Data sources | HPSS-ORNL | Tera-ORNL | Tera-PSC |
| --- | --- | --- | --- |
| Rclient (MB/s) | 52.2 | 52.2 | 52.2 |
| Rpatch (MB/s) | 7.6 | 42 | 10.8 |
| L (s) | 31.4 | 3 | 3.9 |
| Predicted ratio | 95% | 24.6% | 81% |

## Impact of Prefix Caching on Cache Hit rate

| Jefferson Lab Asynchronous Storage Manager (JASMine) |  |
| --- | --- |
| No of days | 19.1 |
| No of accesses | 4000 |
| No of unique datasets | 1686 |

- Tera-ORNL will see improvements around 0.2 and 0.4 curve (308% and 176% for 20% and 40% prefix ratio)
- Tera-PSC sees up to 76% improvement in hit rate with 80% prefix ratio

## Summary

- Demonstrated prefix caching for large scientific datasets
- Novel techniques to overlap remote I/O with cache I/O
- A simple prefix prediction model
- Patching with different storage transfer protocols
- Rich resource aggregation model
- Impact on cache hit ratio providing a “virtual cache”
- In summary, novel combination of techniques from the fields HTTP multimedia streaming and parallel I/O
- Future:
- Use patching cost in conjunction with frequency of accesses to determine which/how much of a dataset to keep in cache: latency-based cache replacement