=== Phoebus/XSP Reference Experiment for GEMINI I&M ===

GEMINI needs a reference "use case" to demonstrate common features of the I&M
architecture when approached from an experimenter's perspective.  Additionally,
the experimental environment should be flexible enough to allow its use in
future GEMINI tutorials.

==== Component Overview ====

Phoebus is a performance-enhancing software router platform built on the
eXtensible Session Protocol (XSP) framework.  Nodes running Phoebus software are
called "Phoebus Gateways", or PGs.  Applications can make use of the PG nodes
through the XSP client libraries, which includes a transparent wrapper.  On
Linux systems, the wrapper intercepts standard socket() calls and can redirect
TCP flows over one or more PGs.  This path is known as an "XSP PATH", and can be
configured in the local shell environment or programmatically via the XSP client
API.  The configuration of a PG also allows for a number of static routes (i.e.,
XSP "next-hops") to be defined for specified IP prefixes.

The typical use case for Phoebus is that of bulk data movement over high-latency
WAN paths, often with a less than ideal "edge" network on either side of the WAN
link.  We can achieve significant performance improvements for applications that
use Phoebus compared to the direct, or pure end-to-end, case.  Typical testing
applications include network benchmarks such as iperf, netperf and file transfer
tools such as ftp/sftp, GridFTP, etc.  For GridFTP in particular, we have
developed custom drivers for Phoebus and XSP within the Globus framework on
which GridFTP is built.  The driver allows GridFTP to use Phoebus directly with
command line options, and the XSP driver includes instrumentation of the
application that can be exported to a GEMINI MS.

==== Typical Experiment Setup ====

The most basic setup for evaluating Phoebus consistes of 3 nodes in a linear
topology: two clients separated by a PG node.  The clients can either
communicate directly across the PG node (using standard Linux routing) or can
redirect flows over the PG service itself using the methods listed above.
Without any unique network characteristics on the two links, the performance in
either case will be virtually the same.  To make things more interesting, the
netem "network emulation" module (configured via the traffic control, 'tc', tool
in Linux) can be used to add various amounts of latency and loss to the node
interfaces.  Adding these artificial impairments allows us to evaluate the
benefits of the Phoebus approach in mitigating the effects of TCP behavior over
less than ideal network conditions.  The existing experiment is detailed here:

https://docs.google.com/document/d/17JsebJ0vi8zSH-s__o7U_Xii276lG6FqpB_QWHKSFYo/edit?pli=1


==== Future Directions ====

* Eliminate the need for users to login to the nodes to start traffic
  experiments.  Integrate reference experiment into GEMINI GUI.  Develop a
  "Start Experiment" button that would automatically start pre-installed
  software and scripts.

* Increase the flexibility of the experiment.

** 1) Let users easily choose between "direct" and "Phoebus" transfer cases.

** 2) Increase complexity of the topology to allow for alternate routes to be
   chosen.  This could easily be accomplished by dynamically updating the XSP
   PATH used, or altering the linux routing tables for certain nodes. This also
   hinges on how many resources we expect the reference experiment to use, and
   how much we expect to support more dynamic topologies.

** 3) Have a GUI menu for choosing different network impairments setup with
   netem. These effects would be easily visible in the active and passive
   measurements collected by GEMINI.

* Improve unique measurement collection from the experiment.  Show how the
  application (i.e., GridFTP) can push measurement metadata/data to a MS and
  make them visible.