[SensorNetArch] notes from today

[Joe Polastre]

here's some poorly written notes on naming, hope they make sense :)

phil: what is the timeout of the name
david: what transactions have passed on the name? how are the
predicates expressed? how does the universe operate?
scott: do you seperate between names and attributes?
david: i don't care how you express predicates, its just a way of
creating a name. what's the lifetime of an ip multicast group?
david: split predicates from the execution on those predicates
(seperation model)
ion: you form a group of everyone who is interested in an event
(temperature between 10 and 20)
ion: for each attr-value that matters, you give it a name; divide the
naming space and give identifier...
david: identifier to the evaluation of a set of predicates, which MAY
be over a set of attr-values
scott: how does this relate to direct diffusion
david: it defines a point of binding, set of ops/query lng over tuple
space that determines the participants, both srcs and sinks. includes
select and union, not join, not clear what the set of queries are
ion: dd is late binding; push interests
phil: do you resolve predicate when you need to
scott: should be specified in the predicate, naming the whole
evaluation proceeding
david: what i like about decoupling--to eval i must have a
communication capability.  must be some a-priori networking capability
before predicates become useful.
ion: do you need primitives for flexible fine grain communication?
what do you need?  group forming?
david: most of what we're talking about is group communication,
sometimes of size 2
david: ability to insert and remove names and communication ops; what
can we detect about names? best effort naming definition over set of
nodes
david: if i define an aggregate over a group, how do i keep that from
being disseminated to everyone?

david's concrete proposal:
4 things at net layer (converge, disseminate, 1-1, aggregation), every
node has a collection of names, operations are based on the name, node
participates in that operation if it is part of the set of names

scott: could reimplement directed diffusion with david's proposal and
the seperation
david: forces you to take a position on what it means to be a participant
can you communicate with a multicast group without being in the group?
scott: sending is orthoganal
ion: but can you receive?
david: what's the filter on destination address? what's the least
mechanism we need on the node?  need more than "an address", rather k
addresses
ion: want semantics of open group in the multicast IP work
david: go through the rights and wrongs if ip multicast
scott: when i see a packet, is it for me???  sometimes you have to
evaluate complicated predicates to decide if packet is for you
ion: you have symmetric send operation
phil: does a name refer to a node or an interface
scott: a name says "this is a packet i should read"
david: names independent on incoming side
scott: really just an implementation issue on the node
david: a network operation is applied to a name--determines which
nodes participate in the network operation
joe: so a name can consist of an address, service, group, port, etc..
david: does the set of participants have to be contiguous
ion: of course not!
ion: nodes interested in certain temperatures may not be contiguous
scott: name says you read the packet, whether or not you forward is
handled by a different directive
david: (1) names either help route or (2) names define the destinations
scott: do making these logical distinctions change the way you code?
<confused faces>
scott: would it change the way directed diffusion is implemented?
david: yes, you would have formulated directed diffusion in terms of
this seperation
phil: tag doesn't have this; disseminate query to everyone that's only
addressing
phil: what does this mean for state mgmt on a node if i have to
resolve per reception (name-value pairs where value can be a fn), very
nervous about this
scott: how does this framework make the problem worse?
scott: app level decision to bind early or late, thinks phil is saying
binding late may cause problems
phil: if names indpendent of interface, names must be global across
two networks.  name 492 must mean the same over both interfaces
david: why don't we have bind?  bind seems very powerful, otherwise
everything has to go to everybody!
ion: node may decide/differentiate which interface to use based on name

<scott leaves>

david: hoping this will define crip problems at the "next" layer.  set
of 1 is routing problem, set of all is dissemination, so what does it
mean to do dissemination for in between?  collection?  now network
level has well defined set of services to go do.

<david leaves>

ion: can outside the group send to inside the group?  what's different
from open group ip multicast?
phil: yes.
ion: but it really is the semantics
phil: open "boundaries" occur at the higher layer

scott's proposal for 3 different roles of a name (poorly articulated by joe)
- a way to get there
- a machine to deal with it
- the data that's associated with it