Net2WG/Notes/20060803

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.