tom
--------
Tom,
Neat idea. I am definitely interested in participating. We would love
to be able to use something like Access for large-scale testing of our
mobile-agents infrastructure. There are a few other projects here
that would also probably interested.
Indeed, we are building a smaller-scale clusters for a similar purpose; one
consists of linux boxes volunteered by sites around the world that are
interested in a cooperative platform for mobile-agents research
<http://www.cs.dartmouth.edu/~agent/network/>; the other will be a similar
DARPA-funded cluster for private use by researchers in the DARPA CoABS
project. Both are coordinated by my group here at Dartmouth; neither is
as big or as sophisticated as Access. I can attest to the difficulty of
convincing people to sign up.
We've encountered two big security-related problems: firewalls and
domain-name-based authentication. Presumably Access, with a dedicated
network connection to each site, would live outside of any university
firewall, so that should be no problem. But would you allocate IP
addresses from the same domain as the rest of the site? We're concerned
about people running software on .dartmouth.edu machines, and thence being
able to access services that are limited to users coming from
.dartmouth.edu hosts. Perhaps one approach would be to put all of Access
into its own domain, with subdomains for each site: .dartmouth.access.org,
.washington.access.org, etc.
I'm surprised you did not mention any relationship with Internet2.
Intentional?
dave kotz
---------
Hi Tom,
I am interested in participating. Thanks for the invitation.
Do you know what resources Univ. of Wisconsin might receive
from the project? Would it just be the rack of PCs, or
would there be funding for people as well?
Also, how would decisions on Access software and its development
be made?
Pei
--------
Hi Tom,
It is an interesting proposal and I'd be interested in
working you (and presumably lots of others) on that. I gather
from your note that you're looking for some sort of initial
indiacation of interest (?).
FYI, here are a few off-the-top-of-my-head comments:
- the proposal is focussing on end systems (fine) but a number
of the research problems mentioned (e.g., RSVP/diffserv,
measurement) have obvious router components.
- Also, some forms of such research (e.g., trying out a diffserv approach,
or instrumenting a router [even a locally owned one] can "break"
the infrastructure. The issue of "how is this different from CAIRN"
will obviously be a big question with the agencies.
- The management of the infrastructure strikes me as a lot
more complicated than discussed at the end, but probably you have
better experience than I (my comments are based on participating in
DARTnet and seeing how hard ISI had to work on maintaining the
infrastructure.
Jim
-----------
I'm buried-as-usual and have only skimmed the first part of the
proposal. So far, I have a question and a comment.
Question: how does this relate to the various Internet measurement
infrastructure projects already underway? (The ones that come to
mind are NIMI, IPMA, Felix, and Surveyor.)
And the comment:
> This dwarfs the software effort; for example, it took Vern Paxson
> two years to set up a simple multi-site Internet measurement experiment
> as a one-shot event.
This really isn't right. It took a few months to set up the experiment;
a year to do preliminary analysis of the data and figure out what I wanted
to do differently the second time around; and a few more months to take the
second batch of data. Managing the experiment manually certainly was a
pain, and that's what's lead to NIMI, but the *real* pain was the data
analysis, and nothing in terms of infrastructure is going to help with that.
Vern
--------
Interesting project. I will circulate it to some people here and see
if there is interest (I avoid thinking any higher than layer 4....).
But here is something to consiter:
1) Some experiments (such as network measurment, or an
authentication testbed) generally require root or at least
privledges that might be used to compromize other users on the same
system and possibly other systems (e.g. packet sniffing). But for
the infrastructure to be effective at supporting this sort of
experiment, the experimenter needs to be able to "globally" invoke
these privledges.
2) The site administrators will want to know/veto who/what privledges
are granted. (This applies to other resoruces, such as disk space,
as well.)
The design of the compromize between these positions may have a large
affect on it's utility for doing anything other than being a pure
cycle server.
--MM-- (Matt Mathis)
----------
Tom,
I am very interested in supporting your proposal. I will forward
a copy of your email to the other PIs on our grant.
Also, you should add Daniel Zappala (zappala@cs.uoregon.edu)
to your mailing list. He is our newest faculty member (networking,
student of Deborah Estrin at USC).
Thanks, Ginnie
------------
Hi Tom,
I just got back from a trip.
Yes I would be interested in having a testbed of this sort.
for the kinds of project I have in mind, and also many of the examples you
listed, I'd like to see all sites connected by the Internet, not some special
infratstructure controlled by AUP's.
Lixia
------------
This was true of DARTnet, but CAIRN has a production-side, i.e.,
a time when it's supposed to be "up". It is fine for validating
mbone and teleconferencing apps; that was its claim-to-fame
What it lacks is shared access to end hosts; it's only about
interior routers. That's your strong point. It might be useful
to clarify that here.
As to areas, you list a broad range of things ranging from applications
to protocols. The main problem is that whatever is changeable is
also unstable, from an upper-layer perspective. It might be better
to clarify there as well that this is not about protocols (or at least
not about network protocols, e.g., routing, queuing, etc), but
rather about end-host issues.
I.e., it's CAIRN for end-hosts.
As to lending my name, I'd be glad to.
Let me know when it's time to contribute further.
Thanks,
Joe Touch