Sample Resource Specifications for Substrate Components

[Patrick Crowley]

Dear substrate working group members,

At the recent GENI engineering conference, it was suggested that we
begin generating example resource specifications (Rspecs) for the
various substrate components people are currently contemplating (or
building). The exercise has two explicit objectives: 1) to get substrate
creators to think about how to characterize the assets they offer, and
2) to get the control working group members thinking about how to
characterize, control, and allocate the rich variety of substrate types
that people care about.

After a bit of discussion, Ted, Rob and I have two examples to offer to
get the conversation started. Below, you will find two sample Rspecs:

1. A PC, and
2. A Supercharged PlanetLab Platform (something we've built at WU)

As you can see, there is no explicit, machine-readable syntax in place
yet; so do not feel constrained by syntax in any way. We hope that the
examples are rich enough to get you started, and to help you uncover
anything that may be difficult when trying to generate an Rspec for your
favorite substrate type.

Please use this mailing list to publish your example Rspecs, along with
any questions or feedback you may have. Ted and Rob are both members of
this email list, and they (and I) will no doubt value your contributions
and questions.

We hope to have a nice batch of examples to discuss at the July GEC. We
hope and expect that all of the substrate presenters from the recent GEC
will submit example Rspecs to the email list; you know who you are (and
so do we).

Sincerely,
Patrick

Strawman Rspec for a PC (from Ted & Rob)
****************************************

I think what we're looking for (Rob will correct me if I'm wrong) is
constrained attributes for each category.  If you add new ones, give an
idea what attributes would be needed to cover your substrate.  For
example a PC advertisement might look like (for a 1.8 Ghz x86 processor
with 2 network interfaces configurable as bare HW or w/Linux):

Computation: 1.8 Ghz x86 (2 attribs speed and type)
External Communication: 100 Mb/s Ethernet
External Communication: 100 Mb/s Ethernet
Storage: 2 GB DRAM
Storage: 200 GB rotating disk
Extended options
Interface: Bare 386, Lunix RH4

I've sort of implicitly defined some attributes that I'll make explicit:
processor speed
processor type
interface bandwidth
interface MAC
storage size
storage type
PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS

That will give us an idea how many attributes need to be in the core
RSpec and where there's overlap.  Constraints might look like this:
(
Computation: 1.8 Ghz x86
External Communication: 100 Mb/s Ethernet
External Communication: 100 Mb/s Ethernet
)
OR
(
Computation: 2.5 Ghz x86
Computation: 2.5 Ghz x86
External Communication: 100 Mb/s Ethernet
)
Storage: 2 GB DRAM
Storage: 200 GB rotating disk
Extended options
Interface: Bare 386, Lunix RH4

Indicating that one could get a dual processor or a dual ethernet
machine, but not both.  That sort of advertisement might come from an
aggregate rather than a single component.

Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
**********************************************************************

I am providing two types of specifications:
- Physical resources, i.e. "system characteristics that determine class
of system"
- Requestable resources, i.e. "available control interfaces and resources"

Note that we decided to define entities hierarchically.

SYSTEM CHARACTERISTICS
**********************

GPE_x86:
   Computation: 2 Ghz Dual-core Xeon x86
   Computation: 2 Ghz Dual-core Xeon x86
   V Storage: 4 GB DRAM
   NV Storage: 37 GB rotating disk
   Interface: RH4 Linux, Planetlab Version 3.1.15
   Internal Communication: 10 Gb/s Ethernet (GGE)


NPE_IXP2850:
  Computation: 1.4GHz IXP 2850
  Computation: 1.4GHz IXP 2850
  V Storage: 768 MB DRAM per IXP #total of 1.536 GB
  V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
                                #1 Bank of 2 MB (total of 52 MB)
  V Storage: 18 Mb TCAM # Shared between IXPs, each with
                        # a dedicated interface
  Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
  Internal Communication: 10 Gb/s Ethernet (NGE)


Linecard_IXP2850:
   Component: NPE_IXP2850
   Internal Communication: 10 Gb/s Ethernet (LCGE)
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet
   External Communication: 1000 Mb/s Ethernet

SPP:
   Component: GPE_x86 (G1)
   Component: GPE_x86 (G2)
   Component: NPE_IXP2850 (I1)
   Component: NPE_IXP2850 (I2)
   Component: Linecard_IXP2850 (L1)
   Component: Backplane_10GE (B)

Backplane_10GE:
   Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
   Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
   Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
   Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
   Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
   Internal Communication: Crossbar, Fully provisioned

RESOURCES THAT CAN BE REQUESTED
*******************************
PlanetLab 3.1.15 node
PlanetLab fast paths: Bare IXP 2850, IPv4, I3
Network links: 1-10
Link bandwidth : 1-1000 Mbps
Link service: Best Effort, Guaranteed


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

[Mary Fernandez]

Greetings Patrick,

Has anyone in the substrate WG looked at the Common Information
Model (CIM) from DMTF: http://www.dmtf.org/standards/cim/?

The CIM has a UML data model description for just about anything
you can plug in.  This isn't necessarily a good thing, e.g.,
the CIM diagram for network components is 38 pages long!
http://www.dmtf.org/standards/cim/cim_schema_v2171/CIM_Network.pdf

And the Processor description is probably not rich enough:
http://www.dmtf.org/standards/cim/cim_schema_v2171/CIM_Device.pdf
(goto Page 3)

I'm personally interested in using UML (or a rational subset) to
formally define a data model for existing PlanetLab components,
and I tripped over CIM while learning about UML.

Why UML?  Because there are a lot of tools that generate
useful artifacts from UML descriptions, e.g., an XML Schema
for your data model, Java/Python class files, etc.

I think this could be a big win for people working on RSpecs
if they had easy-to-use tools for specifying their devices/components
and they could generate the necessary schemata automatically.

Thanks, Mary

On Fri, 2008-04-11 at 17:16 -0500, Patrick Crowley wrote:

> Dear substrate working group members,
>
> At the recent GENI engineering conference, it was suggested that we
> begin generating example resource specifications (Rspecs) for the
> various substrate components people are currently contemplating (or
> building). The exercise has two explicit objectives: 1) to get substrate
> creators to think about how to characterize the assets they offer, and
> 2) to get the control working group members thinking about how to
> characterize, control, and allocate the rich variety of substrate types
> that people care about.
>
> After a bit of discussion, Ted, Rob and I have two examples to offer to
> get the conversation started. Below, you will find two sample Rspecs:
>
> 1. A PC, and
> 2. A Supercharged PlanetLab Platform (something we've built at WU)
>
> As you can see, there is no explicit, machine-readable syntax in place
> yet; so do not feel constrained by syntax in any way. We hope that the
> examples are rich enough to get you started, and to help you uncover
> anything that may be difficult when trying to generate an Rspec for your
> favorite substrate type.
>
> Please use this mailing list to publish your example Rspecs, along with
> any questions or feedback you may have. Ted and Rob are both members of
> this email list, and they (and I) will no doubt value your contributions
> and questions.
>
> We hope to have a nice batch of examples to discuss at the July GEC. We
> hope and expect that all of the substrate presenters from the recent GEC
> will submit example Rspecs to the email list; you know who you are (and
> so do we).
>
> Sincerely,
> Patrick
>
> Strawman Rspec for a PC (from Ted & Rob)
> ****************************************
>
> I think what we're looking for (Rob will correct me if I'm wrong) is
> constrained attributes for each category.  If you add new ones, give an
> idea what attributes would be needed to cover your substrate.  For
> example a PC advertisement might look like (for a 1.8 Ghz x86 processor
> with 2 network interfaces configurable as bare HW or w/Linux):
>
> Computation: 1.8 Ghz x86 (2 attribs speed and type)
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> I've sort of implicitly defined some attributes that I'll make explicit:
> processor speed
> processor type
> interface bandwidth
> interface MAC
> storage size
> storage type
> PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS
>
> That will give us an idea how many attributes need to be in the core
> RSpec and where there's overlap.  Constraints might look like this:
> (
> Computation: 1.8 Ghz x86
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> )
> OR
> (
> Computation: 2.5 Ghz x86
> Computation: 2.5 Ghz x86
> External Communication: 100 Mb/s Ethernet
> )
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> Indicating that one could get a dual processor or a dual ethernet
> machine, but not both.  That sort of advertisement might come from an
> aggregate rather than a single component.
>
> Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
> **********************************************************************
>
> I am providing two types of specifications:
> - Physical resources, i.e. "system characteristics that determine class
> of system"
> - Requestable resources, i.e. "available control interfaces and resources"
>
> Note that we decided to define entities hierarchically.
>
> SYSTEM CHARACTERISTICS
> **********************
>
> GPE_x86:
>    Computation: 2 Ghz Dual-core Xeon x86
>    Computation: 2 Ghz Dual-core Xeon x86
>    V Storage: 4 GB DRAM
>    NV Storage: 37 GB rotating disk
>    Interface: RH4 Linux, Planetlab Version 3.1.15
>    Internal Communication: 10 Gb/s Ethernet (GGE)
>
>
> NPE_IXP2850:
>   Computation: 1.4GHz IXP 2850
>   Computation: 1.4GHz IXP 2850
>   V Storage: 768 MB DRAM per IXP #total of 1.536 GB
>   V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
>                                 #1 Bank of 2 MB (total of 52 MB)
>   V Storage: 18 Mb TCAM # Shared between IXPs, each with
>                         # a dedicated interface
>   Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
>   Internal Communication: 10 Gb/s Ethernet (NGE)
>
>
> Linecard_IXP2850:
>    Component: NPE_IXP2850
>    Internal Communication: 10 Gb/s Ethernet (LCGE)
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>    External Communication: 1000 Mb/s Ethernet
>
> SPP:
>    Component: GPE_x86 (G1)
>    Component: GPE_x86 (G2)
>    Component: NPE_IXP2850 (I1)
>    Component: NPE_IXP2850 (I2)
>    Component: Linecard_IXP2850 (L1)
>    Component: Backplane_10GE (B)
>
> Backplane_10GE:
>    Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
>    Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
>    Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
>    Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
>    Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
>    Internal Communication: Crossbar, Fully provisioned
>
> RESOURCES THAT CAN BE REQUESTED
> *******************************
> PlanetLab 3.1.15 node
> PlanetLab fast paths: Bare IXP 2850, IPv4, I3
> Network links: 1-10
> Link bandwidth : 1-1000 Mbps
> Link service: Best Effort, Guaranteed
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg

--
Mary Fernandez <mff@...>
AT&T Labs Research


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

[John Jacob-2]

Patrick, Ted and Rob

It is not clear to me that these resources can be sliced? Is this
something that needs to be identified in the Rspec? As presented in
these examples, it seems like the two machine types do not support
simultaneous, isolated slices. Is this true? How might an Rspec differ
for the case of simultaneously shared resources?

John



Patrick Crowley wrote:

> Dear substrate working group members,
>
> At the recent GENI engineering conference, it was suggested that we
> begin generating example resource specifications (Rspecs) for the
> various substrate components people are currently contemplating (or
> building). The exercise has two explicit objectives: 1) to get
> substrate creators to think about how to characterize the assets they
> offer, and 2) to get the control working group members thinking about
> how to characterize, control, and allocate the rich variety of
> substrate types that people care about.
>
> After a bit of discussion, Ted, Rob and I have two examples to offer
> to get the conversation started. Below, you will find two sample Rspecs:
>
> 1. A PC, and
> 2. A Supercharged PlanetLab Platform (something we've built at WU)
>
> As you can see, there is no explicit, machine-readable syntax in place
> yet; so do not feel constrained by syntax in any way. We hope that the
> examples are rich enough to get you started, and to help you uncover
> anything that may be difficult when trying to generate an Rspec for
> your favorite substrate type.
>
> Please use this mailing list to publish your example Rspecs, along
> with any questions or feedback you may have. Ted and Rob are both
> members of this email list, and they (and I) will no doubt value your
> contributions and questions.
>
> We hope to have a nice batch of examples to discuss at the July GEC.
> We hope and expect that all of the substrate presenters from the
> recent GEC will submit example Rspecs to the email list; you know who
> you are (and so do we).
>
> Sincerely,
> Patrick
>
> Strawman Rspec for a PC (from Ted & Rob)
> ****************************************
>
> I think what we're looking for (Rob will correct me if I'm wrong) is
> constrained attributes for each category.  If you add new ones, give an
> idea what attributes would be needed to cover your substrate.  For
> example a PC advertisement might look like (for a 1.8 Ghz x86 processor
> with 2 network interfaces configurable as bare HW or w/Linux):
>
> Computation: 1.8 Ghz x86 (2 attribs speed and type)
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> I've sort of implicitly defined some attributes that I'll make explicit:
> processor speed
> processor type
> interface bandwidth
> interface MAC
> storage size
> storage type
> PC interfaces: x86, Windows, Linux, FreeBSD, AmigaDOS
>
> That will give us an idea how many attributes need to be in the core
> RSpec and where there's overlap.  Constraints might look like this:
> (
> Computation: 1.8 Ghz x86
> External Communication: 100 Mb/s Ethernet
> External Communication: 100 Mb/s Ethernet
> )
> OR
> (
> Computation: 2.5 Ghz x86
> Computation: 2.5 Ghz x86
> External Communication: 100 Mb/s Ethernet
> )
> Storage: 2 GB DRAM
> Storage: 200 GB rotating disk
> Extended options
> Interface: Bare 386, Lunix RH4
>
> Indicating that one could get a dual processor or a dual ethernet
> machine, but not both.  That sort of advertisement might come from an
> aggregate rather than a single component.
>
> Strawman Rspec for Supercharged PlanetLab Platform (SPP, from Patrick)
> **********************************************************************
>
> I am providing two types of specifications:
> - Physical resources, i.e. "system characteristics that determine
> class of system"
> - Requestable resources, i.e. "available control interfaces and
> resources"
>
> Note that we decided to define entities hierarchically.
>
> SYSTEM CHARACTERISTICS
> **********************
>
> GPE_x86:
>   Computation: 2 Ghz Dual-core Xeon x86
>   Computation: 2 Ghz Dual-core Xeon x86
>   V Storage: 4 GB DRAM
>   NV Storage: 37 GB rotating disk
>   Interface: RH4 Linux, Planetlab Version 3.1.15
>   Internal Communication: 10 Gb/s Ethernet (GGE)
>
>
> NPE_IXP2850:
>  Computation: 1.4GHz IXP 2850
>  Computation: 1.4GHz IXP 2850
>  V Storage: 768 MB DRAM per IXP #total of 1.536 GB
>  V Storage: 26 Mb SRAM per IXP #3 Banks of 8 MB each and
>                                #1 Bank of 2 MB (total of 52 MB)
>  V Storage: 18 Mb TCAM # Shared between IXPs, each with
>                        # a dedicated interface
>  Interface: Bare IXP 2850, RH4 Linux, Planetlab fast paths
>  Internal Communication: 10 Gb/s Ethernet (NGE)
>
>
> Linecard_IXP2850:
>   Component: NPE_IXP2850
>   Internal Communication: 10 Gb/s Ethernet (LCGE)
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>   External Communication: 1000 Mb/s Ethernet
>
> SPP:
>   Component: GPE_x86 (G1)
>   Component: GPE_x86 (G2)
>   Component: NPE_IXP2850 (I1)
>   Component: NPE_IXP2850 (I2)
>   Component: Linecard_IXP2850 (L1)
>   Component: Backplane_10GE (B)
>
> Backplane_10GE:
>   Internal Communication: 10 Gb/s Ethernet (BGE1) -> G1/GGE
>   Internal Communication: 10 Gb/s Ethernet (BGE2) -> G2/GGE
>   Internal Communication: 10 Gb/s Ethernet (BGE3) -> I1/NGE
>   Internal Communication: 10 Gb/s Ethernet (BGE4) -> I2/NGE
>   Internal Communication: 10 Gb/s Ethernet (BGE5) -> L1/LCGE
>   Internal Communication: Crossbar, Fully provisioned
>
> RESOURCES THAT CAN BE REQUESTED
> *******************************
> PlanetLab 3.1.15 node
> PlanetLab fast paths: Bare IXP 2850, IPv4, I3
> Network links: 1-10
> Link bandwidth : 1-1000 Mbps
> Link service: Best Effort, Guaranteed
> ------------------------------------------------------------------------
>
> _______________________________________________
> substrate-wg mailing list
> substrate-wg@...
> http://lists.geni.net/mailman/listinfo/substrate-wg
>  

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

[Ted Faber]

On Fri, Apr 18, 2008 at 07:38:05AM -0400, John Jacob wrote:
> Patrick, Ted and Rob
>
> It is not clear to me that these resources can be sliced? Is this
> something that needs to be identified in the Rspec? As presented in
> these examples, it seems like the two machine types do not support
> simultaneous, isolated slices. Is this true? How might an Rspec differ
> for the case of simultaneously shared resources?

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.

Maybe the issue is that there's no indication of how thickly the
resources can be sliced?  That does seem like the kind of thing one
would like to communicate in an advertisement, and that one would
consider in picking which components to try to instantiate on.

Rob, does that sound like something we need to add?  I'm worried that
there's a pretty big can of worms under there (there are lots of ways to
slice).  Do you think there's a simple, general slicing granularity
metric that we can communicate?

I'm tempted to say that for each resource there's a granularity
parameter (2.5 GHz of CPU in 500 MHz slices).  That certainly may get
more complex for connectivity.

John, is that the issue you're getting at or did I miss it.

--
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

[John Jacob-2]

Ted,

Yes, this is the issue I was getting at. The basic question is how to
identify slicing granularity, and possibly isolation,  in an Rspec. You
captured the issue well. I agree that there will be many ways to slice
the diverse substrate technologies as well as different ways to slice
similar substrate technologies, which is one of the reason we might want
to advertise the granularity. In a similar manner, two similar resources
with similar slice granularities may have different isolation
properties, which is something else we might need to consider in an
advertisement of a resource. On this latter point, is isolation a
prerequisite for slicing, or can a resource be sliced with different
degrees of isolation?

John


Ted Faber wrote:

> On Fri, Apr 18, 2008 at 07:38:05AM -0400, John Jacob wrote:
>  
>> Patrick, Ted and Rob
>>
>> It is not clear to me that these resources can be sliced? Is this
>> something that needs to be identified in the Rspec? As presented in
>> these examples, it seems like the two machine types do not support
>> simultaneous, isolated slices. Is this true? How might an Rspec differ
>> for the case of simultaneously shared resources?
>>    
>
> 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.
>
> Maybe the issue is that there's no indication of how thickly the
> resources can be sliced?  That does seem like the kind of thing one
> would like to communicate in an advertisement, and that one would
> consider in picking which components to try to instantiate on.
>
> Rob, does that sound like something we need to add?  I'm worried that
> there's a pretty big can of worms under there (there are lots of ways to
> slice).  Do you think there's a simple, general slicing granularity
> metric that we can communicate?
>
> I'm tempted to say that for each resource there's a granularity
> parameter (2.5 GHz of CPU in 500 MHz slices).  That certainly may get
> more complex for connectivity.
>
> John, is that the issue you're getting at or did I miss it.
>
>  

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

[Jay Lepreau]

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.

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?

John said:
> In a similar manner, two similar resources with similar slice
> granularities may have different isolation properties, which is
> something else we might need to consider in an advertisement of a
> resource.

This is a good point I had not thought of.  Could do an arbitrary metric
from 1-N (eg 5), or avoid that with an enumeration of the isolation
mechanisms (vservers, Xen VMs, flow tables, ...)

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

[Ted Faber]

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 Faber]

On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:

> Ted,
>
> Yes, this is the issue I was getting at. The basic question is how to
> identify slicing granularity, and possibly isolation,  in an Rspec. You
> captured the issue well. I agree that there will be many ways to slice
> the diverse substrate technologies as well as different ways to slice
> similar substrate technologies, which is one of the reason we might want
> to advertise the granularity. In a similar manner, two similar resources
> with similar slice granularities may have different isolation
> properties, which is something else we might need to consider in an
> advertisement of a resource. On this latter point, is isolation a
> prerequisite for slicing, or can a resource be sliced with different
> degrees of isolation?

People have certainly put forth the idea of allocating resources as
"best effort," which sounds a lot like "with minimal isolation" to me.
It's a little tough to think of isolation in terms other than "as
complete as we can make it" and "no guarantees," though.  Are you
thinking of a scale that's more experessive than that?

I agree with you that an expression of granularity could be useful.  I
worry that with the many axes on which one can slice, coming up with the
right abstraction for granularity is tricky.  I wonder if a combination
of aggregation and simple time/space granularity expressions is
sufficient...

--
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

[Jay Lepreau]

> In my understanding slicable and allocable are synonyms.

Seems strange.  This definition devalues/reduces the word "sliceable"
from its intuitive and historical meaning.  I think that's a bad
idea in terms of documentation and clarity.

But, the result is that you and I agree about what resources are sliceable.

> 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.

Good, we agree (except for the definition of the word).

> 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.

Right.  Programmable is orthogonal.

> 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.

Sounds like we're in violent agreement.

But via your many examples it seems that your "sliceable" has now
lost all its semantics.

> Even if we disagree on "slicable" do you
> believe the goal of describing resources researchers can ask for and
> receive?

Absolutely.

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

[Ted Faber]

On Wed, Apr 23, 2008 at 12:49:39PM -0600, Jay Lepreau wrote:
> Sounds like we're in violent agreement.

Great.
>
> But via your many examples it seems that your "sliceable" has now
> lost all its semantics.

So by sliceable you mean virtualizable?  If I hand you exclusive control
of a resource I haven't sliced it?

--
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

[Jay Lepreau]

> So by sliceable you mean virtualizable?  If I hand you exclusive control
> of a resource I haven't sliced it?

Yes.

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

[Christopher White-5]

On Tue, 2008-04-22 at 17:58 -0700, Ted Faber wrote:
> 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.

I think of an experimenter looking at RSpecs as the list of what is
available for reservation.  The fact that the device advertising the
RSpec must slice an underlying device to achieve a reservation is an
implementation detail.

It seems much like a newspaper offering advertising space.  You can
purchase advertisements of multiple sizes (1 inch, 1 column, 1/4 page,
etc.)  As someone purchasing ad space, I don't care what the ultimate ad
capacity of the entire paper is, nor how many ways that capacity can be
chopped up, I only care what sizes are available for me to purchase.

As such, the RSpec should define the bounds possible for a single
reservation, but the fact that it's a slice of something larger is less
interesting.  For example, take a 1Gb Ethernet link.  The RSpec might
advertise the set [1GB, 100Mb, 10Mb].  If the user asks for 100Mb, the
device must slice the link to satisfy it.

...cj

--
Christopher J. White
cwhite@...
Principal Software Engineer
Mazu Networks


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

[John Jacob-2]

Christopher White wrote:
> For example, take a 1Gb Ethernet link.  The RSpec might
> advertise the set [1GB, 100Mb, 10Mb].  If the user asks for 100Mb, the
> device must slice the link to satisfy it.
>
> ...cj
>
>  
Chris,

I agree with this, but it was not clear to me that the two examples
which started this discussion included a set of resources divided in
this way.  If I take your example above, and apply what we had in the
two worked examples, the Rspec for this case would only list the 1GB
link. Rephrasing the original question being asked, shouldn't the Rspec
also list 100Mb and 10Mb, where the 10Mb is the slicing granularity?

John


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

[Aaron Falk]

On Apr 24, 2008, at 4:09 AM, Ted Faber wrote:
>> But via your many examples it seems that your "sliceable" has now
>> lost all its semantics.
>
> So by sliceable you mean virtualizable?  If I hand you exclusive  
> control
> of a resource I haven't sliced it?

When I use the term sliceable I mean shareable.  Virtualization is a  
technique for sharing but there are others.

--aaron

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

[John Jacob-2]

Ted Faber wrote:

> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>  
>> Ted,
>>
>> Yes, this is the issue I was getting at. The basic question is how to
>> identify slicing granularity, and possibly isolation,  in an Rspec. You
>> captured the issue well. I agree that there will be many ways to slice
>> the diverse substrate technologies as well as different ways to slice
>> similar substrate technologies, which is one of the reason we might want
>> to advertise the granularity. In a similar manner, two similar resources
>> with similar slice granularities may have different isolation
>> properties, which is something else we might need to consider in an
>> advertisement of a resource. On this latter point, is isolation a
>> prerequisite for slicing, or can a resource be sliced with different
>> degrees of isolation?
>>    
>
> People have certainly put forth the idea of allocating resources as
> "best effort," which sounds a lot like "with minimal isolation" to me.
> It's a little tough to think of isolation in terms other than "as
> complete as we can make it" and "no guarantees," though.  Are you
> thinking of a scale that's more experessive than that?
>  

Ted,

I am not thinking of a specific scale, I am just wondering if some
information  regarding  the isolation of a shared resource has a place
in the RSpecs.

John

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

[Christopher White-5]

On my way into work, I was thinking more about a variation of your
question.  Lets say the device has 2x1Gb plus 4x100Mb links.  A user has
a need for 8x100Mb links as a virtual switch.  If the device is not
sliceable, it cannot satisfy this request.  Assuming it can slice, the
device has multiple ways of satisfying this request, including
allocating all 4 as slices from the same single 1Gb link.   The
constraints on which links can be used will fall to connectivity on the
other side of those links.

So how would the device advertise it's resources?  Somewhere the user
must be able to discern that "the device can support up to 24x100Mb
links" and in addition "the device can support up to 2 1Gb links".  They
can't *all* be satisfied at the same time, but they represent the
capability.

My primary concern is that an RSpec for the 1Gb link stating it can be
sliced to 10Mb granularity then puts the work elsewhere divide up the
link to determine just how many links it can support.  This may be
necessary if the granularity is highly variable (ie. in 10Mb chunks).  

It seems there is room in the gray area between the RSpec and the end
user that does this calculation such that the user

As such it seems there is need for a third parameter indicating the
upper bound on how much the link can be split.  I.e,  [1Gb - 100Mb, in
10Mb gran, max 8 virtual links].

...cj

On Thu, 2008-04-24 at 07:47 -0400, John Jacob wrote:

> Christopher White wrote:
> > For example, take a 1Gb Ethernet link.  The RSpec might
> > advertise the set [1GB, 100Mb, 10Mb].  If the user asks for 100Mb, the
> > device must slice the link to satisfy it.
> >
> > ...cj
> >
> >  
> Chris,
>
> I agree with this, but it was not clear to me that the two examples
> which started this discussion included a set of resources divided in
> this way.  If I take your example above, and apply what we had in the
> two worked examples, the Rspec for this case would only list the 1GB
> link. Rephrasing the original question being asked, shouldn't the Rspec
> also list 100Mb and 10Mb, where the 10Mb is the slicing granularity?
>
> John
>

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

[Heidi Picher Dempsey-2]

On Apr 24, 2008, at 8:08 AM, John Jacob wrote:

> Ted Faber wrote:
>> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>>
>>> Ted,
>>>
>>> Yes, this is the issue I was getting at. The basic question is how  
>>> to
>>> identify slicing granularity, and possibly isolation,  in an  
>>> Rspec. You
>>> captured the issue well. I agree that there will be many ways to  
>>> slice
>>> the diverse substrate technologies as well as different ways to  
>>> slice
>>> similar substrate technologies, which is one of the reason we  
>>> might want
>>> to advertise the granularity. In a similar manner, two similar  
>>> resources
>>> with similar slice granularities may have different isolation
>>> properties, which is something else we might need to consider in an
>>> advertisement of a resource. On this latter point, is isolation a
>>> prerequisite for slicing, or can a resource be sliced with different
>>> degrees of isolation?
>>>
>>
>> People have certainly put forth the idea of allocating resources as
>> "best effort," which sounds a lot like "with minimal isolation" to  
>> me.
>> It's a little tough to think of isolation in terms other than "as
>> complete as we can make it" and "no guarantees," though.  Are you
>> thinking of a scale that's more experessive than that?
>>
>
> Ted,
>
> I am not thinking of a specific scale, I am just wondering if some
> information  regarding  the isolation of a shared resource has a place
> in the RSpecs.
>
> John

 From a practical point of view, I think I would want to know whether  
I had all or part of a resource in my slice in some cases, because  
some techniques for sharing might be more likely to always work than  
others.  For example, getting an entire node dedicated to me might be  
virtually "guaranteed" in the sense used previously in this message,  
but getting a certain amount of bandwidth on an experimental router  
that was using priority queuing might not be.  I wouldn't expect the  
RSPEC to give me any scale of how "shared" it was, but a shared/not  
shared bit could be useful for debugging.

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


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

[Jay Lepreau]

> > So by sliceable you mean virtualizable?  If I hand you exclusive  
> > control of a resource I haven't sliced it?

> When I use the term sliceable I mean shareable.  Virtualization is a  
> technique for sharing but there are others.

Let's distinguish between a single resource and a set of resources
(perhaps represented as an aggregate component).  Eg, a single Mica2
sensor mote won't be simultaneously shareable by multiple slices.
However, a set of motes clearly can be space-shared.

In general, when we refer to "a resource" in GENI, we've been
referring to a single physical entity, not a set of them.
And that affects the kind of sharing possible on a single resource.

That doesn't mean we can't clarify the docs and explicitly address
sets of resources.

Just trying for clarity...

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

[stuart.d.elby]

I am concerned with the complexity added by including some advertisement
and then guarantee of isolation.  The idea of simply 'shared/not shared'
makes a lot of sense to me.  With just this information, the designer of
the experiment will then be able to craft the trial in such a way that
provides the level of resource guarantees she needs without pushing this
complexity down into the Substrate infrastructure.

What we may want to think about is what we mean by "best effort"
sharing.  For example, is it an average resource availability over some
long time period or is it a peak availability of that resource?  Having,
at least as a target, a common view of what form sharing will take will
make experiment designers' tasks easier. If we allow every type of
sliceable resource to have its own type of "best effort" we will need a
much more elaborate advertising scheme than 'shared/not shared' and the
task of experiment design will require detailed Substrate network
engineering expertise beyond what should be required of a 'user'.

-Stu Elby
 Verizon  

-----Original Message-----
From: substrate-wg-bounces@...
[mailto:substrate-wg-bounces@...] On Behalf Of Heidi Picher Dempsey
Sent: Thursday, April 24, 2008 11:57 AM
To: John Jacob
Cc: Substrate-WG@...; Ted Faber
Subject: Re: [substrate-wg] Sample Resource Specifications forSubstrate
Components


On Apr 24, 2008, at 8:08 AM, John Jacob wrote:

> Ted Faber wrote:
>> On Tue, Apr 22, 2008 at 03:23:56PM -0400, John Jacob wrote:
>>
>>> Ted,
>>>
>>> Yes, this is the issue I was getting at. The basic question is how
>>> to identify slicing granularity, and possibly isolation,  in an
>>> Rspec. You captured the issue well. I agree that there will be many
>>> ways to slice the diverse substrate technologies as well as
>>> different ways to slice similar substrate technologies, which is one

>>> of the reason we might want to advertise the granularity. In a
>>> similar manner, two similar resources with similar slice
>>> granularities may have different isolation properties, which is
>>> something else we might need to consider in an advertisement of a
>>> resource. On this latter point, is isolation a prerequisite for
>>> slicing, or can a resource be sliced with different degrees of
>>> isolation?
>>>
>>
>> People have certainly put forth the idea of allocating resources as
>> "best effort," which sounds a lot like "with minimal isolation" to
>> me.
>> It's a little tough to think of isolation in terms other than "as
>> complete as we can make it" and "no guarantees," though.  Are you
>> thinking of a scale that's more experessive than that?
>>
>
> Ted,
>
> I am not thinking of a specific scale, I am just wondering if some
> information  regarding  the isolation of a shared resource has a place

> in the RSpecs.
>
> John

 From a practical point of view, I think I would want to know whether I
had all or part of a resource in my slice in some cases, because some
techniques for sharing might be more likely to always work than others.
For example, getting an entire node dedicated to me might be virtually
"guaranteed" in the sense used previously in this message, but getting a
certain amount of bandwidth on an experimental router that was using
priority queuing might not be.  I wouldn't expect the RSPEC to give me
any scale of how "shared" it was, but a shared/not shared bit could be
useful for debugging.

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


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

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