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
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
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
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
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?
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
OG: Are we assuming certain type of radio?
RF: No, and one motivation of handles is to better mask different radio
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.