Distributed Faulttolerant Proxy Network with QoS Support

1
Distributed Fault-tolerant Proxy Network with QoS
Support
2
Problem Description

• The proxy network as a whole should provide QoS
  globally to users. (Solve the merging problem.)
• The proxy network should tolerate failures of
  individual proxies.
• The proxy network should be able to balance load
  across individual proxies in order to achieve
  better efficiency.

3
Assumptions/Tools

• We know how to do fair schedule in a centralized
  fashion. A WFQ variant
• Keep some history for each user.
• Dynamically change number of queues
• Initially assume everyone in the same class (or
  in several known classes)
• Periodically sampling to find violators
• Put violators into separate queues.
• Each queue can be FIFO, which is fast. Sampling
  has little overhead (might be just increment
  counter). Total number of queue should not be
  huge provided there are not too many violators.

4
Assumptions/Tools (cont.)

• There are tools to help build fail-stop proxies
  especially against intrusion.
• Users are geographically distributed and the
  distribution does not change often.

5
High-level Design

• Virtual proxy glue between user and physical
  proxy
• Static mapping between user and virtual proxy
  solves merging problem.
• Migration of virtual proxies on physical proxies
  (virtual proxies are dynamically mapped to
  physical proxies) to balance load and to mask
  failure of physical proxies.

6
Design Load Balance FT
Gossip
A Lead
B Lead
Proxy Group A
Proxy Group B
gossip
gossip

• Physical proxies are organized into proxy groups.
  Each virtual proxy has a home proxy group.
• Each physical proxy is responsible of a set of
  virtual proxies. Group members periodically
  exchange gossip messages to balance load.
  (Virtual proxies migrate inside proxy group)
• Group leads infrequently exchange gossip messages
  to balance load across proxy groups.

7
Design - Routing

• Inside each proxy group, every group member keeps
  a table of current mapping for each group member.
  The table is updated in the gossip protocol.
• Each group lead keeps two tables emigrant table
  and visitor table. (Since migration across proxy
  groups have to go through group lead, it is easy
  to maintain those lists.)
• When a virtual proxy migrates
• Inside group, only involved members update their
  lists
• Across groups, both involved members and involved
  team leads update their tables.
• To locate a virtual proxy starting from any
  physical proxy
• Search locally (usually virtual proxies dont
  travel far, so most possibly it can be located
  locally.
• If failed, pass the request to group lead, and
  search globally.
• If all failed, return error to user. User should
  retry later.

8
Other problems

• Prevent massive propagation of worms/viruses,
  which may generate huge amount of traffic to slow
  down the whole network.
• Prevent intrusion on the application itself.