View source for 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.