Email 4B Email for Billions

1
E-mail 4B (E-mail for Billions)

• Mike Demmer, Bowei Du, Matt Piotrowski
• demmer, bowei, pio_at_cs.berkeley.edu

2
Context / Project goals

• Evaluate development platform targeted for
  developing regions
• Tiered infrastructure
• Datacenter, proxy, devices
• Delay tolerant networking (DTN)
• Communication using data mules, satellites, etc
• TIER programming API
• Toolkit for developers to write applications for
  a tiered infrastructure

3
Why E-mail

• E-mail is a good fit as a TIER application
• Asynchronous communication model
• Users can tolerate delays
• Only checking mail once a week gives us a week to
  deliver it
• Data messages of different sizes /
  characteristics
• Mail headers and status updates are small
• Larger mail body and attachments can be delivered
  on demand
• Network layer can optimize message routing based
  on application-specified semantics

4
Email-4B Architecture
5
Email-4B Architecture

• Data Center
• Reliable, permanent storage for all mail in
  system
• Serves as gateway between Internet and Mail4B
  infrastructure
• Proxy
• Local cache of mail storage for users in a single
  village
• Intermittent connection with Data Center (bus,
  satellite, )
• Provides village-area wireless networking
• Device
• Inexpensive hand-held class device
• Custom task-oriented email/voicemail interface
• Communicates through wireless network interface
  to proxy

6
Email-4B Architecture

• Proxy and Devices are caches
• Permanent copy of data exists only in the data
  center
• Reliability less of an issue
• Proxy state can always be restored from the data
  center
• Small storage requirements
• Space can be reclaimed by evicting old data and
  retrieved on user-demand
• Inexpensive Device Implementation
• Offload processing and storage to proxy

7
Optimal vs. Experimental Delivery Time
DC to Device mail messages

• Experimental Setup
• Ran experiments on the same host, intermittent
  connectivity simulated with firewall rules.
• DC and Proxy connected from 6pm-6am every day,
  Proxy and Device connected for 5 hours every 10
  hours
• Notes on Results
• Jumps due to intermittency
• Gaps due to DTN delays

DC
Proxy
Dev
Time Delivered (simulator seconds)
Device to DC mail messages
Message ID
8
Future Work

• Full system implementation for use here at
  Berkeley
• Local networking infrastructure to simulate
  TIER-like deployment environment
• Prototype application on an actual device
• Scalable cluster-based data center and storage
  implementation
• Extensions to DTN and TIER API based on project
  lessons
• Add caching support to TIER API

9
Future work - Multicast protocol

• Separate mail headers from body chunks (i.e.
  bodies and attachments)
• Create unique hash id for each chunk
• Send headers with a list of body/attachment ids
• Only send a chunk once to each proxy
• If more than one message includes an attachment,
  only need to transmit the data once.
• Chunks are retrieved on demand, saving bandwidth
• Device can selectively pull over attachments
• Proxy can do application specific reformatting
• e.g. remove color from images going to a b/w
  display