Guide to Writing Applications for Internet2

As we talk about writing applications for Internet2, it may be helpful to explicitly think about the minimum set of requirements any prospective Internet2 application author needs to keep in mind.

1. One end of the application needs to be homed at WPI.

It may sound self-evident, and we may very well be stating the obvious, but one end of the application needs to be at WPI. Put another way, the system on one end or the other of the network connection needs to be here at WPI, in 130.215.*.* address space.. If you work with a community network partner this may be an issue for you, since in those cases being "closely affiliated" with WPI isn't "close enough" when it comes to Internet2 – you need to actually be connected from WPI's network.

2. The other end of the application needs to be at a site with live high performance connectivity.

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 Internet2/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 Internet2 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 Internet2/Abilene. Again, those sites won't work, at least not yet. 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 Internet2 connectivity – but please remember that Internet2 is evolving and developing, and institutional eligibility for connection to Internet2 or other high performance networks isn't something we control.

If you would like assistance to determine if a particular application would take advantage of our Internet2 network capability, feel free to contact Sean O'Connor (, x5115).

3. Your application should (ideally) have characteristics that take advantage of Internet2's special capabilities.

An application engineered for Internet2 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 Internet2's big pipes. Put another way, a good Internet2 application is usually an application that doesn't work well over the commodity/commercial Internet.

the amount of time it takes a packet to travel from source to destination. Together, latency and bandwidth define the speed and capacity of a network. In other words, it's the lag time or response time you experience.
the variation in the amount of latency among packets being received. In other words, sometimes on the commodity Internet, response time if faster than other times. This variation is the called jitter.
the amount of data that can be transmitted in a fixed amount of time. For networks, bandwidth is usually expressed in bits per second (bps).
a piece of a message transmitted over a network. Large chunks of information are broken up into packets before they are sent across the Internet.

For more information, consult the Internet2 glossary.

4. Your application needs to be able to differentiate between high performance Internet connections and commodity Internet connections.

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 Internet2/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.

5. Applications should be ongoing (or time critical).

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 Internet2."

6. Applications can't be for commercial purposes, nor can they involve classified data.

The WPI Acceptable Use Policy prohibits commercial use of university resources, so the fact that your application will be running to or from WPI means that commercial projects are unacceptable. Similarly, Internet2 isn't certified for use for classified research purposes, so don't plan to use it to move classified data, even though Internet2 has routes to places well known for doing classified research (such as Lawrence Livermore Lab, Los Alamos, Sandia, Kirtland Air Force Base, etc.).

What Sorts of Applications Will Work Well via Internet2?

Here are some examples:

For further information, contact

Adapted for WPI from Writing Applications for Internet2?, written by Joe St. Sauver and generously donated by the University of Oregon. Definitions adapted from the Internet2 Web site Glossary.


Maintained by itweb
Last modified: Jan 31, 2014, 19:18 EST
[WPI] [IT] [Back] [Top]