[net2-wg] call notes 23/3/06

[henri dubois-ferriere]

Phil, Om, Kyle, Rodrigo, Henri, Sukun




Rodrigo:
- Looked at a bunch of multihop collection implementations

- Differ in metrics, queuss integrated or not, control messages triggered or
  periodic

- Control messages:
  + Triggered: Drain
  + Periodic: about everyone else
  Both approaches valid.
  Suggests making room for both: a control message has a 'trigger' bit which
  forces received to resend a control message shortly after.

Phil: Good to separate link quality and path quality

Rodrigo: Some link estimators (ie BVR) rely on periodic messages.
	 Piggy back on traffic, if no traffic generate own traffic.

	 Other methods could use LQI/RSSI and not need periodic messages.

Om: In terms of # packets, prob efficient to merge link and routing info in
    same packets
	
Phil: Maybe getting into a raffle here.

Om: Started implementing. Overview:
    Send neighbortable (with seqno)
    Everyone can compute bidir link quality
    Neighbortable size is determined at compile time
    Con: Beacon message growing with neighbortable
    What to optimize for: Code size? Memory? Communication?
    Didn't yet do seqno wrapping, table pruning is very simple.

Phil: Neighbor table size is not a major worry


Henri: How do you fit seqnos + addr + qual in 4 bytes?

Om: Not keeping seqnos yet.

Rodrigo: This is needed. Could have seqnos be 'stamped' at the bottom, as
packets go out. Link est should be at the bottom of the stack.

Phil: Do we put the seqno at data-link layer or collection layer?

Rodrigo: Link layer.

Phil: But it adds this field to every single message everywhere.

Henri: Is this necessary? For byte radios possibly not.

Phil: For cc2420, header is predefined, so seqno would have to be in packet.

Phil: Why not pop up a frame, and go for a simple implementation that can form
      a basis. Then later (and as we go toward SP), we can revisit link
      estimation.

Om: Might not be able to test on mica2.
    Will test on telos and maybe micaZ.


Sukun: Often tend to underestimate congestion's effect on link quality.

Phil: Fair to say their are few apps intended for heavy load. Without solving,
problem, could still aim to have interfaces flexible enough that they support
future 'smart' solutions to congestion.

Om: In a past app, simply froze estimator when we saw a lot of packets.

Phil: Status: tested dissemintation in TOSSIM.
      If you modify different things at same time, will slowly converge.
      Maybe better algorithms for disseminating multple values, but future
      work.

Phil: Chatted with jonathan about initial netw2wg link layer proposal,
      different SP forks, etc:

      Basic question: what does 'urgent' mean? Existing protocols from SP
      paper never use urgent. Vaguely defined, hard to know whether or not to
      use it.

      Idea: attach 'send-at-latest' timestamp, so that we have a measurable
      and clearly-defined metric for urgency.

Kyle: Existing work (velocity) that does this, might be worth looking at.

Phil: Could be useful even on single-hop basis. Will send summary of
      discussion I had with Jonathan.