1 | === Phoebus/XSP Reference Experiment for GEMINI I&M ===
|
---|
2 |
|
---|
3 | GEMINI needs a reference "use case" to demonstrate common features of the I&M
|
---|
4 | architecture when approached from an experimenter's perspective. Additionally,
|
---|
5 | the experimental environment should be flexible enough to allow its use in
|
---|
6 | future GEMINI tutorials.
|
---|
7 |
|
---|
8 | ==== Component Overview ====
|
---|
9 |
|
---|
10 | Phoebus is a performance-enhancing software router platform built on the
|
---|
11 | eXtensible Session Protocol (XSP) framework. Nodes running Phoebus software are
|
---|
12 | called "Phoebus Gateways", or PGs. Applications can make use of the PG nodes
|
---|
13 | through the XSP client libraries, which includes a transparent wrapper. On
|
---|
14 | Linux systems, the wrapper intercepts standard socket() calls and can redirect
|
---|
15 | TCP flows over one or more PGs. This path is known as an "XSP PATH", and can be
|
---|
16 | configured in the local shell environment or programmatically via the XSP client
|
---|
17 | API. The configuration of a PG also allows for a number of static routes (i.e.,
|
---|
18 | XSP "next-hops") to be defined for specified IP prefixes.
|
---|
19 |
|
---|
20 | The typical use case for Phoebus is that of bulk data movement over high-latency
|
---|
21 | WAN paths, often with a less than ideal "edge" network on either side of the WAN
|
---|
22 | link. We can achieve significant performance improvements for applications that
|
---|
23 | use Phoebus compared to the direct, or pure end-to-end, case. Typical testing
|
---|
24 | applications include network benchmarks such as iperf, netperf and file transfer
|
---|
25 | tools such as ftp/sftp, GridFTP, etc. For GridFTP in particular, we have
|
---|
26 | developed custom drivers for Phoebus and XSP within the Globus framework on
|
---|
27 | which GridFTP is built. The driver allows GridFTP to use Phoebus directly with
|
---|
28 | command line options, and the XSP driver includes instrumentation of the
|
---|
29 | application that can be exported to a GEMINI MS.
|
---|
30 |
|
---|
31 | ==== Typical Experiment Setup ====
|
---|
32 |
|
---|
33 | The most basic setup for evaluating Phoebus consistes of 3 nodes in a linear
|
---|
34 | topology: two clients separated by a PG node. The clients can either
|
---|
35 | communicate directly across the PG node (using standard Linux routing) or can
|
---|
36 | redirect flows over the PG service itself using the methods listed above.
|
---|
37 | Without any unique network characteristics on the two links, the performance in
|
---|
38 | either case will be virtually the same. To make things more interesting, the
|
---|
39 | netem "network emulation" module (configured via the traffic control, 'tc', tool
|
---|
40 | in Linux) can be used to add various amounts of latency and loss to the node
|
---|
41 | interfaces. Adding these artificial impairments allows us to evaluate the
|
---|
42 | benefits of the Phoebus approach in mitigating the effects of TCP behavior over
|
---|
43 | less than ideal network conditions. The existing experiment is detailed here:
|
---|
44 |
|
---|
45 | https://docs.google.com/document/d/17JsebJ0vi8zSH-s__o7U_Xii276lG6FqpB_QWHKSFYo/edit?pli=1
|
---|
46 |
|
---|
47 |
|
---|
48 | ==== Future Directions ====
|
---|
49 |
|
---|
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.
|
---|
54 |
|
---|
55 | * Increase the flexibility of the experiment.
|
---|
56 |
|
---|
57 | ** 1) Let users easily choose between "direct" and "Phoebus" transfer cases.
|
---|
58 |
|
---|
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.
|
---|
64 |
|
---|
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.
|
---|
68 |
|
---|
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.
|
---|