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

File GENI-GIMS-doc-review-jun09.txt, 8.7 KB (added by Vic Thomas, 10 years ago)

Notes from review of the "Requirements and Specifications for the Instrumentation and Measurement Systems for GENI" document

Line 
1Paul Barford, U Wisconsin
2Caroline Lai, Columbia
3Michael Wang, Columbia
4Franz Fidler, Columbia
5Steve Schwab, Sparta
6Christopher Small, Indiana U
7Christopher Small, BBN
8Chris Tracy, Mid Atlantic Crossroads
9Peter O'Neill, Mid Atlantic Crossroads
10Tiantong Yu, Colgate
11Joel Sommers, Colgate
12Mark Crovella, Boston University
13Vic Thomas, BBN/GPO
14Heidi Dempsey, BBN/GPO
15
16Joel:
17- Basic Objectives of Document are to describe purpose and design of
18system being built (i.e., system for passive measurement capability
19within GENI)
20- Note that document is not complete at current time;  feedback is still
21being solicited and some aspects are not finalized.
22
23Franz: There may be some opportunity for use of GIMS in the real time
24embedded measurements project -- this will become clear over time.
25
26Section 1. 
27---------
28No comments.
29
30Section 2. 
31---------
32
33Joel: focus is on passive packet capture, at layer 3 and
34above.  Additionally some basic transformations on captured traffic
35(eg, anonymization, filtering, sampling).
36
37Paul: Active measurements were part of the original GENI proposal, but
38were removed due to budget restrictions that were imposed after award.
39Most of the upper layers of the system being built are amenable to
40active measurement but the lower layers (ie, sensor level) don't include
41active measurement.
42
43Heidi: Clarification - this is not an architecture for all of GENI
44measurement, rather a design for the GIMS system, correct?
45
46Paul: Correct.  There was an earlier pre-GPO document that laid out a
47more complete architecture that may be of value.
48
49Christopher Small (Indiana):  Did not see anything that discusses where
50packet transformation functions live.
51
52Joel: Those are defined to be on measurement nodes currently.
53
54Christopher Small (Indiana): Will there be an ability to do
55transformations on mirroring device -- will software support doing
56sampling after packet capture?
57
58Joel: I think the answer is yes.
59
60Section 3.
61---------
62
63Steve Schwab: Control Interface Interaction (3.5.1): right now the
64interface is underspecified.  Are you planning on using any of the GENI
65interfaces from the control framework and in so doing pick up any of the
66GENI security features?
67
68Joel: Hopefully we will be able to take advantage of some of those
69capabilities from ProtoGENI.
70
71Steve: So the integration task (integrating into ProtoGENI) will address
72that.
73
74Paul: Mike Blodgett is working closely with ProtoGENI.   Note that
75ProtoGENI is rapidly evolving and fluid.   We will take anything from
76ProtoGENI that offers us substantial capability over what we can build
77ourselves.  One of our design goals is to be flexible w.r.t. integrating
78multiple sensors and even control frameworks.   We will be eager to add
79components including security that will help us.
80
81Steve: We can close the loop on this after the call.
82
83Paul: Our current security model is very simple.
84
85Peter O'Neill: What sort of expectations are there for this API to speak
86to other aggregate managers?  Is there something that we (Cluster B)
87need to do?
88
89Paul: While remaining flexible, we have not given specific thought to
90integrating with other control framworks or aggregate manangers other
91than ProtoGENI at this point.  We are eager to start those discussions.
92
93Vic: How do experimenters discover measurement sensors?
94
95Joel: The information about what is available at this point will be
96statically configured into ProtoGENI.  If there is a way to make this
97dynamic and subject to query later on, that will be desirable, but
98currently this is static.  The specifics of how that information is
99presented to the user is not yet defined.
100
101Paul: Actually this something that we've been thinking about a good
102deal.  In the demo you will see a UI that has a map that represents
103where the nodes are that are available from GIMS.  At this point that
104map is static.  In subsequent versions -- where the measurement
105aggregate managers is the focus -- we've talked about developing a
106publish/subscribe capability to the aggregate manager, where sensors can
107make their presence known to the AM.   Pub/sub could be a year two or
108even beyond that capability.
109
110Vic: Even virtual sensors that exist within virtual machines, eg, a
111virtual CPU measurement sensor?
112
113Paul: That goes beyond our objective for the project, which focuses on
114capturing packets.  I can see how we could expand to that capability,
115but it's not within our current parameters.
116
117Chris Tracy: Regarding layer 3 vs layer 2.  Section 2 says limit of
118scope is layer 3 but this section discusses demultiplexing via VLAN
119tags.  I can see that the system needs to be VLAN aware.
120
121Joel: From the perspective of the experimenter, anything below layer 3
122is invisible.  For example the experimenter doesn't know the VLAN tag on
123the slice the user is using.  But system needs to know the VLAN tags to
124demultiplex.
125
126Chris: This might be good to clarify in the document.
127
128Heidi: It might be fine for an experimenter to not be cognizant of the
129VLAN tags, but that's needed for the bigger picture -- system designers
130and debuggers need to look at things like VLAN tags to cross-reference
131with what they are seeing with other tools.
132
133Section 4.
134----------
135
136Christopher Small (Indiana):  One suggestion is that there be specific
137provision for connectivity to the data repository.  At some sites (I2)
138there may not be connectivity to the S3 servers.
139
140Joel: Good point, some other mechanism would need to be used.
141
142Heidi: Still a little bit uneasy about security and privacy and
143interfaces to data archive.  Not sure at what point we actually deal
144with security and privacy.
145
146Steve Schwab: Kinds of questions about security and privacy currently
147being discussed with GMOC (w.r.t repository) are identical to these
148questions.  Maybe we can talk more generally at GEC5 about whole-system
149security and privacy.
150
151Steve: Encrypting everything in S3 would provide security.
152
153Heidi: OK. Just not clear from current document where it's being handled.
154
155Paul: Not wedded to Amazon S3.  Just an example.  But given that security
156is in flux we are open to discussion.
157
158Heidi: In security and access control, there is a requirement that no
159aspect of data storage will compromise security.
160
161Paul: We are open to a specific change to the requirements here.
162
163Mark: So in the security section there is a strong statement about
164security and privacy but in the storage section there isn't anything
165called out about how that will be implemented.
166
167Joel: Haven't flushed out metadata yet.   It will contain information
168about current experiment that produced data and the measurement system,
169hopefully explaining any anomalies.  This will include any
170transformations that are applied, for example, an anonymization
171function used in data collection will be noted in the metadata.
172
173Section 5.
174---------
175
176Heidi: Are you going to add a pointer to where the WSDL specs are?
177
178Joel: Yes, hopefully by the next GEC those will have jelled.
179
180Heidi: Yes, there will be some interest there.
181
182Franz: Can the user interact directly with this interface?
183
184Joel: Yes.
185
186Franz: The control framework still has to decide if a particular
187resource is available to the user, even if its visible in the interface,
188correct?
189
190Paul: No, there will be a credential for each user that specifies the
191resources available to the user.  The vision is that for any control
192framework there will some flash object recognized by the control
193framework, and given the user's profile the resources available will be
194displayed.  Again, seeking flexibility here in light of flux among
195control frameworks.
196
197Section 6.
198---------
199
200Joel: At this point, the mechanisms to implement the required (security
201and access control) mechanisms are as yet undefined.   We've been more
202focused on getting the lower levels prototypes before fleshing out these
203issues.
204
205Heidi: Not mentioned here are methods for access to logs.  Knowing where
206and where people (say, from GMOC) can access logs would be helpful.
207That's not specific to this project.
208
209Section 7
210---------
211Joel: This section is designed to just give an overview of the tests and
212so is fairly general in nature by design.
213
214??: Will you make it possible for other folks to acquire another copy
215of the sensor to use elsewhere?  If it's code plus software.
216
217Joel: Not clear when that would be possible, but since we are developing
218under the GPL the answer is yes.  Deciding when the s/w is stable enough
219for outside use is not clear.
220
221Heidi: I think the development and test section is great, happy to see
222it in requirements document, hope other projects do the same thing.
223
224Overall
225-------
226
227Heidi: It was interesting to consider how you can compare measurements
228on this project with what other people could get with their own
229measurement tools.  It would be nice if there were a few paragraphs
230explaining what this project uniquely provides -- there is definitely
231value, it just should be laid our more clearly.
232
233
234
235
236
237
238
239
240
241
242
243
244