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