minutes from this AM's meeting

Jay Lepreau chair
Jeff Chase chair (absent)

Review the agenda
(paste in the agenda from the ML here)

1) Documents that have been produced so far are the jumping off point.
2) What do we think about dividing work between us and other wgs?

What are the services and features that we think GENI should be providing to experimenters and what priority do we want?
How hard do we think it is in cost and time to produce this?
Where can we steal models, code, etc.?

Two suggestions:
1) note taker (Phil Roberts - Motorola)
2) sign up sheets

Process (Aaron Falk - GENI lead system engineer)
Drawing on his experience in the IETF for organizing the activities of the GENI working group.  Aaron wrote a paper
on the GENI working group process (available on the GENI site at http://www.geni.net/docs/geni-wgs-20070920.pdf

Project is at a stage where we are trying to define what GENI is actually going to be.  Each WG will have a staff
of GENI system engineers available to it.  The project office will be adminstering prototyping awards over the next
few months.  The charter for this group is using the experimental work flow working group.  What does the group want in
terms of services.  Working on some use cases for various experiments.  The outcome for that work should be a list of
services, what exists, what needs to be built, what are the critical items, and what causes the most worry.  Expect the
group to ask questions and we'd like to see a dialog on that.

If you are going to participate in this work, do the background reading.  Use that as a starting point.  But it doesn't
mean the design decisions are not open to change.  The WGs are to drive the discussion.  The staff SEs are responsible
for authoring the key documents coming out of the working group.  People can author technical contributions/white papers.

Q: how does this intersect with other working groups.
A: all the groups have points of overlap.  We will need to coordinate, identify what they are and sharing the lists with
the other groups.

Q: when will the SEs be available?
A: GPO will have the money to hire them in early 08.  Hopefully they will be on board by February.

Back to Jay

The architecture group worried about interfaces and APIs.  The services wg worried about ....
The two documents (in the agenda list).  Rick from HP was on that group.  The operations group is meeting in parallel with
us now.  One way to cut the division is that we are worried about services delivered to the research, operations would
be worried about services to GENI itself,  OPTIN worries about services delivered to the end user.  There is a meta-question:
do you want a lot of work?  or do we want to be shedding load?
Aaron: a triage approach, take the stuff that is not in some other groups scope.  Some groups may come back and request a
particular piece of work from some other working group.  Most important question initially is, what does GENI need to provide
to support the researcher.

Jay: there are a lot of services that are shared and for any reasonable implementation will be sharing this infrastructure.
Aaron: rather than cross things off the list, let's order the list so the items aren't lost.  Ordered according to
priorities for this working group.

proposals:
move security architecture to the bottom, because it's in another group's name
experiments should be moved up because that's what we do
operations support should be moved down
edge cluster hardware/software is probably included in the charter of the substrate working group
storage sounds like us

Here's a shot:
experiment
comms substrate
storage
resource allocation
Q: (Aaron) what is communications substrate
A: to control GENI for O&M and experiment workload control
Q: (Jerry Sobieski) where does GENI end and the user's environment/researchers environment begin?  If you want to look at this in a more
generic fashion, there are a set of resources.  Some of it may have to do with network resources.  There are a number of
different ways of looking at the same resource allocation problem.  If there is another group that is going to define
the services, having some kind of bound to what GENI is going to be able to manage.  For instance, if you have a researcher
who wants to create and deploy a new mail system, how would you set that up in way.  But if you try to ask what services
the question has to be what capabilities does GENI actually have control over.
A: (Jay) my take on resource allocation is that historically it's on providing resources, and the experimenter wants some
resources, there is a slice embedding resource on top that goes around and allows the resources; there is also a policy
aspect to answer the who, etc.
comment: (Ellen Zegura) I'm the cochair of the GENI science council (triangle, GSC, GPO, NSF).  GPO responsibility is the design
of the facility.  GSC responsiblity is to articulate a research agenda.  People are coming from such diverse backgrounds.
Is it possible to say something to get something of a level playing field.  Think about this as a facility for experiments.
The facility will come with a set of services for experiments.  Some researchers may want to experiment with services.  The
experiment duration will run for a long time.  Where GENI ends are what is the set of services that are available to all
experimenters.  It is the baseline set of services.
(Ellen): the substrate term shouldn't be used as its just too confusing
(Ellen): experiments may be very short or very long in durations
(Jerry): as the researchers want to set up some novel technology, you want to do that in a way that it doesn't affect
researchers doing their own thing.  How many of these services - how can we delineate what GENI provides and what the
researchers need to provide themselves?
(Jay): seems like a reasonable question.  Tom Anderson has written a paper about it.  If we don't commit to doing it, it
won't get done in a long time.
(Ellen): there is going to have to be as part of what this working group will do - there is some set of tools that show
me what is available. So, what can I get?  If I need more storage, for example, than what I can get, I need to go somewhere
else.
(Aaron): one way to look at GENI is that it's a bunch of facilities that researchers can go put things on.  Another way is
that it is a control plane to allow researchers to discover what is out there.  Construct experimental code and what
people can put out there.
There is the narrow waist working group that is responsible for this control plane where every piece of work in GENI can
express what it has and express requests in a controlled manner.  It's another level that takes those building blocks and
define how services can make use of those.
(Aaron): resource discovery needed, services on joining (either as a contributor of resources or a researcher), testing
for validation, debugging tools, data collection tools
(Aaron): all of these are part of the workflow that we need to specify
(Ted): we seem to be really stuck on getting this on machines, there is another level: I'd like to do an email service
experiment and by the way I'd like to have DNS in the experiment also.  If your experiment is on mail services the needs
will be different than someone who wants to do experiments on switched lambdas.  That is the place we start from.
(Ted): the other thing we should think bigger about, a couple of people would like to see what is available, if I set up
an experiment on the internet, I don't do that;  there may be more on GENI that will fit on the screen
(Jay): our agenda item will be trying to figure out what is in the scope
(Jay):  this is an open process like the IETF.  The expectation is that a substantial amount of this will be done via
email.
(Jay):
legacy support- support for IPv4?  Some of this is superseded by the user opt-in group.  Architecture is how you enteract
with that.
legacy - things like virtualized http, virtualized DNS, client opt-in, distributed dynamic NAT, virtualized BGP
The first two are within our scope, but maybe not, maybe it is more opt-in.
(Rick Mageren): what do you do when you are designing these things, and what is broke?
(Rick): what is broke is that everyone wants to run his experiments on port 80.
(Rick): opt-in we punt, dynamic NAT is yuk
(Aaron): re: client opt-in, the end user opt-in is chartered to look specifically at what they are doing
(Jay): it is useful to look at the list (slide 4) and in some cases they listed reqs and in other cases they listed design

1. experimenter support
2. communication
3. resource allocation
4. storage
5. measurement
(time service)
(location - physical and topological)

(Aaron): there is clearly a support of overlap between measurement here and in substrate working group (where you need
h/w support), but this group should take the lead

(Jay): at what level do you instrument the system, there are those that hold you instrument at the phy layer as it's the
only place to get the info.  Others hold it isn't abstract enough.  So how do you tell if the link layer is tough.  So you
need services to all the different stacks and layers to allow folks to tap into that.

(Jon Turner) have done that and you can give the experimenter exactly what he needs.  It is difficult to talk about this
in the abstract.  You can build platforms where measurements are done in the substrate and the control infrastructure of
the experiment can get you what you need.  The experiment itself will have to do its own measurement as well.  May still
have h/w measurement mechanisms but it is something you can do and in a way that gives isolated views to the experimenters.
(Aaron): there are some interesting and hard issues that need to be solved.  If GENI has a measurement infrastructure (say
a queriable database of measurments that are available), then there may be a need for quality assurance.  Things like
time synchronization between different components, there could be difficult requirements.
(Jay): add time service
(Kristin): do we have to decide this for every piece of GENI uniformly from the very beginning.  If I start out heavily
instrumented, then maybe I can move that into other parts of GENI over time.
(Jay) we have this Internet that is very tough to measure.  Many researchers don't want to make this mistake (can argue
about that), and to be as aggressive as possible up front as you're going to lose measureability as scale and complexity
grows
(Aaron): we are at risk of ratholing on this topic
(Jay): here's an example of a user service: a user wants to build an auditable network service.  This group might impinge
on that question.
(Jay): are there other services that people can think of: experiment support.  One of things is that the kind of stuff
our project does is what GENI is going to provide (bundling up an experiment and giving it to someone else and they can
recreate it 6 months later).  
(Aaron): does location service rise to the level of some of the other?
(Jay) for mobile nodes
(Aaron): so you can know the location of every hop.
(Ted): I'm worried.  This slide seemed pretty full.
(Aaron): I'm looking for things that are important and hard.  We are looking for a comprehensive story and where there
are risks in the design.  If a GENI wide location service is hard, then we should put it on the list.
(Jay): resources should have their geographic location
(Mark Gardner VaTech): there are two types of location - higher level service so you can correlate services with users, there is
another - how to query the growing infrastructure as network distance.  When I'm running an experiment it may be useful to
know.
(Jerry): isn't really a topology question
(Mark): yes, but it is important to know when logically adjacent and physically adjacent don't correspond
(Jerry): maybe we need some kind of topology service, not just a physical location service
(?): location is as critical as asking what is your ip address?  Location can be part of the services.
(Jay): do we want to provide a service that shows you visibility of network tunnels, maybe this is lots and lots of leverage
for experimenters.
(Aaron): no decisions today, but let's add location both topological and physical to the requirements list
(Ted): I represent the "however" category
(Ted): the space you are defining often is dependent on the experiment, the way a person defines you depends on the question
(Jay): what about address management?
(Aaron): if you have multiple people doing IP based experiments on GENI and connecting to the Internet, they will want
addresses and AS space and those will need to be advertised out.  There will have to be coordination with the points of
contact with the global internet.  That makes my head hurt.  If we are going to commit to that kind of experimentation, then
we need to figure out how those addresses are pooled and allocated, it becomes a limited resource in GENI that needs
to be administered.  I'm specifically talking about addresses and reachability.
(Jerry): it's a very good observation but what if we did something more general than that, what about lower layer that
requires a completely different kind of addressing (at the lower layers), can we define something that allows GENI
experiments to reserve namespaces
(Aaron): don't know enough about what that looks like
(jerry): I can see experiments creating a new kind of packet format and we need some way to allow folks to use those
resources
(Jay) so working on something like rendezvous mechanisms.  If it's just a ..., we have that problem in any scale.
(Aaron) for an experimental infrastructure, having a parameter allocation service is not that important, when you get to
a standard then you need something like that

(Jay): what about failover.  One of the key cornerstones - you get real users and you get research products, so research
products are going to fail, so the experimental service needs to failover to a less experimental service and quickly to
keep real users happy.  It is arbitrarily hard and you can set the latency goal as arbitrarily small.  I'm not sure anyone
has really thought much about it.  Some of it may come in our scope.
(Jon): I'm finding a hard time imagining this.  I'm going to set up an experimental service that does something no one
does and you are getting into GENI a reliable service that backs it up.
(Jay): suppose you are sending A to B, and we're talking about failover to a more reliable service.  If I use some P2P
service and it fails, then can I failover to ftp.
(Ellen): that's impossible
(Jay): everyone is shaking their head, is there no mechanism we could imageine that more than one service could exploit.
(Ron?): you want to build a lower level reliable transport mechanism.
(Ellen): I think your conception of what these experiments is going to be like is way off.  I think it's just wrong.  There
might be an experiment that modifies the packet format, and what does it mean to fall back to something different.  It
is just not going to make any sense in a common connectivity way.
(?): what about intentional failover.  I want to make my service reliable, how can I create an intentional failure to make
sure the application woks
(Shane): back to issue of failover and instrumentation and it could take place all the way through the stack; if there is
a failover mechanism then maybe it's a collection of mechanisms or policies that an experimenter can apply at different
points in the stack
(Mark Garnder): there are given things that you want to have established in the network.  Some services are going to want
some guarantees and others are going to provide whatever it is that they need
(Ellen): the heart of your concern, are there ways in which we can make it more likely that users will find it appealing
to use the experiments on GENI, and your approach is that if something fails, the users get something else; another approach
is to set it up so that experimenters can harden their design before they are let into the wild.  Not trying to do it
inline.
(aAron): it would be easily to evaluate if you wrote down what you wanted

(Jay): it could be that there are many classes.  Maybe there is a modest number of classes of services for which a modest
number of failover mechanisms for which a number of libraries could be built to have fast failover.
I think it's going to be hard to get people to work harder
(Aaron): are you failing over to something operating on GENI or on the global internet
(Jay): both
(Chip): I'd be curious if there were a list.  If people in the room people had a choice of exactly one, what would it look
like.
(Miguel?): I want to go back to use cases at the beginning - people are going to be experimenting from web services all the way
down to Ethernet, each of us has needs of a different kind from the neetwork.  Going back to the use cases will allow us
to come down with a set of requirements from the network.  Perhaps I am doing BGP protocols and I would like to turn off
regular BGP protocols.  Basing ourselves into use cases and then what I'd like the network to provide to me.
(Ted): services go from experimental to relied upon.  The goal of making those reliable is useful.  I'm not sure it's
something you can make into a library.
(Jon): the failover only makes sense if the service is just the functional equivalent of IP.  I'm not sure that that is
interesting enough to invest money in.  We are talking at this on a very abstract level and it's hard to attach much
meaning without very much concrete in the way of examples available.
(ron?): I'd like to see the measurements that can be done in real time services
(Jerry): reliability.  There is a place for a measure of reliability.  If you are going to go out and ask for resources from
the infrastructure.  There are some you want to be reliable and some more experimental.  You want the control plane highly
reliable but perhaps the data plane isn't that reliable.
(Ellen): last 90 minutes is grappling with things that may or may not belong in the working group and what services.  The
most important thing the working group can do is to make it easy to run an experiment.  Please don't underestimate the
complexity of running distributed experiments.

(Jay): future discussion item, the extent to which we make the kind of services that are aligned.  How do we get a richer
support with the workbench stuff that we are talking about.

(Chip): does anyone have any high level goals other than that?  making it easy to run experiments.

(Jay): Monty made a distinction between experiments and services.

(Suzi): easy to run and data;  there should be an easy procedure for a first time experimenter to determine how to run
an experiment.  And you have to be able to get data out the other end.  Even if it's easy to use but you can't figure
out what happened you're not going to come back.

(Jay): data storage in a canonical way in shared repositories.
(Jay): so if you can only choose one which one is it
looking at list from page 9, there are 8 +1 - measurement

storage: 1

(Jon): these aren't meaningful questions
(Mark): if you don't have several of these you can't ask meaning questions
(Chip): not so much this list, but "Making experiments easy"
(Steve): which things you can't build yourself, that's what you need
(Steve): is repeatability a key goal of GENI, the ability to repeat your experiments
(Jim Williams): a spy from operations group.  It seems to me that a critical part of this process is having a clean
well-defined interface between the two groups.  Maybe it is written down somewhere that I haven't read yet.
Measurement is an example of that, a base set of measurement that is provided to everyone.  
(jay): maybe we want to add domain specific aids to experiments.  Maybe a security experimenters toolkit.  You can imagine
someone investing in this stuff.
(Steve): toolkits for specific communities.  We have built this to help with security experiments specifically.  There is
some point where you organize some tools for particular subcommunities (routing folks, virtual worlds, etc.).  In what
order do you want to build things.

(Aaron): down to 10 minutes, the group should talk about what next
(Jay): let's skip to wg deliverables, priorities, schedules (near term is before next meeting and medium term is through end
of 08)
(Aaron): charter has a couple of specifics about doing some use cases, this group should be able to do that without a
systems engineer.  This would help move the discussion forward.  Find some volunteers to hold the pen.
(Jay): we have some start but it's very high level.
(Aaron): perhaps you could take a few and determine what the services are that are needed for those use cases
(Jay): what about an incentive structure for contributing resources
(Aaron): in the transition slides there is the discussion of some kind of credit distribution services where people could
get some preferential access to the GENI pool of resources.  It's not clear that has been scrutinized enough to say it's
something we want to do.  It's not nearly as important as starting to look at the use cases and what kind of requirements
fall out of that.
(Aaron): it would be helpful to flush out a taxonomy of services that could be populated
(Jay): near term - use case scenario document, taxonomy and list of services and prioritization, defining scope is part and
partial of that.  What else?
(Aaron): might be good to look for some volunteers.  It is a community supported activity so we are looking for folks in
the working group to do the work
(Henry): in planetlab a lot of people provided services to support experiments, does the model include allowing people
to provide services on top of the GENI services?
(Jay): yes
(Henry): are we then trying to define a minimum set of services that GENI is providing
(Jay): not minimum, minimum.  If we rely on volunteers it doesn't necessarily get things
(Aaron): let's take discussion to scope of working group on mailing list, now volunteers to sketch out some use case
scenarios
(Peter Steenkist from CMU) volunteering to do usage scenarios for experiment control
(Aaron): someone to take a first cut at list of services
(Ram Dantu) from UT and Jerry Sobieski) volunteer for list of services
(Ted): is each wg going to come up with its own list of use cases?  seems dangerous
(Aaron): this group should represent what the experimenters work.
(Jay): maybe someone different with a complementary set of requirements, non wireless, non security
(Steve Schwab): will help with a security orientated scenario.








 






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