GEMINI: 091412_gemini_phoebus.txt

File 091412_gemini_phoebus.txt, 3.9 KB (added by Jeanne Ohren, 7 years ago)
1=== Phoebus/XSP Reference Experiment for GEMINI I&M ===
3GEMINI needs a reference "use case" to demonstrate common features of the I&M
4architecture when approached from an experimenter's perspective.  Additionally,
5the experimental environment should be flexible enough to allow its use in
6future GEMINI tutorials.
8==== Component Overview ====
10Phoebus is a performance-enhancing software router platform built on the
11eXtensible Session Protocol (XSP) framework.  Nodes running Phoebus software are
12called "Phoebus Gateways", or PGs.  Applications can make use of the PG nodes
13through the XSP client libraries, which includes a transparent wrapper.  On
14Linux systems, the wrapper intercepts standard socket() calls and can redirect
15TCP flows over one or more PGs.  This path is known as an "XSP PATH", and can be
16configured in the local shell environment or programmatically via the XSP client
17API.  The configuration of a PG also allows for a number of static routes (i.e.,
18XSP "next-hops") to be defined for specified IP prefixes.
20The typical use case for Phoebus is that of bulk data movement over high-latency
21WAN paths, often with a less than ideal "edge" network on either side of the WAN
22link.  We can achieve significant performance improvements for applications that
23use Phoebus compared to the direct, or pure end-to-end, case.  Typical testing
24applications include network benchmarks such as iperf, netperf and file transfer
25tools such as ftp/sftp, GridFTP, etc.  For GridFTP in particular, we have
26developed custom drivers for Phoebus and XSP within the Globus framework on
27which GridFTP is built.  The driver allows GridFTP to use Phoebus directly with
28command line options, and the XSP driver includes instrumentation of the
29application that can be exported to a GEMINI MS.
31==== Typical Experiment Setup ====
33The most basic setup for evaluating Phoebus consistes of 3 nodes in a linear
34topology: two clients separated by a PG node.  The clients can either
35communicate directly across the PG node (using standard Linux routing) or can
36redirect flows over the PG service itself using the methods listed above.
37Without any unique network characteristics on the two links, the performance in
38either case will be virtually the same.  To make things more interesting, the
39netem "network emulation" module (configured via the traffic control, 'tc', tool
40in Linux) can be used to add various amounts of latency and loss to the node
41interfaces.  Adding these artificial impairments allows us to evaluate the
42benefits of the Phoebus approach in mitigating the effects of TCP behavior over
43less than ideal network conditions.  The existing experiment is detailed here:
48==== Future Directions ====
50* Eliminate the need for users to login to the nodes to start traffic
51  experiments.  Integrate reference experiment into GEMINI GUI.  Develop a
52  "Start Experiment" button that would automatically start pre-installed
53  software and scripts.
55* Increase the flexibility of the experiment.
57** 1) Let users easily choose between "direct" and "Phoebus" transfer cases.
59** 2) Increase complexity of the topology to allow for alternate routes to be
60   chosen.  This could easily be accomplished by dynamically updating the XSP
61   PATH used, or altering the linux routing tables for certain nodes. This also
62   hinges on how many resources we expect the reference experiment to use, and
63   how much we expect to support more dynamic topologies.
65** 3) Have a GUI menu for choosing different network impairments setup with
66   netem. These effects would be easily visible in the active and passive
67   measurements collected by GEMINI.
69* Improve unique measurement collection from the experiment.  Show how the
70  application (i.e., GridFTP) can push measurement metadata/data to a MS and
71  make them visible.