« Return to Thread: Re: [cwg] questions on RSpecs from GEC2 meeting
Re: [cwg] questions on RSpecs from GEC2 meeting
by McGeer, Rick
::
Rate this Message:
There is very little in a data formats discussion that I, at least, find scary.
Look, Rspecs will be wrong. There will be stuff they omit, stuff they overspecify, and I guarantee in five years we'll look at some chunks of it and say what were we thinking? I also guarantee that Rspec 2.0 will be different from 1.0, since we'll learn things from 1.0. (In general, 2.0's are more complex and therefore worse than 1.0's, but that is life; if we are very wise and lucky we'll zap stuff between 1.0 and 2.0, but more likely we'll be stupid and unfortunate and add stuff). That said, this isn't really all that complicated.
At the end of the day, as an experimenter, what I want to specify is a virtual or physical network, and then ask the GENI facility to go instantiate that network for me. Emulab and PlanetLab both do wonderful jobs at this, so a good way to start is to take an XMLified version of the Emulab ns commands and the PlanetLab XML-RPC interface and ask why doesn't this work? I can think of several enhancements to the unified PlanetLab/Emulab interface:
1. Emulab is almost ideal, since I allocate physical nodes and specify node type, which automatically gives me memory, disk, cpu speed and type. If GENI slices nodes -- and one lesson of PlanetLab is that we should use a hypervisor which offers performance isolation -- then I just want to specify memory, disk, cpu speed and type. Four parameters, and add wildcards. The emulab system of OSIDs and image IDs work just fine.
2. I need to be able to pick specific nodes (a la PlanetLab) or at least network node locations ("give me any node at U Chicago meeting these specs", or "give me any node with an interface matching this netmask and these specs"). For Emulab of course this is irrelevant; PlanetLab lets me pick individual nodes but not resource guarantees on them.
3. This doesn't affect me personally, since like any sensible person I instantiate small networks to run my experiments. Unfortunately, many others (Kubi and the DHT guys) do not share my good taste :-) and instantiate monsters. To make life easier on them (why?) we need hierarchical descriptions. For example, OceanStore really needed clusters at each site to do the signature computations, and so we'll need the ability to specify clusters and instantiate them. That means hierarchical descriptions, and modules.
4. Truly hoggish experiments (like the ones my buddy Joe Mambretti and I kick around) require gobs-o-bandwidth and optical links, so I need to be able to specify links of truly hideous capacity -- 10 Gb/s and above.
5. A call needs to be made -- are we fooling around at layer 1? I haven't the faintest idea about what link characteristics need to be specified here, but Ben Yoo and Keren Bergman probably do.
6. Need to specify layer 2 link characteristics. (Ethernet and parameters, including jumbo and 1522-byte framing, sonet, wifi, fiber channel, etc...
> -----Original Message-----
> From: services-wg-bounces@...
> [mailto:services-wg-bounces@...] On Behalf Of Peter Steenkiste
> Sent: Tuesday, March 04, 2008 6:33 AM
> To: chase@...
> Cc: services-wg@...; control-wg@...
> Subject: Re: [services-wg] [cwg] questions on RSpecs from GEC2 meeting
>
>
> Hello Jeff,
> Your two extremes do look scary. I have always assumed that
> the Rspec would pick an intermediate point in your spectrum:
> if two parties need to exchange some information other than
> the "standard" information in
> the Rspec, they would just be able to do that.
> "Standardizatin" or at
> least rough consensus would be needed if information field
> became widely used.
>
> I think that the issues of time, duty cycle, scheduling unit,
> isolation, etc. are harder. When creating a slice, you will
> need to make sure that these properties of your slivers "line
> up" so you get the right behavior at the slice level. That
> looks like a hard problem. Clearly it will require consensus
> over how to represent this information and what various
> values mean for different substrates. This issue exists
> independent of whether you include the information in the
> Rspec or not.
>
> Peter
>
> Jeffrey Chase wrote:
> > Aaron Falk wrote:
> >
> >> I took a few notes on the questions that came up during Ted & Rob's
> >> talks:
> >>
> >> Where is time expressed?
> >>
> >> How are duty-cycles expressed?
> >>
> >> How are probabilistic constraints expressed?
> >>
> >> (something about elemental actuators....?)
> >>
> >> c.f. sensorML, ontology for services, network markup
> languages from
> >> OGF, resource descriptor framework
> >>
> >> How is isolation expressed?
> >>
> >> _______________________________________________
> >> control-wg mailing list
> >> control-wg@...
> >> http://lists.geni.net/mailman/listinfo/control-wg
> >>
> >>
> >
> > It seems to me that there's a larger core question here
> that came up
> > about the role of rspec as a language (format?) for representing
> > information about resources and slivers in the GENI
> architecture. How
> > do we balance the tension between standardization and extensibility?
> >
> > There are a couple of options that bracket a continuum:
> >
> > 1. Exactly one: Rspec is the standard specification. It can be
> > extended through various consensus processes defined by
> GENI governance.
> >
> > 2. At least one: Rspec is an initial standard for representing some
> > information, but there may be other alternatives for
> representing other
> > information. If the various actors (component manager,
> clearinghouse,
> > researcher tools) understand some other language, then they can
> > negotiate for resources using that language instead of or
> in addition
> > to Rspec.
> >
> > Strategy #1 has several risks. It means we have to invest a lot in
> > trying to agree on an specification for what GENI actors
> say to other
> > actors about resources and slivers, and their topology and
> > capabilities. What does it mean for Rspec to be
> "extensible"? Can it
> > incorporate information represented in NDL, or DCML, or
> sensorML, or
> > various other languages that other related communities
> might use? Or
> > will we build "our" own language, borrowing from these "other"
> > communities as we see fit? Can the Rspec standard evolve quickly
> > enough to avoid being a barrier to innovation?
> >
> > The risk of strategy #2 is that we later degenerate into a
> > jello-nailing exercise of some sort. But I hope we can
> keep GENI open
> > enough to encompass multiple ways of talking about
> resources, just as
> > the Web has multiple formats for representing content. If
> we can do
> > that, then we will have a more evolvable result and better
> inclusion
> > of other groups who have thought hard about these problems
> for a long
> > time (e.g., http://www.science.uva.nl/research/sne/ndl).
> We should at
> > least ask the question of whether we can get where we want to go in
> > some other way, e.g., by extending NDL.
> >
> > Jeff
> >
> >
> > _______________________________________________
> > services-wg mailing list
> > services-wg@...
> > http://lists.geni.net/mailman/listinfo/services-wg
> >
> >
>
> _______________________________________________
> services-wg mailing list
> services-wg@...
> http://lists.geni.net/mailman/listinfo/services-wg
>
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
Look, Rspecs will be wrong. There will be stuff they omit, stuff they overspecify, and I guarantee in five years we'll look at some chunks of it and say what were we thinking? I also guarantee that Rspec 2.0 will be different from 1.0, since we'll learn things from 1.0. (In general, 2.0's are more complex and therefore worse than 1.0's, but that is life; if we are very wise and lucky we'll zap stuff between 1.0 and 2.0, but more likely we'll be stupid and unfortunate and add stuff). That said, this isn't really all that complicated.
At the end of the day, as an experimenter, what I want to specify is a virtual or physical network, and then ask the GENI facility to go instantiate that network for me. Emulab and PlanetLab both do wonderful jobs at this, so a good way to start is to take an XMLified version of the Emulab ns commands and the PlanetLab XML-RPC interface and ask why doesn't this work? I can think of several enhancements to the unified PlanetLab/Emulab interface:
1. Emulab is almost ideal, since I allocate physical nodes and specify node type, which automatically gives me memory, disk, cpu speed and type. If GENI slices nodes -- and one lesson of PlanetLab is that we should use a hypervisor which offers performance isolation -- then I just want to specify memory, disk, cpu speed and type. Four parameters, and add wildcards. The emulab system of OSIDs and image IDs work just fine.
2. I need to be able to pick specific nodes (a la PlanetLab) or at least network node locations ("give me any node at U Chicago meeting these specs", or "give me any node with an interface matching this netmask and these specs"). For Emulab of course this is irrelevant; PlanetLab lets me pick individual nodes but not resource guarantees on them.
3. This doesn't affect me personally, since like any sensible person I instantiate small networks to run my experiments. Unfortunately, many others (Kubi and the DHT guys) do not share my good taste :-) and instantiate monsters. To make life easier on them (why?) we need hierarchical descriptions. For example, OceanStore really needed clusters at each site to do the signature computations, and so we'll need the ability to specify clusters and instantiate them. That means hierarchical descriptions, and modules.
4. Truly hoggish experiments (like the ones my buddy Joe Mambretti and I kick around) require gobs-o-bandwidth and optical links, so I need to be able to specify links of truly hideous capacity -- 10 Gb/s and above.
5. A call needs to be made -- are we fooling around at layer 1? I haven't the faintest idea about what link characteristics need to be specified here, but Ben Yoo and Keren Bergman probably do.
6. Need to specify layer 2 link characteristics. (Ethernet and parameters, including jumbo and 1522-byte framing, sonet, wifi, fiber channel, etc...
> -----Original Message-----
> From: services-wg-bounces@...
> [mailto:services-wg-bounces@...] On Behalf Of Peter Steenkiste
> Sent: Tuesday, March 04, 2008 6:33 AM
> To: chase@...
> Cc: services-wg@...; control-wg@...
> Subject: Re: [services-wg] [cwg] questions on RSpecs from GEC2 meeting
>
>
> Hello Jeff,
> Your two extremes do look scary. I have always assumed that
> the Rspec would pick an intermediate point in your spectrum:
> if two parties need to exchange some information other than
> the "standard" information in
> the Rspec, they would just be able to do that.
> "Standardizatin" or at
> least rough consensus would be needed if information field
> became widely used.
>
> I think that the issues of time, duty cycle, scheduling unit,
> isolation, etc. are harder. When creating a slice, you will
> need to make sure that these properties of your slivers "line
> up" so you get the right behavior at the slice level. That
> looks like a hard problem. Clearly it will require consensus
> over how to represent this information and what various
> values mean for different substrates. This issue exists
> independent of whether you include the information in the
> Rspec or not.
>
> Peter
>
> Jeffrey Chase wrote:
> > Aaron Falk wrote:
> >
> >> I took a few notes on the questions that came up during Ted & Rob's
> >> talks:
> >>
> >> Where is time expressed?
> >>
> >> How are duty-cycles expressed?
> >>
> >> How are probabilistic constraints expressed?
> >>
> >> (something about elemental actuators....?)
> >>
> >> c.f. sensorML, ontology for services, network markup
> languages from
> >> OGF, resource descriptor framework
> >>
> >> How is isolation expressed?
> >>
> >> _______________________________________________
> >> control-wg mailing list
> >> control-wg@...
> >> http://lists.geni.net/mailman/listinfo/control-wg
> >>
> >>
> >
> > It seems to me that there's a larger core question here
> that came up
> > about the role of rspec as a language (format?) for representing
> > information about resources and slivers in the GENI
> architecture. How
> > do we balance the tension between standardization and extensibility?
> >
> > There are a couple of options that bracket a continuum:
> >
> > 1. Exactly one: Rspec is the standard specification. It can be
> > extended through various consensus processes defined by
> GENI governance.
> >
> > 2. At least one: Rspec is an initial standard for representing some
> > information, but there may be other alternatives for
> representing other
> > information. If the various actors (component manager,
> clearinghouse,
> > researcher tools) understand some other language, then they can
> > negotiate for resources using that language instead of or
> in addition
> > to Rspec.
> >
> > Strategy #1 has several risks. It means we have to invest a lot in
> > trying to agree on an specification for what GENI actors
> say to other
> > actors about resources and slivers, and their topology and
> > capabilities. What does it mean for Rspec to be
> "extensible"? Can it
> > incorporate information represented in NDL, or DCML, or
> sensorML, or
> > various other languages that other related communities
> might use? Or
> > will we build "our" own language, borrowing from these "other"
> > communities as we see fit? Can the Rspec standard evolve quickly
> > enough to avoid being a barrier to innovation?
> >
> > The risk of strategy #2 is that we later degenerate into a
> > jello-nailing exercise of some sort. But I hope we can
> keep GENI open
> > enough to encompass multiple ways of talking about
> resources, just as
> > the Web has multiple formats for representing content. If
> we can do
> > that, then we will have a more evolvable result and better
> inclusion
> > of other groups who have thought hard about these problems
> for a long
> > time (e.g., http://www.science.uva.nl/research/sne/ndl).
> We should at
> > least ask the question of whether we can get where we want to go in
> > some other way, e.g., by extending NDL.
> >
> > Jeff
> >
> >
> > _______________________________________________
> > services-wg mailing list
> > services-wg@...
> > http://lists.geni.net/mailman/listinfo/services-wg
> >
> >
>
> _______________________________________________
> services-wg mailing list
> services-wg@...
> http://lists.geni.net/mailman/listinfo/services-wg
>
_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg
« Return to Thread: Re: [cwg] questions on RSpecs from GEC2 meeting
| Free embeddable forum powered by Nabble | Forum Help |
