WG overlap: GIMS

[Michael A. Patton]

One of the things I've been looking at for the OMIS WG is where we
overlap with other WGs.  One particular area that's got both lots of
overlap and is critical and important to GENI is the instrumentation
(GIMS) for experiments.  It seems like these three WGs, at least, all
have a considerable stake in it.  But where the lines are drawn is not
at all clear.

Since one of the goals of the upcoming conference is to work on
cross-WG issues (since all WG sessions are in full plenary and
therefore open to all other WGs), I thought it might be fruitful to
see if we could spur some discussion on how to attack the design and
specification for GIMS.

----------------

I think that getting GIMS right is a hard (and therefore interesting)
problem.  There are lots of issues, and I think some of them cross the
normal boundaries between the WGs.  This leads me to think that first
we may need to decide on the meta-question of how to handle it.

One possible way to get a more consistent overall design would be to
have a sub-group (that would, in essence be a sub-grioup of each of
the WGs) to work on GIMS.  This sub-group would need to have people
from all three WGs and would interact back to each of the full WGs as
needed both for input and review.

Another idea (really just a less organized version of the above, I
suspect) is to have a wiki page common to the 3 WGs (and any others
that think they have a stake) to collect the issues and work out how
the subdivision of the problem will be defined.

If you have any comments on those approaches, or want to suggest some
other alternatives, please do.

----------------

There are a lot of issues that need to be worked out, here are just
some that occur to me...these are short summaries, I could probably
write a lot more on each of them.

I think one of the big issues with GIMS is that with the 20 plus year
expected lifetime, data collection, archiving, and analysis techniques
will evolve considerably and an architecture is needed that can evolve
as well and keep all the required old data available.

Another big one is privacy, anonymity, and other concerns in the
tradeoff between disclosure and secrecy.  This is especially tough as
public perception and even legislation can affect what protections are
needed, and these change over time.  So, again there is a need for a
design that can adjust to changing circumstances.  And, what about
combining data collected under two different sets of privacy
assumptions?

Another issue is avoiding duplication between data collected for
operating the network and for instrumentation of experiments.  There
are several kinds of data that need to be collected for both purposes.
How do we integrate these systems in a way that avoids having to
collect the same information multiple times?

OK, that's a short sample of issues.  Feel free to contribute your
own...

----------------

In summary, I think GIMS is going to be an important part of GENI and
getting its design going soon seems desireable.  So, please contribute
your own input on this.

        -MAP

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

[Deniz Gurkan]

I completely agree with you. We need to take into account of the requirements of all workgroups in the architecture definitions of GIMS and measurement plane in general. A sub-group that communicates with all other WGs on GIMS is a good idea. Maybe this subgroup can belong to the substrate group during the phase when we actually build the physical GENI.

In addition to the data sharing and archiving issues, we need to identify what kinds of measurements will be needed for each potential researcher's agenda. The substrate group may work on identifying what equipment needs to be deployed or initially it will be all possible commercial off-the-shelf instruments. However, each GENI island may have a different set of measurement capabilities. We need to think about how to make this diversity a strength for GENI.

We need to regard each dedicated measurement equipment as a component that needs to have a slice coordination and O&M just like any other component. There may be also some embedded measurements in components. They all need to be accessible by users as a resource. Remote access and configuration of all measurements will be very important to define.

Thanks,
Deniz

Michael A. Patton wrote:

One of the things I've been looking at for the OMIS WG is where we
overlap with other WGs.  One particular area that's got both lots of
overlap and is critical and important to GENI is the instrumentation
(GIMS) for experiments.  It seems like these three WGs, at least, all
have a considerable stake in it.  But where the lines are drawn is not
at all clear.

Since one of the goals of the upcoming conference is to work on
cross-WG issues (since all WG sessions are in full plenary and
therefore open to all other WGs), I thought it might be fruitful to
see if we could spur some discussion on how to attack the design and
specification for GIMS.

----------------

I think that getting GIMS right is a hard (and therefore interesting)
problem.  There are lots of issues, and I think some of them cross the
normal boundaries between the WGs.  This leads me to think that first
we may need to decide on the meta-question of how to handle it.

One possible way to get a more consistent overall design would be to
have a sub-group (that would, in essence be a sub-grioup of each of
the WGs) to work on GIMS.  This sub-group would need to have people
from all three WGs and would interact back to each of the full WGs as
needed both for input and review.

Another idea (really just a less organized version of the above, I
suspect) is to have a wiki page common to the 3 WGs (and any others
that think they have a stake) to collect the issues and work out how
the subdivision of the problem will be defined.

If you have any comments on those approaches, or want to suggest some
other alternatives, please do.

----------------

There are a lot of issues that need to be worked out, here are just
some that occur to me...these are short summaries, I could probably
write a lot more on each of them.

I think one of the big issues with GIMS is that with the 20 plus year
expected lifetime, data collection, archiving, and analysis techniques
will evolve considerably and an architecture is needed that can evolve
as well and keep all the required old data available.

Another big one is privacy, anonymity, and other concerns in the
tradeoff between disclosure and secrecy.  This is especially tough as
public perception and even legislation can affect what protections are
needed, and these change over time.  So, again there is a need for a
design that can adjust to changing circumstances.  And, what about
combining data collected under two different sets of privacy
assumptions?

Another issue is avoiding duplication between data collected for
operating the network and for instrumentation of experiments.  There
are several kinds of data that need to be collected for both purposes.
How do we integrate these systems in a way that avoids having to
collect the same information multiple times?

OK, that's a short sample of issues.  Feel free to contribute your
own...

----------------

In summary, I think GIMS is going to be an important part of GENI and
getting its design going soon seems desireable.  So, please contribute
your own input on this.

        -MAP

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