clearinghouses (or not)

[Larry Peterson]

We're saying the same thing, I think. The authority approves
the account, so to speak, but the registry interface mediates
this transaction.

Larry

On Thu, Apr 16, 2009 at 7:49 PM, Robert P Ricci <ricci@...> wrote:

> Thus spake Larry Peterson on Thu, Apr 16, 2009 at 07:17:59PM -0400:
>> 1) A place for a user to "log in" -- that's what we have
>>     registries for. You just need to get your university's
>>     authority (PI in PlanetLab-speak) to vouch for you.
>>     Then you acquire the credential(s) you need and
>>     you're off and running.
>
> Yeah, I'd like to push back on this one too - while we use the
> clearinghouse as a trust anchor, it's not the place where a user's
> account "exists". The user's account "exists" at an authority (in our
> case a slice authority).
>
> --
> /-----------------------------------------------------------
> | Robert P Ricci <ricci@...> | <ricci@...>
> | Research Associate, University of Utah Flux Group
> | www.flux.utah.edu | www.emulab.net
> \-----------------------------------------------------------
>

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

[Robert P Ricci]

Thus spake Aaron Falk on Thu, Apr 16, 2009 at 06:25:20PM -0400:
> >  (5) Help resource providers and resource users find each other, by
> >      hosting registries of AMs and users (for example, our simple
> >      resource discovery has the client contact the CH to get a list of
> >      AMs)
> >  (6) Act as a trust anchor - in the federation we have running, every
> >      federate establishes direct trust with only one party, the CH,
> >      which then distributes signing certs, CRLs, etc. to all members of
> >      the federation
 
>     1. User log-in.  A place for a user to create an account; it needs
>     to be capable of validating there is an organization accountable for
>     their actions.  It's not clear whether this validation is included
>     in the credential manager you mentioned.

Perhaps it's not a perfect paraphrase, but what I got out of Chip's
talk was something like "bringing buyers and sellers together". A global
login is one way of doing that, but not the only way. I think #5 are #6
another good way to accomplish that goal.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[David Irwin-3]

Hi Aaron,

I basically agree with your points (specific comments below), with
respect to the functions a Clearinghouse in Orca should support.  In
my view, your first and third points were mentioned in the previous
thread.

>    1. User log-in.  A place for a user to create an account; it needs
>    to be capable of validating there is an organization accountable for
>    their actions.  It's not clear whether this validation is included
>    in the credential manager you mentioned.

My interpretation was that this is effectively credentials management
in the previous thread.  User log-in is probably the wrong word (since
it implies some form of a user-interface/prompt).  But, yes, a user
establishes itself with a Clearinghouse in some (out-of-band) way
(e.g., exchange of public keys), which then authorizes resource use by
allocating signed tickets.  I think a user's account (the log of its
actions across all GENI aggregates) should reside at a Clearinghouse,
to reduce the burden of gathering these logs from many different
aggregates (which may not always be trusted to keep them).  I also
don't think it is right to have users create accounts at many
different aggregate managers; an account at a trusted Clearinghouse
should be enough.

>    2. Transaction Logging.  A reliable record of all resources a user
>    consumed.  Needed to determine accountability if something bad happens.

Yes, so the Clearinghouse, User, and AM keep records of all tickets
they receive/issue.  You can then do ticket audits to determine if
someone violated the terms they set.   I don't believe this was
mentioned in the 6 functions outlined by Larry and augmented by Rob.

I'm not sure if transaction logging implies a "global red button"
since the CH is just a middleman, it doesn't have its fingers on the
resources----a "global red button" is difficult in a widely federated
system.  But what you can do is log transactions in places and audit
those logs over intervals of your choosing.

>    3. An ability to enforce global policies.

I assume you include resource allocation decisions as part of the
global policy.  I think this is essentially the Resource Manager
function above.  I certainly view it as important for the
Clearinghouse to be able to support global policies, even if the
aggregates ultimately own and operate the resources.  I don't view it
as unreasonable for aggregates to delegate resources periodically to
"global" entities like GENI, which then allocate them.

If an aggregate wants to be part of a system that supports coordinated
allocation of resources across aggregates it **must** give up some
control over its allocation over some periods of time.  Of course, it
is always up to the aggregate that owns the resources to choose when
to delegate this control, how much power to delegate, and for how
long.

-David

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

[Larry Peterson]

Here's what I conclude from this discussion. There are several
distinct functions. We've done a decent job of identifying them.
A Clearinghouse isn't one of them -- it's a bundling strategy.
There are many possible ways to bundle, but they all seem to
be pragmatic/implementation driven. I don't think I've seen an
"architectural argument" favoring one over another.

Larry

On Thu, Apr 16, 2009 at 9:23 PM, David Irwin <irwin@...> wrote:

> Hi Aaron,
>
> I basically agree with your points (specific comments below), with
> respect to the functions a Clearinghouse in Orca should support.  In
> my view, your first and third points were mentioned in the previous
> thread.
>
>>    1. User log-in.  A place for a user to create an account; it needs
>>    to be capable of validating there is an organization accountable for
>>    their actions.  It's not clear whether this validation is included
>>    in the credential manager you mentioned.
>
> My interpretation was that this is effectively credentials management
> in the previous thread.  User log-in is probably the wrong word (since
> it implies some form of a user-interface/prompt).  But, yes, a user
> establishes itself with a Clearinghouse in some (out-of-band) way
> (e.g., exchange of public keys), which then authorizes resource use by
> allocating signed tickets.  I think a user's account (the log of its
> actions across all GENI aggregates) should reside at a Clearinghouse,
> to reduce the burden of gathering these logs from many different
> aggregates (which may not always be trusted to keep them).  I also
> don't think it is right to have users create accounts at many
> different aggregate managers; an account at a trusted Clearinghouse
> should be enough.
>
>>    2. Transaction Logging.  A reliable record of all resources a user
>>    consumed.  Needed to determine accountability if something bad happens.
>
> Yes, so the Clearinghouse, User, and AM keep records of all tickets
> they receive/issue.  You can then do ticket audits to determine if
> someone violated the terms they set.   I don't believe this was
> mentioned in the 6 functions outlined by Larry and augmented by Rob.
>
> I'm not sure if transaction logging implies a "global red button"
> since the CH is just a middleman, it doesn't have its fingers on the
> resources----a "global red button" is difficult in a widely federated
> system.  But what you can do is log transactions in places and audit
> those logs over intervals of your choosing.
>
>>    3. An ability to enforce global policies.
>
> I assume you include resource allocation decisions as part of the
> global policy.  I think this is essentially the Resource Manager
> function above.  I certainly view it as important for the
> Clearinghouse to be able to support global policies, even if the
> aggregates ultimately own and operate the resources.  I don't view it
> as unreasonable for aggregates to delegate resources periodically to
> "global" entities like GENI, which then allocate them.
>
> If an aggregate wants to be part of a system that supports coordinated
> allocation of resources across aggregates it **must** give up some
> control over its allocation over some periods of time.  Of course, it
> is always up to the aggregate that owns the resources to choose when
> to delegate this control, how much power to delegate, and for how
> long.
>
> -David
>

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

[David Irwin-3]

> Here's what I conclude from this discussion. There are several
> distinct functions. We've done a decent job of identifying them.
> A Clearinghouse isn't one of them -- it's a bundling strategy.
> There are many possible ways to bundle, but they all seem to
> be pragmatic/implementation driven. I don't think I've seen an
> "architectural argument" favoring one over another.

I agree that there are several distinct functions (sometimes its
difficult to keep track of all of them).  However, the architectural
point I take away is don't design (or implement) control frameworks in
a way that makes it difficult to easily conform to any one of the
"bundling" alternatives.

This is a point that underlies Orca's approach----we put nearly all of
the discussed functionality (in some form) in our Clearinghouse
because we can always have multiple Clearinghouses or combine AMs with
their own Clearinghouse (so the AM takes on its functions) in
different ways to effectively produce a different "bundle" of
functions.  Taking the opposite approach---by putting few functions in
a Clearinghouse initially---may make composing/bundling these
functions in different ways later on more difficult.

-David

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

[Aaron Falk]

On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:

>
> Thank you Larry for starting an interesting thread.  You and Rob have
> listed several candidate functions for Clearinghouses that don't really
> match the clearinghouse functions that Chip described at GEC4 (slide
> 15-21 of [1]).  Those functions really revolve around accountability:
>
>    1. User log-in.  A place for a user to create an account; it needs
>    to be capable of validating there is an organization accountable for
>    their actions.  It's not clear whether this validation is included
>    in the credential manager you mentioned.
>
>    2. Transaction Logging.  A reliable record of all resources a user
>    consumed.  Needed to determine accountability if something bad happens.
>
>    3. An ability to enforce global policies.
>

Larry-

In your SFA doc, you define a slice authority to be a principal
"responsible for the behavior of a set of slices, vouching for the
researchers running experiments in each slice and taking appropriate
action should the slice misbehave."  Would you agree that this is
roughly analogous to clearinghouse functions 1. and 2. as I've described
them?

Larry Peterson wrote:
> I don't think those are the right functions.
>
> 1) A place for a user to "log in" -- that's what we have
> registries for. You just need to get your university's
> authority (PI in PlanetLab-speak) to vouch for you.
> Then you acquire the credential(s) you need and
> you're off and running.

I don't think we should require every university to run a slice
authority to be able to participate in GENI.  As the value of the
resources that can be acquired in GENI grows, the need for
accountability will grow.  There will be policies for what it takes to
acquire a GENI log-in (who is vouching for the PI?  what fidelity of
out-of-band ID verification is needed?).  This will add to the burden of
running a slice authority.

If you accept that a slice authority is roughly analogous with a
clearinghouse, we don't have a disagreement that there can be multiple
of them with different policies.  I think we need at least one where we
develop a baseline set of policies and procedures so we can explore the
issues I've laid out above.  We need to find a set that will be
comfortable for the folks contributing resources (who is using my
stuff?  will my institution get sued?) the places a minimal burden on
both the contributors and the users.

>
> 2) Transaction logging -- implies a global "red button".
> I don't think you have that feature in a truly
> federated world. At the end of the day, each
> aggregate has to protect itself.

I think transaction logging and 'red button' represent two functions,
although the latter depends on the former.  Logging gives you a way to
figure out what happened after the fact.  If there is an attack launched
from GENI resources (deliberate or inadvertent) we should be able to
figure out who was accountable for those resources at the time.   Are
opposed to collecting any logs of resource utilization?  If not, where
do you think they should be?  Do you oppose having a single
"authoritative" log?

W.r.t. the 'red button' function, again, as the value of GENI resources
grows, the damage that can be done will grow and the need to shutdown
slices will grow.  I didn't think you were opposed to that.  I'm not
suggesting that the mechanism needs to be centralized, just reliable.
(It seems to me that a transaction log would be useful for such
mechanisms but perhaps I'm wrong.)  There's the open question of who can
request a slice to be shutdown and I don't think we have a sufficient
understanding of operations yet to say.  If there is GENI-wide
'meta-operations', it seems to me that they might become aware of slices
that need to be shutdown and should probably have that ability.  While
it's still too early to say, I think we shouldn't design that out of the
system.

>
> 3) Global allocation policy -- to the extent anything
> is global, then yes, you need something like this.
> It corresponds to one of the functions I named
> earlier (Resource Manager... I forget which number
> I gave it). But again, I think allocation rights originate
> with the owner of the aggregate; they may or may
> not delegate to a global entity.

I think we are in agreement then.  I don't think we've wrapped our heads
around the implications of global policy yet but it does seem to me that
a consenting aggregate should be able to grant a researcher something
that is beyond the 'global' policy.

--aaron



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

[Leigh Stoller]

> I don't think we should require every university to run a slice
> authority to be able to participate in GENI.  As the value of the
> resources that can be acquired in GENI grows, the need for
> accountability will grow.  There will be policies for what it takes to
> acquire a GENI log-in (who is vouching for the PI?  what fidelity of
> out-of-band ID verification is needed?).  This will add to the  
> burden of
> running a slice authority.
>
> If you accept that a slice authority is roughly analogous with a
> clearinghouse, we don't have a disagreement that there can be multiple
> of them with different policies.

Well, I would disagree that an SA is analogous with a clearinghouse.
If GENI wants to run an SA of last resort, that seems fine though.

> I think we need at least one where we develop a baseline set of
> policies and procedures so we can explore the issues I've laid out
> above.  We need to find a set that will be comfortable for the folks
> contributing resources (who is using my stuff?  will my institution
> get sued?) the places a minimal burden on both the contributors and
> the users.

This is more of an argument for a reference implementation of
a slice authority, just as there is a need for a reference
implementation of a clearinghouse.

> I think transaction logging and 'red button' represent two
> functions, although the latter depends on the former.  Logging gives
> you a way to figure out what happened after the fact.  If there is
> an attack launched from GENI resources (deliberate or inadvertent)
> we should be able to figure out who was accountable for those
> resources at the time.  Are opposed to collecting any logs of
> resource utilization?  If not, where do you think they should be?
> Do you oppose having a single "authoritative" log?

If there are multiple clearinghouses, then there are probably multiple
logs. I am not sure it is practical to have a single master
transaction log. Besides, sites will probably want to decide for
themselves how much data they want to release.

Lbs




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

[Aaron Falk]

Leigh Stoller wrote:

>> I don't think we should require every university to run a slice
>> authority to be able to participate in GENI.  As the value of the
>> resources that can be acquired in GENI grows, the need for
>> accountability will grow.  There will be policies for what it takes to
>> acquire a GENI log-in (who is vouching for the PI?  what fidelity of
>> out-of-band ID verification is needed?).  This will add to the burden of
>> running a slice authority.
>>
>> If you accept that a slice authority is roughly analogous with a
>> clearinghouse, we don't have a disagreement that there can be multiple
>> of them with different policies.
>
> Well, I would disagree that an SA is analogous with a clearinghouse.
> If GENI wants to run an SA of last resort, that seems fine though.

Well, I confess that I don't fully grok the SA.  Can you expand on how
you think they are different?

--aaron

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

[David Irwin-3]

> Well, I confess that I don't fully grok the SA.  Can you expand on how
> you think they are different?

I also don't quite grok it.  I also didn't quite grok the SFA's Slice
Manager, but the decomposition of functions discussed in the earlier
part of this thread clarified it for me somewhat.  I think decomposing
the Slice Authority into some set of underlying functions would help
here.

-David

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

[Larry Peterson]

Comments inline...

On Fri, Apr 17, 2009 at 9:51 AM, Aaron Falk <falk@...> wrote:

> On Thu, Apr 16, 2009 at 6:25 PM, Aaron Falk <falk@...> wrote:
>>
>> Thank you Larry for starting an interesting thread.  You and Rob have
>> listed several candidate functions for Clearinghouses that don't really
>> match the clearinghouse functions that Chip described at GEC4 (slide
>> 15-21 of [1]).  Those functions really revolve around accountability:
>>
>>    1. User log-in.  A place for a user to create an account; it needs
>>    to be capable of validating there is an organization accountable for
>>    their actions.  It's not clear whether this validation is included
>>    in the credential manager you mentioned.
>>
>>    2. Transaction Logging.  A reliable record of all resources a user
>>    consumed.  Needed to determine accountability if something bad happens.
>>
>>    3. An ability to enforce global policies.
>>
>
>
> Larry-
>
> In your SFA doc, you define a slice authority to be a principal
> "responsible for the behavior of a set of slices, vouching for the
> researchers running experiments in each slice and taking appropriate
> action should the slice misbehave."  Would you agree that this is
> roughly analogous to clearinghouse functions 1. and 2. as I've described
> them?

So what value-added does the clearinghouse provide? My point is that
the SFA lays out a set of "functions". (We've since identified some new
"sub-functions" because some people imagine building a widget with less
functionality than the SFA prescribes, and so want to off-load the missing
piece to someone else.)  As I said before, a clearinghouse is a collection
these functions -- you choose to bundle functions 1 and 2... the next guy
chooses to bundle 1, 2, and 3. Bundling is fine, but it's an exercise in
managing the implementation task (usually by simplifying it in some way).
It's not prescribing anything architectural.

>
> Larry Peterson wrote:
>> I don't think those are the right functions.
>>
>> 1) A place for a user to "log in" -- that's what we have
>> registries for. You just need to get your university's
>> authority (PI in PlanetLab-speak) to vouch for you.
>> Then you acquire the credential(s) you need and
>> you're off and running.
>
> I don't think we should require every university to run a slice
> authority to be able to participate in GENI.  As the value of the
> resources that can be acquired in GENI grows, the need for
> accountability will grow.  There will be policies for what it takes to
> acquire a GENI log-in (who is vouching for the PI?  what fidelity of
> out-of-band ID verification is needed?).  This will add to the burden of
> running a slice authority.

Yes, every university should have a slice authority -- I can't know
whether to approve Joe Random Student's slice; only you do. That
does not mean every university runs their own registry, which
records trust relationships created by slice authorities. In our version,
PLC runs a registry on behalf of all US universities and PLE runs a
registry on behalf of all European universities. If one day MIT asks
to run their own sub-registry, we ought to be able to support that, but
we don't require it.

>
> If you accept that a slice authority is roughly analogous with a
> clearinghouse, we don't have a disagreement that there can be multiple
> of them with different policies.  I think we need at least one where we
> develop a baseline set of policies and procedures so we can explore the
> issues I've laid out above.  We need to find a set that will be
> comfortable for the folks contributing resources (who is using my
> stuff?  will my institution get sued?) the places a minimal burden on
> both the contributors and the users.
>

I don't agree that authority = clearinghouse. By bundling functions we
need to not conflate the underlying functions (architectural elements).

>>
>> 2) Transaction logging -- implies a global "red button".
>> I don't think you have that feature in a truly
>> federated world. At the end of the day, each
>> aggregate has to protect itself.
>
> I think transaction logging and 'red button' represent two functions,
> although the latter depends on the former.  Logging gives you a way to
> figure out what happened after the fact.  If there is an attack launched
> from GENI resources (deliberate or inadvertent) we should be able to
> figure out who was accountable for those resources at the time.   Are
> opposed to collecting any logs of resource utilization?  If not, where
> do you think they should be?  Do you oppose having a single
> "authoritative" log?

There is an audit mechanism at the lowest level. It maps network
activity to slice. It's then a matter of figuring out globally where a
a bad slice exists. If we do not assume a single centralized slice
manager -- which I think is the case -- then we do not have a "root"
from which we can find all aggregates/components hosting that
slice, so the burden falls to aggregates to watch out for their own
interests.

This is a non-trivial discussion that we've had on various phone
calls. It's difficult to summarize in this context, but in summary,
unless we mandate a single GENI root/clearinghouse with a big
red button, and I hope we don't because it negates the advantages
of federation, then we have to develop other mechanisms by
which bad slices are squashed.

>
> W.r.t. the 'red button' function, again, as the value of GENI resources
> grows, the damage that can be done will grow and the need to shutdown
> slices will grow.  I didn't think you were opposed to that.  I'm not
> suggesting that the mechanism needs to be centralized, just reliable.
> (It seems to me that a transaction log would be useful for such
> mechanisms but perhaps I'm wrong.)  There's the open question of who can
> request a slice to be shutdown and I don't think we have a sufficient
> understanding of operations yet to say.  If there is GENI-wide
> 'meta-operations', it seems to me that they might become aware of slices
> that need to be shutdown and should probably have that ability.  While
> it's still too early to say, I think we shouldn't design that out of the
> system.

I think there's likely some sort of inter-NOC, and humans are involved.
I don't think I'm ever going to be willing to give you the credential to shut
down a slice on my aggregate. Slices do go bad, but the more common
scenario is that alarmists throw tantrums about slices without just cause.

>
>>
>> 3) Global allocation policy -- to the extent anything
>> is global, then yes, you need something like this.
>> It corresponds to one of the functions I named
>> earlier (Resource Manager... I forget which number
>> I gave it). But again, I think allocation rights originate
>> with the owner of the aggregate; they may or may
>> not delegate to a global entity.
>
> I think we are in agreement then.  I don't think we've wrapped our heads
> around the implications of global policy yet but it does seem to me that
> a consenting aggregate should be able to grant a researcher something
> that is beyond the 'global' policy.

I agree we don't understand this yet. I do think there are two different
perspectives (starting points), though. One is based on the presumption
of a global policy -- it focuses on how we achieve it. The other is based
on the presumption of aggregate autonomy -- it focuses on mechanisms
to support peering, should consenting aggregates have incentive to do
so. I tend to come at this from the latter perspective.

Larry

>
> --aaron
>
>
>

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

[David Irwin-3]

> So what value-added does the clearinghouse provide? My point is that
> the SFA lays out a set of "functions". (We've since identified some new
> "sub-functions" because some people imagine building a widget with less
> functionality than the SFA prescribes, and so want to off-load the missing
> piece to someone else.)  As I said before, a clearinghouse is a collection
> these functions -- you choose to bundle functions 1 and 2... the next guy
> chooses to bundle 1, 2, and 3. Bundling is fine, but it's an exercise in
> managing the implementation task (usually by simplifying it in some way).
> It's not prescribing anything architectural.

I agree that a Clearinghouse in and of itself doesn't add much
value----its the functions that it supports relative to the other
principals that adds value (what value depends on the composition of
functions).

I disagree with the assertion that bundling is an exercise in managing
an implementation task.  The ways in which functions can be composed
together within the different principals and interact between
principals is architectural.  This actually seems like the very
definition of architecture.  An important characteristic of a control
framework's architecture is its ability to readily support different
compositions.

> I agree we don't understand this yet. I do think there are two different
> perspectives (starting points), though. One is based on the presumption
> of a global policy -- it focuses on how we achieve it. The other is based
> on the presumption of aggregate autonomy -- it focuses on mechanisms
> to support peering, should consenting aggregates have incentive to do
> so. I tend to come at this from the latter perspective.

I also agree with this.  I don't think supporting global policies
periodically precludes a focus on mechanisms to support peering,
should consenting aggregates have an incentive to do so.  Aggregates
should choose when and how to contribute to a global policy; if they
don't want to then they should not contribute or contribute sparingly.

-David

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

[Robert P Ricci]

In my interpretation, an SA is a thing that has the ability to create
new slice names. So, a user walks up to an SA, says "I want to create a
slice", and that SA makes some policy decision about whether it's going
to let them. If the SA decides to make a new slice name for the user, it
bears some responsibility for what happens in that slice. An SA "vouches
for" a slice by giving it a name.

Thus spake David Irwin on Fri, Apr 17, 2009 at 10:33:59AM -0400:

> > Well, I confess that I don't fully grok the SA. ?Can you expand on how
> > you think they are different?
>
> I also don't quite grok it.  I also didn't quite grok the SFA's Slice
> Manager, but the decomposition of functions discussed in the earlier
> part of this thread clarified it for me somewhat.  I think decomposing
> the Slice Authority into some set of underlying functions would help
> here.
>
> -David
>
> _______________________________________________
> control-wg mailing list
> control-wg@...
> http://lists.geni.net/mailman/listinfo/control-wg

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[David Irwin-3]

> In my interpretation, an SA is a thing that has the ability to create
> new slice names. So, a user walks up to an SA, says "I want to create a
> slice", and that SA makes some policy decision about whether it's going
> to let them. If the SA decides to make a new slice name for the user, it
> bears some responsibility for what happens in that slice. An SA "vouches
> for" a slice by giving it a name.

Is that it's only function?  That seems like the Resource Manager
function described earlier.  As per my previous message, there may be
times when an AM (and its owner) what to control this function (e.g.,
to deny people resources so it can reserve them for local use) and
times when a Clearinghouse should control this function.  Both are
valid and important; a control framework should support both in my
opinion.  In other words, if each institution runs its own Slice
Authority, then it should be able to periodically delegate this power
to another entity (for a period of its choosing).

I do find it odd that the privileged operation here is "create and
name the slice."  I view the privileged operation as "reserve/create
resources for me".  In Orca, we don't bind the "reserve/create
resources" operation tightly with creating/naming a slice, so the
create/name slice operation isn't really privileged.  We use a slice
mostly on the User's side as a way for the user to specify a set of
attributes for a group of resources (e.g., all the nodes in this slice
should have this ssh public key authorized).

-David

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

[Robert P Ricci]

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:08:40PM -0400:
> > In my interpretation, an SA is a thing that has the ability to create
> > new slice names. So, a user walks up to an SA, says "I want to create a
> > slice", and that SA makes some policy decision about whether it's going
> > to let them. If the SA decides to make a new slice name for the user, it
> > bears some responsibility for what happens in that slice. An SA "vouches
> > for" a slice by giving it a name.
>
> Is that it's only function?  That seems like the Resource Manager
> function described earlier.

I think it's distinct, becuase simply having a slice name does *not*
entitle you to any resources. There is still policy that goes on when
deciding whether or not to grant you tickets (and those policy decisions
could take which Slice Authority authorized the slice into account.) The
SA is claiming some level of responsibility over what happens in the
slice, whatever resources it turns out people are willing to give to the
slice.

> I do find it odd that the privileged operation here is "create and
> name the slice."  I view the privileged operation as "reserve/create
> resources for me".  In Orca, we don't bind the "reserve/create
> resources" operation tightly with creating/naming a slice, so the
> create/name slice operation isn't really privileged.  We use a slice
> mostly on the User's side as a way for the user to specify a set of
> attributes for a group of resources (e.g., all the nodes in this slice
> should have this ssh public key authorized).

I think we agree that "reserve/create resources" is an important
priviledged operation - I think the existence of the SA is adding
another step, which is assigning overall responsiblity for the slice's
actions.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[Robert P Ricci]

Thus spake Robert P Ricci on Fri, Apr 17, 2009 at 11:20:29AM -0600:

> > I do find it odd that the privileged operation here is "create and
> > name the slice."  I view the privileged operation as "reserve/create
> > resources for me".  In Orca, we don't bind the "reserve/create
> > resources" operation tightly with creating/naming a slice, so the
> > create/name slice operation isn't really privileged.  We use a slice
> > mostly on the User's side as a way for the user to specify a set of
> > attributes for a group of resources (e.g., all the nodes in this slice
> > should have this ssh public key authorized).
>
> I think we agree that "reserve/create resources" is an important
> priviledged operation - I think the existence of the SA is adding
> another step, which is assigning overall responsiblity for the slice's
> actions.

To be a little more concrete - in PlanetLab, every slice is associated
with a 'site', so I know if the slice utah_robsbadslice is sending
apparent attack traffic, hogging resources, or whatever, I can talk to
Utah to complain about it. (I could talk to the slice's creator too, but
if s/he's behaving badly, I need to be able to talk to whoever has taken
responsibility for her/him). Similarly, in Emulab, every experiment is
associated with a "project", so I know I can talk to the person who's
registered as the head of the project that experiment is a part of if I
have any issues with the experiment. The TIED project uses the same
structure, as far as I know, as Emulab, since that's what it's built on.
I believe ORBIT has some kind of similar structure, and I don't know
about ORCA.

I see the SA as a pretty simple way to capture this set of schemes for
responsibility, which on one level are pretty similar (groups of users
for which some higher entity has claimed responsibility) and on another
level are pretty different (in PlanetLab, they must be organized by
institution, and in Emulab, they don't have to be, and the delegation
model for who is able to create slices differs), under a nice common
umbrella.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[David Irwin-3]

> I think it's distinct, becuase simply having a slice name does *not*
> entitle you to any resources. There is still policy that goes on when
> deciding whether or not to grant you tickets (and those policy decisions
> could take which Slice Authority authorized the slice into account.) The
> SA is claiming some level of responsibility over what happens in the
> slice, whatever resources it turns out people are willing to give to the
> slice.

Fair enough.  I see.  In this case, the "policy" may not have anything
to do with the resources.  However, my point is still valid.  There is
no reason why this SA couldn't choose to delegate this responsibility
to a Clearinghouse it trusts for some period of time.  Doing that does
provide some value, since each institution now doesn't have to
establish a relationship with every User that wants to run on its
resources.  Its fine if an institution doesn't want to delegate so it
can apply its own policies, but it should be able to do both.

> I think we agree that "reserve/create resources" is an important
> priviledged operation - I think the existence of the SA is adding
> another step, which is assigning overall responsiblity for the slice's
> actions.

Sure.  I see the distinction.  We have focused more heavily on the
applying this type of policy to entire Users (and not necessarily
their individual slices, if they have more than 1).

-David

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

[David Irwin-3]

> To be a little more concrete - in PlanetLab, every slice is associated
> with a 'site', so I know if the slice utah_robsbadslice is sending
> apparent attack traffic, hogging resources, or whatever, I can talk to
> Utah to complain about it. (I could talk to the slice's creator too, but
> if s/he's behaving badly, I need to be able to talk to whoever has taken
> responsibility for her/him). Similarly, in Emulab, every experiment is
> associated with a "project", so I know I can talk to the person who's
> registered as the head of the project that experiment is a part of if I
> have any issues with the experiment. The TIED project uses the same
> structure, as far as I know, as Emulab, since that's what it's built on.
> I believe ORBIT has some kind of similar structure, and I don't know
> about ORCA.

Orca has a similar structure.  Every slice is associated with a
principal that controls that slice.  The principal could represent an
entire institution or an individual researcher (doesn't really
matter).  The AM either knows who this principal is or can find out
(by talking to a Clearinghouse it trusts that approved this
principal).

> I see the SA as a pretty simple way to capture this set of schemes for
> responsibility, which on one level are pretty similar (groups of users
> for which some higher entity has claimed responsibility) and on another
> level are pretty different (in PlanetLab, they must be organized by
> institution, and in Emulab, they don't have to be, and the delegation
> model for who is able to create slices differs), under a nice common
> umbrella.

Sure.  The SA as you've defined it represents an important function.
It Orca this important could either reside at a Clearinghouse or in
each AM at different periods time.

-David

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

[Robert P Ricci]

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:35:00PM -0400:

> > I think it's distinct, becuase simply having a slice name does *not*
> > entitle you to any resources. There is still policy that goes on when
> > deciding whether or not to grant you tickets (and those policy decisions
> > could take which Slice Authority authorized the slice into account.) The
> > SA is claiming some level of responsibility over what happens in the
> > slice, whatever resources it turns out people are willing to give to the
> > slice.
>
> Fair enough.  I see.  In this case, the "policy" may not have anything
> to do with the resources.

Right - I see three separate statments to make here:

1) I vouch for the identity of this person
    Made by some authority (I'm not sure it has a name), by issuing a
        GENI identity to that person
2) I take responsiblity for the actions taken by this slice
    Made by a slice authority, by issuing a name for the slice
3) I allow this slice to use some resources
    Made by a component manager, broker, etc. depending on the model by
        issuing a ticket to that slice

The authorities in #1 and #2 *could* be institutions, and in fact could
be the same entity, but the model itself does not require that.

> However, my point is still valid.  There is
> no reason why this SA couldn't choose to delegate this responsibility
> to a Clearinghouse it trusts for some period of time.  Doing that does
> provide some value, since each institution now doesn't have to
> establish a relationship with every User that wants to run on its
> resources.  Its fine if an institution doesn't want to delegate so it
> can apply its own policies, but it should be able to do both.

A slice-name is a global identifier. So, I'm not sure I quite follow
your comment about instituions having to establish relationships with
every user. If you have some resources I want to use, I approach you
with a valid slice name that has been signed by some SA. You look at my
request and decide if you want to give me anything, and you very well
might look at which SA my slice was created by in making that decision.
(In our implementation, every member of the federation is given a list
of trusted SAs by the clearinghouse, but this is clearly not the only
possible design/policy.)

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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

[David Irwin-3]

> Right - I see three separate statments to make here:
>
> 1) I vouch for the identity of this person
>    Made by some authority (I'm not sure it has a name), by issuing a
>        GENI identity to that person
> 2) I take responsiblity for the actions taken by this slice
>    Made by a slice authority, by issuing a name for the slice
> 3) I allow this slice to use some resources
>    Made by a component manager, broker, etc. depending on the model by
>        issuing a ticket to that slice
>
> The authorities in #1 and #2 *could* be institutions, and in fact could
> be the same entity, but the model itself does not require that.

Sure.  Even #3 could be an institution (operating its own broker, for
instance) for that matter.  Or all three of these functions could be
inside of a Clearinghouse.   Or they could be split between
principals.

> A slice-name is a global identifier. So, I'm not sure I quite follow
> your comment about instituions having to establish relationships with
> every user. If you have some resources I want to use, I approach you
> with a valid slice name that has been signed by some SA. You look at my
> request and decide if you want to give me anything, and you very well
> might look at which SA my slice was created by in making that decision.
> (In our implementation, every member of the federation is given a list
> of trusted SAs by the clearinghouse, but this is clearly not the only
> possible design/policy.)

I was assuming that each Institution runs its own Slice Authority (as
per Larry's last email in this thread).  I was assuming that this
Slice Authority only controlled slice names at that institution (and
not at other institutions, since that would impinge on their own
ability to control their local policies).  Your comments indicate that
any institutions SA could apply a policy for creating/naming slices
that other SAs must (always) conform to.

-David

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

[Robert P Ricci]

Thus spake David Irwin on Fri, Apr 17, 2009 at 01:40:15PM -0400:

> > I see the SA as a pretty simple way to capture this set of schemes for
> > responsibility, which on one level are pretty similar (groups of users
> > for which some higher entity has claimed responsibility) and on another
> > level are pretty different (in PlanetLab, they must be organized by
> > institution, and in Emulab, they don't have to be, and the delegation
> > model for who is able to create slices differs), under a nice common
> > umbrella.
>
> Sure.  The SA as you've defined it represents an important function.
> It Orca this important could either reside at a Clearinghouse or in
> each AM at different periods time.

Good, that it also fits ORCA would seem to indicate that the function of
the SA was designed well. :)

I think the overall point here is that SAs *could* be bundled with
either CHs or AMs (in our implementation, we bundle them with AMs), but
that it offers valuable flexibility for the architecture to not *require*
that it be bundled with either one, since bundling with the CH implies
more centralization that some of us are comfortable with, and bundling
with the AM implies that accounts somehow go with resources, which is
not necessarily desirable either.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

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