« Return to Thread: Sample Resource Specifications for Substrate Components
Re: Sample Resource Specifications for Substrate Components
by Ted Faber
::
Rate this Message:
On Tue, Apr 22, 2008 at 05:18:03PM -0600, Jay Lepreau wrote:
>
> Ted said:
> > Patrick or Rob will correct me if I say something bogus, but the intent
> > is that resources described by an RSpec are intended to be slicable.
>
> This must-be-sliceable requirement makes no sense to me
> and I do not remember ever hearing it before.
Let me see if my reasoning makes any sense to you.
>
> Reasons:
> -RSpecs are the universal way to describe resources of this type
> (computational, network, probably storage, maybe measurment),
> including virtual resources (the virtual resources/network requested
> by the experimenter) which by definition and practice are clearly not
> sliceable.
>
> -The GENI design, docs, and our discussions in the architecture group
> explicitly allow "virtualization" through space-sharing as well as
> intra-resource slicing. The docs use sensor nodes as onme example,
> but there are plenty of cases where it will make sense to do
> space-sharing or exclusive assignment, e.g. devices with poor or
> costly or not yet developed isolation mechanisms, such as NetFPGAs.
>
> -What's the value and motivation for proposing such a restriction?In my understanding slicable and allocable are synonyms. I may slice a
resource by handing it all to you, virtualizing some set of resources
and handing them to you, or scheduling your use so they don't interfere
with others. That's a pretty wide range of techniques swallowed up in
one word, but I understand slicing to imply an allocation of resources
isolated temporally, spatially, or virtually.
Slicable doesn't necessarily mean programmable to me. If I'm allocated
half the capacity of a link, that doesn't mean I get to program the
controller, but the link's been sliced.
If I understand your example above of unslicable virtual resources
above, I think they're still slicable by my broader definition: I could
give them to another researcher as a whole. I understand that they're
probably not further virtualizable.
By talking about resources that slicable by that definition, RSpecs talk
about anything a user could ask to be given or that a component can
allocate. That seems like a small, clean thing to describe, and it's
what I think RSpecs are for. Even if we disagree on "slicable" do you
believe the goal of describing resources researchers can ask for and
receive?
--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
substrate-wg mailing list
substrate-wg@...
http://lists.geni.net/mailman/listinfo/substrate-wg
>
> Ted said:
> > Patrick or Rob will correct me if I say something bogus, but the intent
> > is that resources described by an RSpec are intended to be slicable.
>
> This must-be-sliceable requirement makes no sense to me
> and I do not remember ever hearing it before.
Let me see if my reasoning makes any sense to you.
>
> Reasons:
> -RSpecs are the universal way to describe resources of this type
> (computational, network, probably storage, maybe measurment),
> including virtual resources (the virtual resources/network requested
> by the experimenter) which by definition and practice are clearly not
> sliceable.
>
> -The GENI design, docs, and our discussions in the architecture group
> explicitly allow "virtualization" through space-sharing as well as
> intra-resource slicing. The docs use sensor nodes as onme example,
> but there are plenty of cases where it will make sense to do
> space-sharing or exclusive assignment, e.g. devices with poor or
> costly or not yet developed isolation mechanisms, such as NetFPGAs.
>
> -What's the value and motivation for proposing such a restriction?
resource by handing it all to you, virtualizing some set of resources
and handing them to you, or scheduling your use so they don't interfere
with others. That's a pretty wide range of techniques swallowed up in
one word, but I understand slicing to imply an allocation of resources
isolated temporally, spatially, or virtually.
Slicable doesn't necessarily mean programmable to me. If I'm allocated
half the capacity of a link, that doesn't mean I get to program the
controller, but the link's been sliced.
If I understand your example above of unslicable virtual resources
above, I think they're still slicable by my broader definition: I could
give them to another researcher as a whole. I understand that they're
probably not further virtualizable.
By talking about resources that slicable by that definition, RSpecs talk
about anything a user could ask to be given or that a component can
allocate. That seems like a small, clean thing to describe, and it's
what I think RSpecs are for. Even if we disagree on "slicable" do you
believe the goal of describing resources researchers can ask for and
receive?
--
Ted Faber
http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
substrate-wg mailing list
substrate-wg@...
http://lists.geni.net/mailman/listinfo/substrate-wg
attachment0 (202 bytes) « Return to Thread: Sample Resource Specifications for Substrate Components
| Free embeddable forum powered by Nabble | Forum Help |
