Low Bandwidth Networking Project:
Requirements

Last update: 2006-11-20 by David Pierce <chikuru@mali.geekcorps.org>

Scope

This document describes the requirements for the Low Bandwidth Networking project, to be implemented in the villages of Bourem Inaly and Bourem Foghas.

We envision using a split proxy with caching and filtering on both server and client side. On the client side, the customer will be able to access email and the Internet (with limits on amount of data transferred). Both server and client will filter out email attachments and images. The server will filter out ads.

The connection path between client and server is

client >> RBGAN modem >> satellite >> inmarsat.com >> Internet >> server

To avoid unnecessary latencies between the inmarsat.com and the server, the server will reside in the United States. Minimizing latency is important because we want to support instant messaging between stations.

Based on previous experience (Ian Howard, RANET project), the server may need to be more than a virtual server. Squid and loband, for example, require significant resources.

Server-side Proxy

The server, managed by Geekcorps Mali (GCM), will act as a proxy server for multiple clients. It will provide limited access to email, the Internet, and instant messaging. It will allow a system administrator at GCM to monitor customers' network usage.

Client-side Proxy

The client is a single computer that serves as firewall, cache, and customer workstation. We do not anticipate connecting additional client computers. The client can only connect to the GCM proxy server, which it does using an RBGAN modem.

Use Cases

  1. Customer reads the daily news, pulled from RSS feeds.
  2. Customer reads weather bulletins, updated every hour.
  3. Customer sends and receives email (limited in number and size).
  4. Customer browses the Internet. All data is filtered through the server-side proxy server and cached in the local proxy server.
  5. Customer uses interactive web pages, e.g., to fill out forms.
  6. Customer does instant messaging, limited to rates sufficient for chatting.
  7. The client computer limits bandwidth to a maximum instantaneous rate.
  8. The client computer limits bandwidth on a daily basis. The bandwidth not used on one day is available the next day.
  9. Customer monitors total usage and remaining funds, just as with cell phones.
  10. The server computer filters spam.
  11. The server provides statistics on customer's total usage and remaining funds.

Non-Use Cases

  1. Customers cannot install new software.
  2. Customers cannot access the Internet except through the proxy server.
  3. Customers cannot send or receive email attachments.

Requirements

  1. All of the use cases are supported.
  2. All data sent between server and client is compressed.
  3. All nonessential content (images, ads, etc.) will be filtered out at the server.
  4. Throughput is artificially throttled so that performance better reflects actual cost.

Relevant Technologies

Most of the entries in this list were culled from the documents Wireless Networking in the Developing World and Autonomous and Remote Computing Platforms for Installations in Lesser Developed Countries.
  1. Server-side Administration / Troubleshooting / Development
    1. Protocol Analyzers
      1. Ethereal
      2. Kismet
      3. Driftnet
      4. Etherpeg
    2. Bandwidth Monitoring
      1. MRTG
      2. RRDTool
      3. NTOP
      4. Cacti
      5. iptraf
    3. Troubleshooting
      1. ping
      2. traceroute
      3. mtr
    4. Throughput
      1. ttcp
      2. iperf
    5. Network Health
      1. cacti
      2. SmokePing
      3. Nagios
  2. To Use in the Implementation
    1. iptables (firewall)
    2. SQUID (caching server, compressing)
    3. Dan's Guardian (web site content filtering)
    4. Skweezer (proxy that reformats for PDAs or cellphones)
    5. dnsmasq (caching DNS and DHCP server)
    6. Cameleon -  http://www.sysctl.org/cameleon (ad blocker)
    7. CBQ (shaper, rate limiter)
    8. UUCP (remote copying with compression)
    9. loband.org (stripping web pages)
    10. procmail (white lists, email to text)
    11. spamassassin
    12. ClamAV (virus filtering)
    13. Jabber (with the jabber server running on the GCM server)
    14. Ruby (general programming language to glue the pieces together)

Scenarios

We will expand these in the design phase and use them to make sure we have a complete design. We will also use them to test the implementation.
  1. Customer requests page from local cache.
  2. Customer requests page from remote cache.
  3. Customer requests page not in either cache.
  4. Customer interacts with web page with a form.
  5. Customer reads email.
  6. Customer sends an email.
  7. Customer attempts to send an attachment.
  8. Someone sends an attachment to the customer.
  9. Customer uses instant messaging.
  10. Customer attempts to send a file using IM.
  11. Someone attempts to send a file to the customer using IM.
  12. Customer attempts to use more than the bandwidth allotted for a given day.
  13. Customer queries client computer for his usage statistics.
  14. The server updates RSS feeds.
  15. The server monitors Jabber usage to record how often it is used for communication among radio stations.

Open Questions

  1. Where can we find documentation, tutorials, working examples, and forums for each relevant technology?
  2. Has this problem already been solved elsewhere? (E.g., for the RANET project or the Internet kiosks in India) Do we have access to the details of existing solutions?
  3. Is bandwidth being used whenever the client is connected to the satellite even when no data is being sent?
  4. Where does ifconfig get the number of packets and bytes from? NTOP may be overkill. Does Ruby have a library that could provide this information? Ian: get the data from /proc and /sys.