[net2-wg] 2/2/2006 Telecon notes

[henri dubois-ferriere]

Mtg nodes 2/2/2006

[ note: i may be confusing Om and Rodrigo's voices ]

Om, Rodrigo, Joe P,  Kyle, Phil, Gil, Jon, Henri
============================================

Phil: Status on Collection?

Om: Draft of service in collection.draft
Basic idea: provide best-effort multihop delivery of packets.
Can have multiple trees, each with one or more roots.
For control plane purposes, a node maintains one parent for each tree
(to whichever root you want).
DV-like algo. Periodic bcasts of each node's distance vector.
For forwarding, you can route to the "control plane" parent, or to any other
that has lower cost than you.
To become root, you just advertise hopcount=0. Any node can become a root.
3 main interfaces
- Forwarding (buffering, retransmits)
- Routing Engine (maintain topology, propagate control messages)
- Link Estimator / Neighbor table
Distinguish between fwd / bwd / bidir link qualities.
Status: have draft, interfaces, have divided components for each one to
implement.
Interface for application is address-free send. Compile-time parameterized by
tree-id. Anycast semantics.

Rodrigo: Should we provide PC-side sw, ie to detect if a node is a root via
serial, or to add a layer above multiple roots of a tree to "merge" packets
coming from each.

Phil: Can go either way. It should be clear that duplicates can arrive at
different roots, and up to application to deal with this.

Rodrigo: We could get dupes even with one root. Will add (source,
seqnos) to data
packets to identify packets uniquely.

Om: Is there a way to connect a sf to multiple basestations?

Phil: There is Kamin's sfmultiplex. Not on critical path for 2.x, but if ready
and works, will go in.

Joe: Is there a way not to use the resources (packet fields, mem space, code
space) if i have a single root? MultiHopLQI, Drip, Drain, Deluge already take
up a lot.

Om: MultihopLQI and Drain would be replaced by this new collection.

Joe: But they have very different goals, ie a 'MultihopLQI' has higher latency
than Drain. Or Drip and Deluge both use Trickles.

Phil: Status on Dissemination?

Phil/Gil: busy, most likely will not get to it until post-ttx. could drop
interfaces into cvs right now, but no implementation.

Phil: TTX Plans. Who will be there? Phil, Om, Rodrigo (p=.5), Jon, Gil, Joe
Will give a 20-minute talk on netwg. Contents?
- membership
- zigbee: say we are open and interested, if you want to work on a zigbee
  stack, join the group.

Gil: so far net2 has been focused on doing the 'berkeley' protocols for
  2.x. create a separate wg for zigbee?

Phil: really depends what we want to do after collection/dissemination.

Kyle: interested in working on sendpools

Henri: same, as soon as i bring up t2 on tinynode

Joe: service discovery

Om: interested in sendpools. about zigbee: a good reason to have a ref
implementation is for comparison/benchmarking with other protocols.

Phil: are zigbee/sendpool mutually compatible?

Joe: try it to see!

Rodrigo: would be interested to see a framework/architecture to allow one to
implement protocols more easily (ie, i don'thave to reimplement link estimation,
fwding engines, etc).

Joe: Present the potential directions above at ttx, and say that if anyone is
interested in these, join the group.

Phil: Sounds good. Send proposal to list and will gather them up.

Joe: SP and Zigbee proposals are pretty straightforward.

Phil: Won't be there next week. A priori no meeting next week, unless
something comes up.