summary of discussions and near term goals

[John Jacob-2]

All,

Thank you for the recent discussions on this mailing list, it has been
very helpful and we (GPO) are pleased by the level of activity.  Below
is a list of comments and questions I believe summarizes the discussion
to date.

1. We need consensus on definitions for all column headings in the excel
spreadsheet. The two which seem to generate the most discussion are
component and sliceable.

1a. One area of confusion with component column was the notion of a
component being constructed from a set of other components, specifically
the network component.  As shown in the latest spreadsheet,  the
wireless sensor domain may view subnets as a substrate component. There
was also input to this list suggesting that a network could be spatially
separated for isolated experiments, which may also support treating the
network, and other scenarios where a group of components, is itself
treated as a component. I would like the near term focus be to build
consensus on what we mean by component and that we have a complete list
in Column A. Although other columns in the spreadsheet may raise
questions, I would like to suggest an approach to get the list of
components agreed upon. As it currently stands, component and substrate
is somewhat blurred. A distinction may be that anything which has a
resource available for a GENI researcher to build a slice from should be
considered a component.

1b. There was some discussion on links, are these resources of a
"network" component or should we create a separate link component?

1c. I believe "sliceable" is a bad term for a couple of reasons, one is
that the term slice is used in GENI to refer to a specific researchers
collection of GENI resources, and each piece of a resource is called a
sliver. Instead of "sliceable", I will start using dividable (assuming
no objection or other suggestions). I also believe that dividable could
be redundant with resource, since a resource is ideally something that
can be shared across many experiments. If in-fact, a resource is not
dividable, it may be an exception and not the rule. So, in future
versions of this spreadsheet, the dividable column may be deleted.

2. The concept of measurement and how it affects our work in the
substrate-wg, is not presently addressed in the spreadsheet, however it
probably should be included. Currently, I can identify three areas where
measurement distinctions may be drawn; GIMS as a measurement service,
for use in GENI operations and management, and the dependence of
external test equipment on substrate components/architecture. There was
earlier discussion on measurements for cross-layer networking, but I
believe this could be addressed in the following discussion on control
plane.

3. The GENI narrow waist control and operations management entities are
outside the scope of research, and are essential in ensuring a safe and
robust GENI environment. Furthermore, control and management research
will not be allowed to compromise this essential operation. However,
there is significant interest in using GENI for research on control and
management of next generation networks. The research elements of control
and management probably should fall into the substrate-wg activities.
 From the perspective of identifying components and resources, how
should we position these network functions?

4. A comment was made that the current substrate-component-resource
hierarchy implied by the worksheet may not be adequate. We are not
constrained by a column count, so we should do whatever makes the most
sense. Hopefully the answer to this will evolve as we populate the
worksheet. To reiterate my previous suggestion, I would like to see the
wg focus on column A (components) first, and we can build from that base.

I believe this captures the discussions thus far, if I have omitted or
missed on the interpretation, please speak up. Attached is the latest
version of the spreadsheet. What is missing, confusing, wrong? Do we
have wireless covered? What about a wireless subnet distinction from
wireless sensor subnets?

Thanks,
John


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

[Paul Morton]

Hi John, All,

I believe that Timing is an important concept that we need to somehow  
include in the matrix.  It is a concept that needs to be relayed to  
the other WGs so that it becomes part of the GENI infrastructure - A  
Timing Service? - How do we enable time-division-multiplexing on  
GENI?  Can we support experiments that require a synchronous network  
or circuits?  Are there different levels of timing (services) that  
need supporting - Fine granularity (for TDM etc), Course - GPS/
seconds, Loose (slow) for management...?

I am not sure how best to define this or include it, but I feel  
strongly that we need to include Timing as one aspect of the  
substrate.  Hopefully others in the working group can help define it  
and fit it into the matrix framework...

Paul

On Nov 6, 2007, at 10:41 AM, John Jacob wrote:

> All,
>
> Thank you for the recent discussions on this mailing list, it has  
> been very helpful and we (GPO) are pleased by the level of  
> activity.  Below is a list of comments and questions I believe  
> summarizes the discussion to date.
>
> 1. We need consensus on definitions for all column headings in the  
> excel spreadsheet. The two which seem to generate the most  
> discussion are component and sliceable.
>
> 1a. One area of confusion with component column was the notion of a  
> component being constructed from a set of other components,  
> specifically the network component.  As shown in the latest  
> spreadsheet,  the wireless sensor domain may view subnets as a  
> substrate component. There was also input to this list suggesting  
> that a network could be spatially separated for isolated  
> experiments, which may also support treating the network, and other  
> scenarios where a group of components, is itself treated as a  
> component. I would like the near term focus be to build consensus  
> on what we mean by component and that we have a complete list in  
> Column A. Although other columns in the spreadsheet may raise  
> questions, I would like to suggest an approach to get the list of  
> components agreed upon. As it currently stands, component and  
> substrate is somewhat blurred. A distinction may be that anything  
> which has a resource available for a GENI researcher to build a  
> slice from should be considered a component.
>
> 1b. There was some discussion on links, are these resources of a  
> "network" component or should we create a separate link component?
>
> 1c. I believe "sliceable" is a bad term for a couple of reasons,  
> one is that the term slice is used in GENI to refer to a specific  
> researchers collection of GENI resources, and each piece of a  
> resource is called a sliver. Instead of "sliceable", I will start  
> using dividable (assuming no objection or other suggestions). I  
> also believe that dividable could be redundant with resource, since  
> a resource is ideally something that can be shared across many  
> experiments. If in-fact, a resource is not dividable, it may be an  
> exception and not the rule. So, in future versions of this  
> spreadsheet, the dividable column may be deleted.
>
> 2. The concept of measurement and how it affects our work in the  
> substrate-wg, is not presently addressed in the spreadsheet,  
> however it probably should be included. Currently, I can identify  
> three areas where measurement distinctions may be drawn; GIMS as a  
> measurement service, for use in GENI operations and management, and  
> the dependence of external test equipment on substrate components/
> architecture. There was earlier discussion on measurements for  
> cross-layer networking, but I believe this could be addressed in  
> the following discussion on control plane.
>
> 3. The GENI narrow waist control and operations management entities  
> are outside the scope of research, and are essential in ensuring a  
> safe and robust GENI environment. Furthermore, control and  
> management research will not be allowed to compromise this  
> essential operation. However, there is significant interest in  
> using GENI for research on control and management of next  
> generation networks. The research elements of control and  
> management probably should fall into the substrate-wg activities.  
> From the perspective of identifying components and resources, how  
> should we position these network functions?
>
> 4. A comment was made that the current substrate-component-resource  
> hierarchy implied by the worksheet may not be adequate. We are not  
> constrained by a column count, so we should do whatever makes the  
> most sense. Hopefully the answer to this will evolve as we populate  
> the worksheet. To reiterate my previous suggestion, I would like to  
> see the wg focus on column A (components) first, and we can build  
> from that base.
>
> I believe this captures the discussions thus far, if I have omitted  
> or missed on the interpretation, please speak up. Attached is the  
> latest version of the spreadsheet. What is missing, confusing,  
> wrong? Do we have wireless covered? What about a wireless subnet  
> distinction from wireless sensor subnets?
>
> Thanks,
> John
> <Substrate WG - 06Nov07.xls>
> <mime-attachment.txt>

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

[Deniz Gurkan]

John and all,

1. on component definition:
1a. I agree with "A distinction may be that anything which has a resource available for a GENI researcher to build a slice from should be considered a component." In that context, I think any physical equipment used for monitoring & measuring purposes should be a component too. The measurements will also be part of the resources shared by GENI users. For example, a sensor network integrated into GENI will deliver functional data from its sensors for the process and experimental data measurements for its researchers. In the future, the GENI network might provide these two in an integrated manner - almost like a health monitoring of its own.

2. I think, the concept of "the dependence of external test equipment on substrate components/ architecture" for the measurement equipment makes it a component. Even in the service level with GIMS, measurement equipment will be a resource for the researchers to slice (where possible, maybe with time shifts or functions). Also, researchers need to have access to this resource to update their experiments on-the-fly. If the network is sliced for different experiments, I would imagine some common measurement equipment will also be sliced to measure what is being experimented. Unless the application at the end points will be the main measurement resource for the researchers.. I am not sure if I am on the right track here..

4. Following from my argument above, I think every general component item should have a row added to identify what can be measured with current technology. If there is a way to integrate and build the substrate from scratch with measurement capabilities, I think we need to consider them in the beginning.

The access to these instruments can be an integral part of the design phase instead of patching them on later. On the other hand, integrating measurement at a high granularity might not be possible at the current level of technology for an immediate GENI demonstration. But anything installed will help prove the point of a dividable research experimentation network.

Deniz

John Jacob-2 wrote:

All,

Thank you for the recent discussions on this mailing list, it has been
very helpful and we (GPO) are pleased by the level of activity.  Below
is a list of comments and questions I believe summarizes the discussion
to date.

1. We need consensus on definitions for all column headings in the excel
spreadsheet. The two which seem to generate the most discussion are
component and sliceable.

1a. One area of confusion with component column was the notion of a
component being constructed from a set of other components, specifically
the network component.  As shown in the latest spreadsheet,  the
wireless sensor domain may view subnets as a substrate component. There
was also input to this list suggesting that a network could be spatially
separated for isolated experiments, which may also support treating the
network, and other scenarios where a group of components, is itself
treated as a component. I would like the near term focus be to build
consensus on what we mean by component and that we have a complete list
in Column A. Although other columns in the spreadsheet may raise
questions, I would like to suggest an approach to get the list of
components agreed upon. As it currently stands, component and substrate
is somewhat blurred. A distinction may be that anything which has a
resource available for a GENI researcher to build a slice from should be
considered a component.

1b. There was some discussion on links, are these resources of a
"network" component or should we create a separate link component?

1c. I believe "sliceable" is a bad term for a couple of reasons, one is
that the term slice is used in GENI to refer to a specific researchers
collection of GENI resources, and each piece of a resource is called a
sliver. Instead of "sliceable", I will start using dividable (assuming
no objection or other suggestions). I also believe that dividable could
be redundant with resource, since a resource is ideally something that
can be shared across many experiments. If in-fact, a resource is not
dividable, it may be an exception and not the rule. So, in future
versions of this spreadsheet, the dividable column may be deleted.

2. The concept of measurement and how it affects our work in the
substrate-wg, is not presently addressed in the spreadsheet, however it
probably should be included. Currently, I can identify three areas where
measurement distinctions may be drawn; GIMS as a measurement service,
for use in GENI operations and management, and the dependence of
external test equipment on substrate components/architecture. There was
earlier discussion on measurements for cross-layer networking, but I
believe this could be addressed in the following discussion on control
plane.

3. The GENI narrow waist control and operations management entities are
outside the scope of research, and are essential in ensuring a safe and
robust GENI environment. Furthermore, control and management research
will not be allowed to compromise this essential operation. However,
there is significant interest in using GENI for research on control and
management of next generation networks. The research elements of control
and management probably should fall into the substrate-wg activities.
 From the perspective of identifying components and resources, how
should we position these network functions?

4. A comment was made that the current substrate-component-resource
hierarchy implied by the worksheet may not be adequate. We are not
constrained by a column count, so we should do whatever makes the most
sense. Hopefully the answer to this will evolve as we populate the
worksheet. To reiterate my previous suggestion, I would like to see the
wg focus on column A (components) first, and we can build from that base.

I believe this captures the discussions thus far, if I have omitted or
missed on the interpretation, please speak up. Attached is the latest
version of the spreadsheet. What is missing, confusing, wrong? Do we
have wireless covered? What about a wireless subnet distinction from
wireless sensor subnets?

Thanks,
John

 
_______________________________________________
substrate-wg mailing list
[e-mail]
http://lists.geni.net/mailman/listinfo/substrate-wg

[Peter Steenkiste]

Hello John:
This helps, thanks.  It looks like you are saying that a component can
be a collection of other components (possibly with resources added),
which make sense to me. It may be useful to make this explicit in the table.

I have taken a shot at adding rows for wireless.  Here is a bit of
background:

"Wireless nodes": I have somewhat arbitrarily divided them in regular
wireless nodes that use fairly traditional wireless interfaces for a
handful of standards  (offer limited flexibility at the PHY and MAC
layer) and software radio nodes.  Obviously there is a spectrum here.  
Also: nodes can have multiple radios.   We could also add sensors to the
wireless nodes.

"Wireless networks": Again there is spectrum here.  I have put them in
two classes:
- In the wild testbeds: highly realistic but most aspects of the testbed
cannot be controller.  Can be big.  We would probably need a variety of
them, capturing different environments (residential, vehicular, urban,
rural, ...)
- Controlled wireless testbeds: provide a high level of control over
node placement (wide range of densities, degrees of mobility,  etc.) and
transmission medium.  Ideally, they would offer some degree of
repeatability as well, and they would support a mix of wireless
technologies (radios).  There are many ways of achieving this, e.g.
testbeds in controlled physical environments, emulation at the PHY level
, emulation at the packet level, etc.  Scale will usually be limited in
some way.

There are other types of testbed for wireless but their focus is purely
wireless, so they do not seem relevant to GENI.

There is obviously a limit to how much detail you can put in a table.

Peter




John Jacob wrote:

> All,
>
> Thank you for the recent discussions on this mailing list, it has been
> very helpful and we (GPO) are pleased by the level of activity.  Below
> is a list of comments and questions I believe summarizes the
> discussion to date.
>
> 1. We need consensus on definitions for all column headings in the
> excel spreadsheet. The two which seem to generate the most discussion
> are component and sliceable.
>
> 1a. One area of confusion with component column was the notion of a
> component being constructed from a set of other components,
> specifically the network component.  As shown in the latest
> spreadsheet,  the wireless sensor domain may view subnets as a
> substrate component. There was also input to this list suggesting that
> a network could be spatially separated for isolated experiments, which
> may also support treating the network, and other scenarios where a
> group of components, is itself treated as a component. I would like
> the near term focus be to build consensus on what we mean by component
> and that we have a complete list in Column A. Although other columns
> in the spreadsheet may raise questions, I would like to suggest an
> approach to get the list of components agreed upon. As it currently
> stands, component and substrate is somewhat blurred. A distinction may
> be that anything which has a resource available for a GENI researcher
> to build a slice from should be considered a component.
>
> 1b. There was some discussion on links, are these resources of a
> "network" component or should we create a separate link component?
>
> 1c. I believe "sliceable" is a bad term for a couple of reasons, one
> is that the term slice is used in GENI to refer to a specific
> researchers collection of GENI resources, and each piece of a resource
> is called a sliver. Instead of "sliceable", I will start using
> dividable (assuming no objection or other suggestions). I also believe
> that dividable could be redundant with resource, since a resource is
> ideally something that can be shared across many experiments. If
> in-fact, a resource is not dividable, it may be an exception and not
> the rule. So, in future versions of this spreadsheet, the dividable
> column may be deleted.
>
> 2. The concept of measurement and how it affects our work in the
> substrate-wg, is not presently addressed in the spreadsheet, however
> it probably should be included. Currently, I can identify three areas
> where measurement distinctions may be drawn; GIMS as a measurement
> service, for use in GENI operations and management, and the dependence
> of external test equipment on substrate components/architecture. There
> was earlier discussion on measurements for cross-layer networking, but
> I believe this could be addressed in the following discussion on
> control plane.
>
> 3. The GENI narrow waist control and operations management entities
> are outside the scope of research, and are essential in ensuring a
> safe and robust GENI environment. Furthermore, control and management
> research will not be allowed to compromise this essential operation.
> However, there is significant interest in using GENI for research on
> control and management of next generation networks. The research
> elements of control and management probably should fall into the
> substrate-wg activities. From the perspective of identifying
> components and resources, how should we position these network functions?
>
> 4. A comment was made that the current substrate-component-resource
> hierarchy implied by the worksheet may not be adequate. We are not
> constrained by a column count, so we should do whatever makes the most
> sense. Hopefully the answer to this will evolve as we populate the
> worksheet. To reiterate my previous suggestion, I would like to see
> the wg focus on column A (components) first, and we can build from
> that base.
>
> I believe this captures the discussions thus far, if I have omitted or
> missed on the interpretation, please speak up. Attached is the latest
> version of the spreadsheet. What is missing, confusing, wrong? Do we
> have wireless covered? What about a wireless subnet distinction from
> wireless sensor subnets?
>
> Thanks,
> John
> ------------------------------------------------------------------------
>
> This body part will be downloaded on demand.

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

[Hongwei Zhang]

Hi Peter and All,

> We could also add sensors to the wireless nodes.

This is an interesting point: perhaps we should start identifying
component hierarchy so that we can have a clear, simple component
architecture. For instance, we may consolidate the current "wireless
node" and "wireless sensor node" so that a "wireless sensor node" may be
defined as "a wireless node + sensor(s)"; similar approaches may carry
over to other special types of "wireless nodes" and aggregate components
(e.g., testbeds) of wireless nodes.

Hongwei



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

[Aaron Falk]

catching up...

On Nov 11, 2007, at 8:35 PM, Hongwei Zhang wrote:

>> We could also add sensors to the wireless nodes.
>
> This is an interesting point: perhaps we should start identifying
> component hierarchy so that we can have a clear, simple component
> architecture. For instance, we may consolidate the current "wireless
> node" and "wireless sensor node" so that a "wireless sensor node"  
> may be
> defined as "a wireless node + sensor(s)"; similar approaches may carry
> over to other special types of "wireless nodes" and aggregate  
> components
> (e.g., testbeds) of wireless nodes.

FWIW, I find this suggestion very appealing.  I think some folks use  
'wireless sensor nodes' as shorthand for low-power highly-programmable  
radios but there are likely other folks who find the sensing  
capabilities of greater interest and of course those those who are  
interested in working with both aspects concurrently.

--aaron

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