Dr. Kenneth Klingenstein
Director, Computing and Network Services
University of Colorado at Boulder

Email:    Ken.Klingenstein@Colorado.edu

Postal Address:
        Dr. Ken Klingenstein
        Computing and Network Services
        Campus Box 455
        University of Colorado
        Boulder, Colorado 80309

Phone: 303-492-8178
Fax:   303-492-4198
===============================================

Shekel Serving: The Management of QOS in the Community

        "Shekel - an ancient unit of weight used in barter by Phoenicians
and others." - Webster's New World Dictionary

While significant work is being done in the technical community on
implementations of QOS in a networked environment, relatively little work
is being done in implementing the management tools necessary to administer
quality of service.  The general presumption is that money will be the
management tool; users who want a predictable quality of service will pay
money for it.

However, there are many non-monetary economies, particularly in a
"community" setting, in which the allocation of QOS may be determined by
other parameters, such as programmatic or equity concerns.  It is likely
that universities, for example, will want to administer QOS as an
institutional good, allocating service in response to strategic issues,
educational value, and fairness.  Corporations may use money as the vehicle
for internal allocations but want to embrace other factors as well in
assigning QOS.  We designate the units of resource ultimately being
allocated as "shekels", named after the ancient Phoenician units of barter.
Basically, shekels treat QOS as a (relatively) fixed good to be dispensed
efficiently and effectively in a networked community, rather than a
(potentially) unbounded supply to be purchased by end-users.  In the
commercial sector, QOS is assumed to be allocated according to a single
criteria - does the user want to spend the money?  Shekel serving consists
of using multiple different evaluation criteria (including, for example,
internal and external network capacity, institutional allocation policies,
and previous reservations) to arbitrate the granting of QOS to a user
request.

In such settings, the management of QOS will need to factor in several
parameters
        Network constraints - Resource reservation will need to respect
network topology and capabilities.  QOS allocations must insure that
intermediate routers and switches can accommodate the pooled load they may
face.
        Allocation policies - It is likely that programmatic factors such
as equity, institutional priorities, etc. will need to be dynamically
applied to evaluating reservation requests.
        Time- Shekels will be allocated for specific periods of time.
Tools must manage these allocations, permitting users to view schedules and
reserve particular times.  System servers must guarantee that reservations
are met by the network at the required time.
        Authentication and authorization services - Users must present
electronic credentials in order to access shekels, and then draw upon their
authorizations to use them.
        APIs - It is desirable for user applications to have a standard
interface to shekel service elements within the community, in order to
facilitate resource negotiation between the user and the network.
        External gateways - For intercampus traffic, gateway services must
convert the internal shekel mechanisms into a well-defined request for
service for the external network provider.  Once resources are reserved on
the campus, the gateway will negotiate with the external service, and
perhaps the destination host to complete end-end resource negotiation.
        End-end negotiations - It is likely that in many instances users
will want to exchange information with the destination node as part of the
network resource reservation process.

This research proposes to investigate the issues associated with managing
the resource negotiation for QOS in such community sessions and
establishing a standard hierarchical framework for enabling implementation
of specific allocation policies.  There are two major goals of the
research- analysis and tools.


Analysis:

        Identify primary user and server design issues.  What units of
reservation will users want, in dimensions of time, money, and varying
levels and types of QOS?  What units of reservation are tractable on the
server side?  What parameters do servers want to consider in evaluating
requests?  Do these parameters change if the specific definition of QOS
changes?  Are requests for intrasite QOS handled differently than requests
that require an external connection?  Should shekels be defined as an N x M
mapping instead of an N x 1 mapping?  (I.e. should multiple dimensions of
QOS be considered?)
        Identify gateway issues.  What forms of external pricing fit the
university context best? What forms of QOS service will be presented to the
campus?
        Seek guidance and direction from related environments. Other
systems, ranging from time-sharing to airline reservations, all reserve
resources.  What are the similarities and differences in the QOS arena?
        Establish a model for structuring negotiation.  This model will
likely be based on a hierarchical community, with users negotiating with
local servers, and those servers in turn negotiating with regional or
community-wide systems.  At the top of this community, a gateway server
will interface community requests with the external environment.  The model
will identify common infrastructure and reflect the key design
considerations identified above.


Tools:

        Define a protocol between pairwise hosts for shekel negotiation.
The protocol will include mutual authentication and verification of
authorization, be independent of the particular QOS being administered and
access underlying rule databases.  The protocol will apply between the
client and the primary shekel server, and also to negotiations among shekel
servers.

        Create an API that will allow applications on a client to interact
with the negotiation processes.  After authentication, users will use
client programs to select services and authorize the use of shekels.

        Implement prototype pieces of software that establishes a test of
concept and viability of shekel service.  This would include both clients
and servers, as well as tools for managing the databases that the system
will need to operate.  The prototype may serve as the basis for future
software systems in this area, and provide a means for other
experimentation, such as investigation into the interactions between
allocation policies and social behavior, etc.


The research area appears important.  One of the unfortunate tendencies of
past Internet development has been to not consider management tools before
deployment.  Those tools should be designed to reflect the broad range of
considerations that will go into QOS management in the institutional
setting.  Those tools must be based on open protocols and interoperability
and work in a hierarchical environment.  The sooner that analytic
frameworks and fundamental tools are available, the sooner that the
theoretical capabilities of the NGI can be meaningfully deployed.