|
|
By Joe St Sauver (joe@oregon.uoregon.edu)
As we talk with users about writing applications for Internet2, it's clear that it may be helpful to explicitly think about the minimum set of requirements any prospective I2 application author needs to keep in mind.
It may sound self-evident, and we may very well be stating the obvious, but one end of the application needs to be at the UO. Put another way, the system on one end or the other of the network connection needs to be here at the UO, in 128.223.*.* address space. If you work with a community network partner (such as one of our Eugene/Springfield K12 Lane Education Network community networking partners) this may be an issue for you, since in those cases being "closely affiliated" with the UO isn't "close enough" when it comes to I2--you need to actually be connected from the UO's network.
Another seeming self-evident requirement which we nonetheless must mention: the other end of the application must be at a site that has high performance connectivity with I2/Abilene (i.e., sites connected via Abilene itself, the vBNS, Canarie, ESNet, NREN, DREN, etc.).
Why is this an issue? Well, you may run into sites that are I2 members but are still working on getting physical high performance network connectivity deployed; obviously they won't work, at least not yet. You will also run into other sites on foreign high-performance networks, but they may not yet peer with I2/Abilene. Again, those sites won't work, at least not yet. The relevant set of institutions which you can work with today are those listed at http://www.ogig.net/routes.html (note that this is a small set of institutions relative to the size of the Internet as a whole). It can be frustrating to have data from a telescope in Hawaii, for example, that you'd like to retrieve via Internet2, only to find that the Hawaiian instrument doesn't have I2 connectivity-- but please remember that I2 is evolving and developing, and institutional eligibility for connection to I2 or other high performance networks isn't something we control.
An application engineered for I2 should (ideally) have characteristics which take advantage of that network's special capabilities, i.e., your application should require high bandwidth, low latency, low jitter, or be otherwise particularly well suited to I2's big pipes. Put another way, a good I2 application is usually an application that doesn't work well over the commodity/commercial Internet.
Implicitly or explicitly, you and your application need to be able to differentiate between high performance network-connected partners and commodity Internet network-connected partners. Consider, for example, a web server that can deliver high bit rate video on demand. Our I2/Abilene connection is designed for, and has capacity available to service, those high bit rate streams. But what if a person comes in via a commodity Internet connection and requests those high bit rate streams? Our commodity network capacity can't satisfy that demand, nor will a user trying to view that video at the other end of a commodity Internet connection get the high bit rate multimedia experience you probably want them to have. Thus, your application needs to be aware of where its peers are coming from, either because it explicitly selects the remote peers it works with itself (e.g., a web crawling spider that crawls only I2 attached web sites), or because it controls which sites can access it via a semiautomatic mechanism (such as a generated .htaccess file which "knows" what network prefixes are via I2), or via a manual mechanism (such as a person-to-person agreement to exchange data, reached by you with a remote collaborator at an I2 site).
Applications particularly well suited to high performance networking connections should be ongoing (rather than being one-time events), or they should be time critical (i.e., you need access to the data ASAP).
Put another way, if you have a one-time, non-time critical need to move data between two sites, it's hard to beat the throughput and cost efficiency of a box full of DLT tapes sent overnight via Federal Express. On the other hand, if you're moving data every day, or the data needs to be available virtually immediately, then think "let's try delivering this data via I2."
The UO Acceptable Use Policy prohibits commercial use of university resources, so the fact that your application will be running to or from the UO means that commercial projects are unacceptable. Similarly, I2 isn't certified for use for classified research purposes, so don't plan to use it to move classified data, even though I2 has routes to places well known for doing classified research (such as Lawrence Livermore Lab, Los Alamos, Sandia, Kirtland Air Force Base, etc.).
Here are some examples: