Net2WG/Notes/20060810

Present: Rodrigo, Arsalan, Henri, Phil, Om, Kyle

RF: LL abstraction requirements on the wiki. We have a long laundry list, let's

   step back and discuss.

PL: Mix between 'uses' and 'provides' in the current list.

PL: Interesting: only dissemination appears to require cancellation. Correct?

RF: Opportunistic may also need it.

RF: For trickle, what is the minimum needed in terms of scheduling?

   "transmit before this time"?
   "transmit between this time and that time"?
   

PL: Need to bound the time until a packet goes out, e.g

   "send not after" some time.
   or maybe this can be done with urgent bit, by cancelling and re-sending
   with urgent.

AK: What about just leaving functionality this in the network layer, ie the

   network layer sets a timer and pushes its packet down into the link layer
   after timer fires.

PL: For trickle, delaying packets is fine, but randomization is key, so TDMA

   is tricky.

AT: Rate limiting: how does it work when you have multiple protocols each

   indicating their own limit?

RF: Flush: assume you have pool/queue at link layer. Then read

   rate from queue can only be controlled at the link layer.
   

OG: Are we explicitly assuming collection-type scenarios, with a single

   destination?

RF: Could rate-limit either per-destination or per-node

PL: If LL provides some rate-limiting mechanism, it should be general and not

   only work for single-dest traffic. Though we don't really know what
   mechanisms would be necessary in multi-destination scenario.

OG: We could at least support broadcast rate limiting and single-destination

   rate limiting.

PL: Is rate-limiting for unicast? anycast? broadcast?

PL+RF: Note that rate-limiting is only relevant if the LL does any form of link

   layer. Presence/not of futures ties into that.

somebody steps out and plays piano ?!?!

PL: SP is basically trying to use its awake time as efficiently as possible,

   and futures can be implemented in different ways.

AT: Rate-limiting can't be done properly at nw layer if there are futures,

   buffered packets, etc in the LL -- or to do it properly is very painful.

KJ: Depends -- if we assume that multiple network protocols are running on top

   of the LL or if we have a single protocol. 

RF: Let's discuss latestamping/timestamping

   Comparison with Apache's way of having modules attach to the request
   lifecycle.

PL: How precise does timing info need to be? LL timestamps must be very

   precise. Flush may have much looser requirements.

OM: Countersniper precision requirements? usecs or something like that

KJ: What about VU's timesync stuff?

RF: Start symbol, usecs

PL: Let's step back to bigger question of neighbor table (NT), message pool.

AT: Going back and forth about extensibility of NT. See it as single-hop table

   that maintains minimum amount of info. Naming: prefer to have handles. 
   Joe P. argues that handles confuse people. 
   Proposes as fields:
   SP handle
   Link quality
   
   Current proposal contains info power scheduling, does this need to be
   exposed to the network layer? 

RF: According to Joe's writeup, making this info available from the NT is

   crucial.

AT: What about extensibility? Make it available, or decide that network

   protocol does it's own thing if it needs to keep other types of per-ngbr
   info?

PL: How about having reflections of the table?

   Provide a way to have extensibility only for the neighbors that a network
   protocol cares about.

   Let's also take into account that underlying CSMA (LPL) vs TDMA makes a big
   difference. Original goal of SP was to support both. Still true?

AT: Yes

RF: Agree that SP should export events on node eviction/insertion that allow

   an upper layer to reflect what it wants.

OG: What about ability to pin/unpin neighbors?

AT: Yes, needs to be there.

RF: What about LL estimates?

AT: Think that single-hop link-layer estimator should remain in LL.

PL: Can we only send to nodes in table?

AT: What about situations with more neighbors than table size?

   How to avoid thrashing.

PL: Lots of caching strategies.

AT: Can we start talking about interfaces in a more concrete manner?

RF: Let's first boil down list on wiki into set of requirements. Interfaces is

   next step.

OG: Are we assuming certain type of radio?

RF: No, and one motivation of handles is to better mask different radio

   frames/naming.

RF: Will refine list of requirements for next week

PL: By next week, will have a draft collection protocol TEP (non-rooted one, a

   la mint route), should also discuss it.