|
Most any legitimate research/experimental use is allowed, including use by
|
|
This document summarizes the administrative policies that relate to the
|
|
companies. Of course, when demand exceeds supply we will have to assign
|
|
operation of the Utah Emulab network testbed (“Emulab”) by the Flux
|
|
priorities to projects, but the hardware base will be expanding. Due to
|
|
Research Group and its members who operate Emulab (“Emulab staff”).
|
|
limited resources and other issues, we currently allow only research use of
|
|
For a summary of who may use Emulab and what it may be used for, see the
|
|
the wide-area nodes; educational and development use are not permitted.
|
|
[Acceptable Use Policy](Acceptable use policy).
|
|
|
|
|
|
### Allocation Priority
|
|
## Resource Allocation Priority
|
|
|
|
|
|
When the testbed become oversubscribed we will be allocating its resources
|
|
The Emulab staff encourage users to plan ahead with respect to their
|
|
based on some function-- currently vague but in roughly this order-- of
|
|
experimentation needs; use Emulab's reservation system to schedule their
|
|
perceived research value and broader impact, the testbed's uniqueness as a
|
|
activities, especially those that require large numbers of nodes; and to
|
|
suitable platform for the research, novelty as a testbed application,
|
|
request only the resources that they need, only for as long as they need them.
|
|
resources required (typically: number of nodes), experimenters'
|
|
|
|
contribution to testbed software development, experimenters' lack of access
|
|
|
|
to other appropriate facilities, sponsorship by our primary sponsors
|
|
|
|
(currently NSF and Cisco), educational value, affiliation with an academic
|
|
|
|
institution, whether the project is funded/peer-reviewed, and for
|
|
|
|
commercial users, their willingness to help defray costs, i.e., pay.
|
|
|
|
|
|
|
|
Many development-oriented commercial experiments and evaluations will be
|
|
Even if everyone follows these guidelines, there are times when the demand for
|
|
allowed, but with lower priority.
|
|
resources exceeds the supply, and Emulab staff are required to exercise
|
|
|
|
judgment in the current and future allocation of resources to users. In
|
|
|
|
general, priority is given to users and experiments that:
|
|
|
|
|
|
### Reporting
|
|
* have communicated a specific and obtainable deadline to Emulab staff,
|
|
|
|
e.g., a conference paper submission deadline;
|
|
|
|
* have communicated and adequately justified a need for specific testbed
|
|
|
|
resources to Emulab staff, e.g., “I need this many nodes of type X
|
|
|
|
for this long because...”;
|
|
|
|
* have a demonstrated history of effectively using the resources that they
|
|
|
|
have allocated, e.g., by not letting resources sit idle;
|
|
|
|
* are performing experiments as part of preparing a publication that will be
|
|
|
|
peer-reviewed;
|
|
|
|
* are contributing to the advancement or awareness of Emulab itself, e.g., a
|
|
|
|
scheduled tutorial;
|
|
|
|
* have limited resource requirements, i.e., “small requests”;
|
|
|
|
* are associated with an academic institution;
|
|
|
|
* lack access to other suitable facilities for experimentation;
|
|
|
|
* are supported by the sponsors of Emulab itself (currently, NSF).
|
|
|
|
|
|
In order to assess the testbed's impact and report to our sponsors, we
|
|
Emulab staff are eager to help researchers and educators use the resources of
|
|
simply require notice of all publications or patents to which the testbed
|
|
the testbed as effectively as possible. Key to this is communication between
|
|
contributed. Formal acknowledgement in such publications is required as
|
|
Emulab staff and users. If you have specific requirements or questions about
|
|
well, by citing the following paper:
|
|
using Emulab, please send email to Emulab support:
|
|
|
|
[testbed-ops@flux.utah.edu](mailto:testbed-ops@flux.utah.edu).
|
|
|
|
|
|
[An Integrated Experimental Environment for Distributed Systems and Networks](http://www.cs.utah.edu/flux/papers/netbed-osdi02-base.html), by White, Lepreau, Stoller, Ricci, Guruprasad, Newbold, Hibler, Barb, and Joglekar, appeared at [OSDI 2002](http://www.usenix.org/events/osdi02/), December 2002.
|
|
## Acknowledgment
|
|
|
|
|
|
You can use this **[BibTex entry](http://www.cs.utah.edu/flux/papers/netbed-osdi02.bib)** to
|
|
To help assess the testbed's impact and report to sponsors, the Flux Research
|
|
cite Netbed/Emulab. Finally, we will be soliciting feedback and suggestions
|
|
Group requires notice of all publications or patents to which the testbed
|
|
from our users.
|
|
contributed.
|
|
|
|
|
|
### Governance
|
|
Formal acknowledgment in such publications is required as well. Acknowledgment
|
|
|
|
may be given by citing the following paper:
|
|
|
|
|
|
An administrative board, including representatives from our major sponsors,
|
|
> Brian White, Jay Lepreau, Leigh Stoller, Robert Ricci, Shashi Guruprasad, Mac
|
|
will be involved in setting broad policy and have review
|
|
> Newbold, Mike Hibler, Chad Barb, and Abhijeet Joglekar. An Integrated
|
|
authority. Typically, a small executive committee composed of members from
|
|
> Experimental Environment for Distributed Systems and Networks. In
|
|
the University of Utah Flux research group will decide most resource
|
|
> _Proceedings of the 5th Symposium on Operating Systems Design and
|
|
allocation issues.
|
|
> Implementation (OSDI)_, pages 255–270, December 2002.
|
|
|
|
> https://www.usenix.org/legacy/event/osdi02/tech/white.html
|
|
|
|
|
|
A Technical Advisory Board is also being formed, containing distinguished
|
|
The following BibTeX record may be useful to you:
|
|
members of the network and distributed systems research communities.
|
|
|
|
|
|
|
|
### Disclaimer
|
|
```
|
|
|
|
@inproceedings{emulab,
|
|
|
|
author = "Brian White and Jay Lepreau and Leigh Stoller and
|
|
|
|
Robert Ricci and Shashi Guruprasad and Mac Newbold and
|
|
|
|
Mike Hibler and Chad Barb and Abhijeet Joglekar",
|
|
|
|
title = "An Integrated Experimental Environment for Distributed
|
|
|
|
Systems and Networks",
|
|
|
|
booktitle = "Proceedings of the 5th Symposium on Operating Systems Design
|
|
|
|
and Implementation (OSDI)",
|
|
|
|
month = dec,
|
|
|
|
year = 2002,
|
|
|
|
pages = "255--270",
|
|
|
|
url = "https://www.usenix.org/legacy/event/osdi02/tech/white.html"
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
We are providing broad access to the testbed in the hopes that it will be
|
|
## Disclaimer
|
|
useful, but we do so **WITHOUT ANY WARRANTY**; without even the implied
|
|
|
|
|
|
The Flux Research Group provides broad access to Emulab in the hope that it
|
|
|
|
will be useful, but does so **WITHOUT ANY WARRANTY**; without even the implied
|
|
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
**WE DISCLAIM ALL LIABILITY** from errors in results or security breaches
|
|
**THE UNIVERSITY OF UTAH, THE FLUX RESEARCH GROUP, AND ITS MEMBERS DISCLAIM ALL
|
|
resulting from emulab's use. The system has been in production use for over
|
|
LIABILITY** from errors in results or security breaches resulting from Emulab's
|
|
a year, but is constantly undergoing rapid development, so significant
|
|
use. The system has been in production use since 2000, but is constantly
|
|
amounts of code are always new. We make an effort to provide inter-project
|
|
undergoing rapid development, so significant amounts of code are always new.
|
|
security, but users must realize that high security is unlikely in i) such
|
|
Emulab development and operations staff make efforts to provide inter-project
|
|
a new and rapidly evolving system, ii) where users have such complete
|
|
security, but users must realize that perfect security is unlikely (1) in such
|
|
control over hardware and software resources, and iii) in such a public
|
|
a new and rapidly evolving system, (2) where users have such complete control
|
|
facility that will attract attack. |
|
over hardware and software resources, and (3) in such an Internet-accessible,
|
|
|
|
public facility that is subject to continual threats. |