MeasurementSystem: GENI-GIMS-doc-review-jun09.txt

Paul Barford, U Wisconsin
Caroline Lai, Columbia
Michael Wang, Columbia
Franz Fidler, Columbia
Steve Schwab, Sparta
Christopher Small, Indiana U
Christopher Small, BBN
Chris Tracy, Mid Atlantic Crossroads 
Peter O'Neill, Mid Atlantic Crossroads
Tiantong Yu, Colgate
Joel Sommers, Colgate
Mark Crovella, Boston University
Vic Thomas, BBN/GPO
Heidi Dempsey, BBN/GPO

Joel: 
- Basic Objectives of Document are to describe purpose and design of
system being built (i.e., system for passive measurement capability
within GENI) 
- Note that document is not complete at current time;  feedback is still
being solicited and some aspects are not finalized.

Franz: There may be some opportunity for use of GIMS in the real time
embedded measurements project -- this will become clear over time.

Section 1.  
---------
No comments.

Section 2.  
---------

Joel: focus is on passive packet capture, at layer 3 and
above.  Additionally some basic transformations on captured traffic
(eg, anonymization, filtering, sampling).

Paul: Active measurements were part of the original GENI proposal, but
were removed due to budget restrictions that were imposed after award.
Most of the upper layers of the system being built are amenable to
active measurement but the lower layers (ie, sensor level) don't include
active measurement.

Heidi: Clarification - this is not an architecture for all of GENI
measurement, rather a design for the GIMS system, correct? 

Paul: Correct.  There was an earlier pre-GPO document that laid out a
more complete architecture that may be of value.

Christopher Small (Indiana):  Did not see anything that discusses where
packet transformation functions live.

Joel: Those are defined to be on measurement nodes currently.

Christopher Small (Indiana): Will there be an ability to do
transformations on mirroring device -- will software support doing
sampling after packet capture?

Joel: I think the answer is yes.

Section 3.
---------

Steve Schwab: Control Interface Interaction (3.5.1): right now the
interface is underspecified.  Are you planning on using any of the GENI
interfaces from the control framework and in so doing pick up any of the
GENI security features?

Joel: Hopefully we will be able to take advantage of some of those
capabilities from ProtoGENI.

Steve: So the integration task (integrating into ProtoGENI) will address
that. 

Paul: Mike Blodgett is working closely with ProtoGENI.   Note that
ProtoGENI is rapidly evolving and fluid.   We will take anything from
ProtoGENI that offers us substantial capability over what we can build
ourselves.  One of our design goals is to be flexible w.r.t. integrating
multiple sensors and even control frameworks.   We will be eager to add
components including security that will help us.

Steve: We can close the loop on this after the call.

Paul: Our current security model is very simple.

Peter O'Neill: What sort of expectations are there for this API to speak
to other aggregate managers?  Is there something that we (Cluster B)
need to do?

Paul: While remaining flexible, we have not given specific thought to
integrating with other control framworks or aggregate manangers other
than ProtoGENI at this point.  We are eager to start those discussions.

Vic: How do experimenters discover measurement sensors?

Joel: The information about what is available at this point will be
statically configured into ProtoGENI.  If there is a way to make this
dynamic and subject to query later on, that will be desirable, but
currently this is static.  The specifics of how that information is
presented to the user is not yet defined.

Paul: Actually this something that we've been thinking about a good
deal.  In the demo you will see a UI that has a map that represents
where the nodes are that are available from GIMS.  At this point that
map is static.  In subsequent versions -- where the measurement
aggregate managers is the focus -- we've talked about developing a
publish/subscribe capability to the aggregate manager, where sensors can
make their presence known to the AM.   Pub/sub could be a year two or
even beyond that capability.

Vic: Even virtual sensors that exist within virtual machines, eg, a
virtual CPU measurement sensor?

Paul: That goes beyond our objective for the project, which focuses on
capturing packets.  I can see how we could expand to that capability,
but it's not within our current parameters.

Chris Tracy: Regarding layer 3 vs layer 2.  Section 2 says limit of
scope is layer 3 but this section discusses demultiplexing via VLAN
tags.  I can see that the system needs to be VLAN aware.

Joel: From the perspective of the experimenter, anything below layer 3
is invisible.  For example the experimenter doesn't know the VLAN tag on
the slice the user is using.  But system needs to know the VLAN tags to
demultiplex. 

Chris: This might be good to clarify in the document.

Heidi: It might be fine for an experimenter to not be cognizant of the
VLAN tags, but that's needed for the bigger picture -- system designers
and debuggers need to look at things like VLAN tags to cross-reference
with what they are seeing with other tools.

Section 4.
----------

Christopher Small (Indiana):  One suggestion is that there be specific
provision for connectivity to the data repository.  At some sites (I2)
there may not be connectivity to the S3 servers.

Joel: Good point, some other mechanism would need to be used.

Heidi: Still a little bit uneasy about security and privacy and
interfaces to data archive.  Not sure at what point we actually deal
with security and privacy.

Steve Schwab: Kinds of questions about security and privacy currently
being discussed with GMOC (w.r.t repository) are identical to these
questions.  Maybe we can talk more generally at GEC5 about whole-system
security and privacy.

Steve: Encrypting everything in S3 would provide security.

Heidi: OK. Just not clear from current document where it's being handled.

Paul: Not wedded to Amazon S3.  Just an example.  But given that security
is in flux we are open to discussion.

Heidi: In security and access control, there is a requirement that no
aspect of data storage will compromise security.

Paul: We are open to a specific change to the requirements here.

Mark: So in the security section there is a strong statement about
security and privacy but in the storage section there isn't anything
called out about how that will be implemented.

Joel: Haven't flushed out metadata yet.   It will contain information
about current experiment that produced data and the measurement system,
hopefully explaining any anomalies.  This will include any
transformations that are applied, for example, an anonymization
function used in data collection will be noted in the metadata.

Section 5.
---------

Heidi: Are you going to add a pointer to where the WSDL specs are?

Joel: Yes, hopefully by the next GEC those will have jelled.

Heidi: Yes, there will be some interest there.

Franz: Can the user interact directly with this interface?

Joel: Yes.

Franz: The control framework still has to decide if a particular
resource is available to the user, even if its visible in the interface,
correct? 

Paul: No, there will be a credential for each user that specifies the
resources available to the user.  The vision is that for any control
framework there will some flash object recognized by the control
framework, and given the user's profile the resources available will be
displayed.  Again, seeking flexibility here in light of flux among
control frameworks.

Section 6.
---------

Joel: At this point, the mechanisms to implement the required (security
and access control) mechanisms are as yet undefined.   We've been more
focused on getting the lower levels prototypes before fleshing out these
issues. 

Heidi: Not mentioned here are methods for access to logs.  Knowing where
and where people (say, from GMOC) can access logs would be helpful.
That's not specific to this project.

Section 7
---------
Joel: This section is designed to just give an overview of the tests and
so is fairly general in nature by design.

??: Will you make it possible for other folks to acquire another copy
of the sensor to use elsewhere?  If it's code plus software.

Joel: Not clear when that would be possible, but since we are developing
under the GPL the answer is yes.  Deciding when the s/w is stable enough
for outside use is not clear.

Heidi: I think the development and test section is great, happy to see
it in requirements document, hope other projects do the same thing.

Overall
-------

Heidi: It was interesting to consider how you can compare measurements
on this project with what other people could get with their own
measurement tools.  It would be nice if there were a few paragraphs
explaining what this project uniquely provides -- there is definitely
value, it just should be laid our more clearly.