Comments received from community on 2/25 of DRAFT GENI Control Framework Requirements document

[Harry Mussman]

GENI Control Framework WG Members and GENI Developers,


An effort is underway to define and document a first view of the GENI
Control Framework Requirements.  

A first DRAFT (v01.3) has been completed, and can be found at
http://groups.geni.net/geni/wiki/GeniControlFrameworkRequirements 

The abstract is:
GENI Control Framework Requirements
GENI-SE-CH-RQ-01.3
This document defines the GENI control framework subsystem, and then
specifies its requirements.  It is a DRAFT, to be used for discussion in the
GENI Facility Control Framework working group.  Once approved, it can be
used as a guide to judge the completeness of prototype control framework
designs, and as a guide to their continued evolution.  


As previously announced, we will do an interactive review via a conference
call:

        Wednesday, Feb 25, 2009
        1pm - (absolutely no later than) 3pm EST.

        Bridge:  866-453-5550   651 3886#

To facilitate this review, a summary of comments received from the community
is attached below.

SORRY - I should have forwarded these to the mailing list as they were
received, or had them directed to the mailing list.


We look forward to a review, and then a lively discussion of the DRAFT
document.

Please feel free to contact me with questions about the document, or the
review.

Thanks,

Harry

Harry E. Mussman
Sr. Systems Engineer - GENI Project Office
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[phone] - Office
[phone] - Mobile
[phone] - Fax
hmussman@...
www.bbn.com



General comments on purpose and nature of the document:


Received from Jeff Chase on 2/18/09:
My overall impression is that it is a valiant effort to abstract from the
various control frameworks, and the cost of doing that is that it is harder
to understand than it could be if we were willing to be more aggressive
about binding some architectural choices.  Not that there's anything wrong
with that....I understand the purpose of the document.  With that said, I
didn't find anything really offensive to me, but many places where the
intended meaning could be subject to interpretation (Rorschach test) or
might unintentionally allow or exclude certain possibilities.


Received from Ted Faber on 2/24/09:
I have my usual detailed comments on the draft, which we can get into on the
phone or after the conference call, but rather than dive into the minutae
first, I wanted to send my comments on the document as a whole.

There are two major problems with this document, as I see it.  First it's
very tied to a particular implementation both in terms of the thinking
behind it and in the specific expressions of the requirements.
Secondly it doesn't differentiate between functional requirements and
implementation requirements.

The result is a document that gives me a recipe that defines birthday cake
rather than telling me that  a birthday cake is a sweet dessert with candles
on top.  The recipe certainly gets me a birthday cake, but there's a certain
lack of innovation implied.  The analogy is an overstatement for effect, but
this document is more about how to do things than what needs to be done.

The first problem prevents the document from becoming a meeting point where
various control framework designers can agree on the key functional
requirements that any control framework must have because requirements are
expressed in the language of a particular implementation.  For example,
there are several places where a database with specific record contents is
tied to requirements (e.g. Section
5.5.3) and that seem to imply that full contents of that database are
accessible (e.g., Section 5.5.1).  To be clear, the problem is that the
requirements fairly tightly constrain the data a framework might need to
keep in order to carry out this function and that the framework must export
it, not that database software is implied - how not what.

To my mind, in reading this document I frequently had two questions:
"does this requirement need to be there functionally?" and if it does "how
tightly does its implementation need to be constrained?"  In my opinion this
document concentrates on the implementation questions much more than the
functional questions.  In any case, we should recognize that both questions
are important.

The second objection speaks more directly to this issue of the level of
requirements.  Functional requirements help developers find the key
abstractions and operations on which control frameworks have to agree.
This document focuses more on explaining how a particular implementation
would approach the operation - what information it would use and where it
would be stored - rather than specifying the details operationally and
letting the developers build whatever works with their system.

For example, the document specifies principal records and their contents,
but a requirement like "it must be possible to tie principals to a
responsible real world entity and authenticate the principal" comes closer
to the ideas on which many implementations can agree.  Even that phraseology
points to the deeper and more important issues on which control frameworks
may differ: what constitutes a principal in the framework?, and to what
extent is that principal connected to a person or collective (university,
department, research group, ...) in the world outside the GENI control
framework?  Following that chain of questions upward to the concepts that
cannot be deleted from any implementation seems more fruitful than following
the questions down into how they're included in a specific implementation.

I can't see the control frameworks groups designing or coding to the
requirements in this document in order to interoperate.  I think many of the
specific structures in these requirements will be missing from some of the
designs. Furthermore, higher level guidance (what does it mean to identify a
principal) is missing.

I'd much prefer a concerted effort to make this a functional requirements
document.  It's a pretty significant challenge to craft requirements for
only the essential elements and functions of a system.
The urge to generate requirements from an example is very strong; I've
certainly done it.  But a document that does capture what a framework must
do to be useful rather than how one might do it is a real asset to the
control framework developers and the program as a whole.



Specific comments on certain sections:



Received from Aaron Falk on 1/13/09:
I'm revising the System Requirements doc and found this very nice text
written by Ted Faber introducing the concept of a slice.  You might want to
include it in your control framework docs.

> A slice is a collection of resources that have been allocated and
> configured together for the purpose of experimentation.
> It can contain resources from diverse locations and administrative
> controls.  Slices provide GENI's notion of an experimenter's
> collection of resources and are the fundamental entity that
> researchers use to define their experiments.
> Researchers will remotely discover, reserve, configure, program debug,
> operate, manage, and teardown distributed systems established across
> parts of the GENI suite by manipulating slices and the resources
> connected to them.

Received from Justin Cappos on 2/12/09:
5.2.2 b)  It shall be possible to identify a principal who is acting within
the GENI suite.

Who can identify a principal acting within the GENI suite?   Any user
on the internet, any GENI user, the administrators of GENI, the leader of
the federation at which the user joined, etc.

This has strong implications for issue c.

5.2.5    From my conversations with Million node GENI users, opt-in
users will want an interface where they can control how their
resources are used.   I think this is very similar to an organization
who donates resources wanting to enforce a policy (like no porn) so a
similar mechanism should suffice.

5.5.7    I think disconnected operation is very important and must be
supported (as a maintainer of several long term services).

5.8    It would probably be a good idea to make sure operations can't
be skipped or performed out of order except in circumstances where the
user expressly allows it.   For example, suppose that I'm logging
information to a file and I want to archive the file periodically.
That might consist of the steps: move the log file to a backup, signal the
server to close the file descriptor and create a new log file,
compress the backup, and erase the backup log file.   It's clear that
if I skip some step(s) or perform them out of order, the researcher will not
get the result they intend.



Received from Larry Lannom on 2/15/09:
A couple of random comments:

5.2.1 - "A GENI principal is a person acting from a server..." what does
acting from a server mean?

5.4.3 - A slice is registered jointly by a GENI admin and someone from a
research org - so who owns it and what does it mean to own it? I found
myself asking this sort of question a number of times - some sort of
ownership/management diagram might be useful.

5.6.1 d) - similar to above - is control a single thing or do control
privileges vary?

In general - is there one GENI suite or multiple instances of GENI suites? I
understand that the intent is to have multiple interoperable suites, but I
wasn't clear if GENI always meant the organizational entity or the interop
spec.



Received from Jeff Chase on 2/17/09:
Two quick questions/proposals on terminology.  These might be comments for
the CF requirements doc.  But they have also come up in drafting spiral 2
proposals.

Both deal with what has been called "experimenter tools" or "experiment
control tools" in various GENI docs.

(1) There is a useful distinction between code that runs inside a slice
vs. code that runs outside a slice.   Code that runs inside a slice
falls under the category of "component programming" and the
programmability requirement (S 5.5.5 in the CF requirements doc).   The
question is: do we have an accepted name for toolkits or other off-the-shelf
software artifacts whose purpose is to support
easy/flexible programming of various components?   An example from the
literature might be Click or Ilia's SILO framework.    The specific
question that drove this concerns whether it is right to refer to SILO as
"experimenter tools".  I would argue that we should not consider these as
"experimenter tools" so as not to blur this useful distinction.

(2) I think we have reached some kind of consensus (within services-wg and I
think in my discussions with GPO folks) for a first-class entity/actor that
controls and monitors a slice.  I think Gush is perhaps the best-known
example.  The defining element that makes such an entity "first-class" is
that it is persistent so that other actors in the control framework, or
slivers in its slice, can send unsolicited
messages/notifications to it.   And it may respond by taking autonomous
actions to control the slice on behalf of an experimenter.  Previously we
haven't had a name for this entity.  I propose that it be called
"slice controller".   (Note: in Orca-world we presume/require/support
such a beast: we have called it "service manager" since the SHARP days in
2003, and then started talking about "guest controller" plugin to the SM
that implements a control policy.)  The specific question that drove this is
whether we will be understood by GPO if we say "slice controller".  I think
David Irwin had told me he though Harry's preferred term was "experiment
controller", but I'm not seeing any "controller" term now in the CF req doc.






Received from Jeff Chase on 2/18/09:
- Can a ticket be many slivers?
- Does the Clearinghouse register every component by name?

(Orca broker may know about interchangeable components within an aggregate
only by type, attributes, and unit count, e.g., for edge
clusters.)

This comes up again in 5.5.1.  Is an aggregate manager mandated to expose
everything, or can it withhold information about its internal structure?

Does the CF make any assumptions about the experiment control tools?  
(e.g., per my question about "slice controller" yesterday).  In general,
where does CF and slice support services begin?  (comes up at several
points, including 5.6.2...see more comments below.)

Fig 2-1.  Is there a distinction between administrator and operator?  
never mind, I see it in 5.2.5.

Fig 2-2.  Is "Research Org A" more than an ID provider?

Fig 2-3.  Notion of GENI services and service manager is new.   Your use
of term "service manager" here is one reason we are shifting terminology
within Orca to refer to former "service manager" as "slice controller".  
(per my message yesterday).  The new emphasis on services takes a big step
toward OGSA.

S4, p 11: is software repository part of the clearinghouse?
p12, is the "broker service" in the next bullet list not part of the
clearinghouse?  There seems to be a shift to create some mechanism for
federating aggregates other than a clearinghouse.  I'm curious why.  (cf
5.5.5)

I'm not sure I understand the two bullets about principals on page 12.

In 5.2.2 the emphasis on identity raises eyebrow.    Shib philosophy is
that any kind of service provider does not really care about identity, but
only security attributes associated with the identity and endorsed
by an identity provider.   Actual real identity is just one possible
attribute but is not necessarily required.  Ultimately GENI may require
bindings to identities in the real world, e.g., for legal sanction, and I
would not oppose that, but to mandate it is a significant step.  It also
raises the question about whether levels of indirection are acceptable,
e.g., if Duke says the operation is being done on behalf of a CS faculty
member, but does not say who, and an abuse is committed, is it sufficient to
allow/require the institution to divulge identity only after the fact, e.g.,
after evidence of the abuse has been presented?  
My personal view is: I don't believe that anonymity is required, but I do
think that requiring strong bindings to identity in advance creates an
implementation burden (essentially requires PKI) and administrative burden,
and may be problematic later, and is probably unnecessary.  
Perhaps 5.2.3 (b) is enough to answer this concern.

In my view, where this is going is Shibboleth (or equivalent) with agreement
within GENI about what security attributes must be associated with
GENI-enabled identities as basis for authorization, and with additional
support within GENI for delegations of authority (probably using SAML) and
richer authorization policies.  If so, then the emphasis on identity may be
drifting off the route, e.g., in 5.2.3-5.2.5 it might be sufficient to
delegate many of these issues to shib.

In 5.3.2, do we mandate a standard for these identifiers?  Orca uses RFC
4122 GUIDs.

In 5.4.1 I do not see a need for a subslice.   Our philosophy is to make
slice creation easy enough (unprivileged) that an experimenter can use
multiple slices if convenient...and in fact we regularly do this in our
research on experiment automation (with Shivnath Babu).  But for this reason
I question the strong requirements for slice registration in
5.4.3 a, c.   [5.4.3 b seems to conflict with c]  This seems to be
derived from PlanetLab, where a slice has to be specifically approved by
humans, instead of just making sure it is created by a user who is
authorized and ultimately accountable.

I don't interpret anything in 5.4.3 as requiring a central point in GENI
with knowledge of all slices.  I hope you not intend to mandate such a
central registry.  [5.4.3 a could be construed as implying it.]

Is 5.5.2 intended to mandate that all components are sliverable?  I think
that would be a mistake.

I'm unclear on the distinction between 5.5.3 e and f.

In 5.5.4, the word "negotiate" could be useful somewhere?

Does 5.5.4 d and f require mutual consent?

In 5.5.6, WSRF is relevant here.  I don't see a problem.  But we like to
allow for notifications about changes to component status, which is one
reason why I think the notion of "slice controller" as first class entity is
important.  Similarly in 5.5.7 "issue", if you have a slice controller and
it is disconnected, then that is OK, but the resources might go away as the
leases expire.  That is why resource contracts must have an end time!  If
you have such an end time, then disconnected is OK.

Terminological point: I think it is wise to be careful about the term
"reserve", which can mean "starts at a specific time in the future" or
"assures me a resource entitlement".   Use is ambiguous in 5.5.7.   This
is one reason I like the term "lease" (plus one syllable).   A lease
could be best-effort or an assured entitlement, and it can be arranged an
advance or can be on-demand.  A "reservation" means different things to
different people, but whatever it means, it is a kind of lease (or at least
a ticket, i.e., a promise to enter into a lease).

I wasn't sure exactly what 5.5.8 and 5.5.9 were really saying.



_______________________________________________
control-wg mailing list
control-wg@...
http://lists.geni.net/mailman/listinfo/control-wg