[net2-wg] Call Transcript: 8/3/2006

[Kyle Jamieson]

Roll call: Phil, Rodrigo, Om, Arslan, Kyle

R: Arslan sent document

R: met for collection, decision to have another TEP specifying 
collection protocol, Phil's suggested Tree Collection Protocol (TCP) :-)

R: other conclusion: need to implement DSDV, two approaches.

P: two protocols, only way to figure out which one to go with is thru 
evaluation.  DSDV advantage is that assuredly loop-free.  Disadvantage 
is that all routing updates be instigated by base station.  Non-DSDV 
approach: nodes individually decide when to update routes, leaves 
possibility of forming loops.

R: arguments for each approach; have to evaluate.  Forwarding process 
has to be different if loops might be present.

R: Regarding one-hop abstraction, started talking about LE and LE 
interface.  Then talked about nbr tbl, shared in SP between all 
protocols.  One idea is pin/unpin interface to control who goes into 
table or not.  How to make a shared tbl extensible?  How to have each 
protocol declare which fields it wants.  Currently SP declares struct in 
file.  Better way?

P: extensible table very problematic idea -- introduces dependencies. 
Two components both use a field; who is responsible for maintaining it?

A: what's alternative?  Just embed everything in table?

O: one alternative is each component keeps its own table.

A: of extensible fields?

P: situation is where piece of data assoc with nbr that multiple 
protocols care about, but some protocols don't.  Want to be able to 
include it only if it's needed.  Q is who generates it.

A: If only one thing sitting on top of LL, then move functionality into 
network layer.  If two, 3 apps want to use it, then can't embed it into 
network layer.

P: how would this work; where does field come from?

R: simplest case is suppose we have idempotent decls, two protocols 
require same field, just one gets compiled in.  Many problems -- 
write/write conflicts.

P: easy to say shared value; but who gets to write?

A: two protocols weren't designed to cooperate; then no problem moving 
extensible layer to network layer.

P: concern is that it seems like something that's very tricky to do; 
payoff is that you'll save a few bytes of RAM.  Maybe what we want is 
that you can create mirrors of table.

R: nbr table is a subset of LE table in collection right now; maybe 
having a mechanism to create derived tables makes sense.

O: or superset

R: so e.g. you may have entries in table that are two-hop neighbors.

K: tool to coordinate tables might be useful.

R: Hood (Kamin, Cory), came to conclusion that different protocols 
needing to refer to different subsets of nbr, may be more efficient to 
have different tables.

P: right now we're talking about low-level interface to LL abstraction. 
  Fundamentally, what do we want from this abstraction?  Arslan said -- 
three basic things abstraction should provide.

K: three things are LE, nbr tbl, shared pool.  First two are pretty 
fundamental...

P: anyone disagree with LE, nbr tbl?

A: all three are valuable.  Reason shared message pool is there is that 
it has better knowledge of which nbrs are awake.

P: what is a shared message pool?  Does that mean multiple outstanding 
packets?  Can send multiple packets at once?  Each protocol can look at 
the pool?

A: last one no, no benefit.  Message futures argument is efficiency -- 
if going to be awake, might as well send.  Often latency is not an 
issue; shared message pool beneficial for minimizing power.

O: network layer provide shared message pool?

A: what is network layer going to do better than LL?

K: not clear on what network layer is?

P: rephrasing Om...  Idea that you have many packets outstanding, pick 
which ones to send is related to Fair Queuing.  Imagine LL has nbr tbl, 
above it decides which packets to send when.  There is a policy: for 
given nbr, servicing is FIFO.  Might not be best policy.

A: not possible to have no policy.  Component could be interchangable.

O: think it's a valuable functionality to have common place where 
messages come in.

R: SP takes position of minimizing energy.

A: think that more fine-grained priority system is useful; tell SP 
bounds on message time.

P: basic question: path of efficiency and deadlines (RTOS), or path of 
multitasking and fairness; trying to give everyone own fair share.  SP 
has been in former category, as well as TinyOS.

K: sounds like we want two link layers.

P: or as Arslan says; build LL abstraction without policy.

A: question is is that a decision we should make whether one is better 
than the other, or should leave to designer.  Why not leave to designer 
of network?

P: if we make a choice, could be the wrong choice.  That's what happened 
with collection; two approaches were incompatible; so we'll do both, let 
time and experience decide.

P: problem would be if people start to design protcols, systems that 
assume one or the other.

R: one last point; in either of the two cases; needs to be resource 
accounting.  Different criteria.  E.g. fair sharing between nbrs; could 
be at odds with higher-level goals of a protocol.  One important point 
to keep in mind.

P: 2 separate issues: what is abstraction LL provides?  Secondly, how 
internally implemented s.t. it's easy to have two separate policies. 
Either way, is interface to the two different, if not let's figure out 
what the interface is.

R: goes in line with deciding what the requirements are.

P: all are in agreement that nbr tbl, LE are critical.  Outstanding 
packets that the LL can choose from seems reasonably important.  If LL 
overhears packet to someone else, then can think that that node is awake 
and use it opportunistically to send in a CSMA network.

P: seem to be in agreement there.  Exactly what decomposition is is a 
bit open.  Arslan's done a lot of work on this, has good observations. 
Lots of people working on SP (me included) are thinking in a certain 
mindset; great for people who haven't drunk SP Kool Aid to make suggestions.

K: agree

A: need to define responsibilities of different layers.

R: Arslan is saying maybe not ready to specify interfaces.

A: question of whether we're talking about congestion at LL, acks, 
timing information necessary.

O: suggestion: say we want collection; would fit on top of LL.  Want to 
review assumptions we made in collection.

P: source addr, dest addr, synchronous acks, protocol dispatch 
mechanism, broadcast supported (w/o acks), no assumption of snooping

K: suprises lurking; wrt congestion

P: priorities for LL from routing protocol.  Telling link layer which 
types of messages routing layer has.  Have lots of protocols, each 
person choose a protocol, writes down requirements on the LL for each 
protocol.

O: also useful to see what Xbow and Moteiv have.  What about 
dissemination?  Should probably ask Joe/Martin.

P: me -- Dissemination, Kyle -- Fusion/Congestion, Rodrigo -- Flush, 
Arslan -- DSN (Declarative Sensor Networking).

P: write down things they've identified LL doesn't provide, but should.