[SensorNetArch] Oct 11 Meeting Notes

[Gilman Tolle]

Topic: What are some Open Problems?

Transport Services
- reliability
- fragmentation
- congestion/flow control
- buffering
- Ion: this has to be end-to-end
- what does this mean in the presence of in-network processing?

SP
- what will it include?
- where is the narrow waist?

Reliability
- not just transport
- also includes link layer
- how does end-to-end reliability relate to in-network processing?

Network Architecture
- what's the common framework across a range of
  - traffic patterns, comm scheduling, link technologies
- effects of "not always on"
  - discovery, retransmission are harder
  - scheduling creates rigidity
- should there be a "topology layer"?
  - how does it relate to different app requirements, technologies underneath
- if performance and energy rule, it's very hard to simplify the architecture
  - optimization creates cross-layer information dependencies that are
    hard to untangle
  - what can we ignore, to simplify the problem?
- link-layer power management protocols try to be opaque to upper layers
  - if it's not opaque, in what way is it exposed?
- the Internet left a lot on the table in terms of efficiency
  - most pairwise point-to-point apps are supported satisfactorily
  - others fall outside the scope of Internet technologies
  - those who tried to tune lower-level technologies lost out (e.g. ATM)
- we want controlled transparency
  - enough to provide reasonably enhanced performance

We've come up against the tension between simplicity and performance.
It's not the first time, but it's particularly acute here.
Where is the sweet spot?

What is the Least Common Denominator for WSN space? 
- it is different from the LCD of Internet space
  - includes energy

Naming
- need to clearly articulate the naming problem
- attributes / addresses is just the tip of the iceberg
- managing large and small address spaces
- what functionality would you like? (addresses alongside attributes)
- what are the constraints? (very few bits)
- different costs show up, different resources
- large address spaces are attractive if they are unmanaged
  - can't write down which portions are in use
  - managed: allocation, interpretation, translation
  - translate 
    - between names and resources
    - between different address spaces
- spatial locality...can we interpret names in this way?
- in diffusion: how is an attr described? XML? String? Small Digit?
- should we distinguish between "names" and "identifiers"?
  - Ion's definition: 
    - names are human readable and variable length
    - identifiers are machine-readable and fixed-length  
- WSNs are edge devices in Internet space
  - there can be translation at the gateways
  - can a gateway know of every node in the network?
- what has an address?
  - the sensor network?
  - the nodes in the sensor network?
- tinydb uses string names for sensors
- SNMS translates between names and identifiers
- routable names? names of subsets?

Local Operators with Global Behaviors
- this is the general networking problem
- we see lots of emergent behavior and noise
- dissemination (trickle)
  - eventually reaches everywhere
  - traffic is independent of density
- minimum-cost collection trees
  - maintain a stable spanning tree
- local rules may lead to unexpected global behaviors
- can phrase this problem in terms of the "toolbox", of operators
  - what are the basics we know how to do, and can build into an architecture

Resilient Aggregate Operation
- if we had some resilient operators, what could we build out of them?
- trickle uses all paths, assumes nothing of structure, uses all paths
- tree-based summation is sensitive to structure
- duplicate and order-insensitive aggregates
  - can use all paths in the gradient
  - makes routing similar to dissemination
  - can do and/or/max/min of vectors
  - this is ultimately the right perspective
  - use inherently resilient operators
- congestion control requires feedback
  - if the topology is changing too quickly, the feedback can't propagate
  - but, trickle does congestion control without feedback and without topology

Sensor Networks are Distributed over Space
- this is fundamental
- space matters little in the Internet
- what does the fact that space matters mean?

What are we removing from our requirements?
What are we precluding?
- actuation, mobility, directed antennas??
- actual processing of sensor data?
  - focus on networking support
  - those should be plugged in on top of it
- intermittent but predictable connectivity schedules
  - discovering them
- control vs. data gathering
  - does this boil down to latency bounds?
  - time synchronization
  - control of a mobile object
- are all of these control issues variants of QoS?

What's the failure scenario for our project?
- under what conditions could an architecture not be used?
- imagine a world in which tech or apps drifted too rapidly for an 
  architecture to stabilize
- mode 1: it would fail if nobody bothered to innovate within it
- mode 2: development of multiple different implementations that do
  not interoperate.
- does pigeonholing peoples' work make the overall system stronger?
- all of these techniques are variable...how do they fit together?
- mode 3: development of components that make sense within the
  architecture, but still don't fit together.

Didn't talk about
- how does the presence of a large node ease the burden on the small nodes
  - can imagine a strict hierarchy and subdivision
- heterogeneity
- fitting into upcoming standards (ZigBee)

Wherever the constraints get eased, it needs to lessen the burden on
all other constrained nodes.