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.