futures (Re: [net2-wg] Packet interface)

[Henri DF]

On Thu, 1 Dec 2005, Philip Levis wrote:

> Let's take a step back here.
> 
> If you look at how communication works today in TinyOS, you can only  
> have a single outstanding packet for a single destination address. A  
> queue is a queue, after all.
> This abstraction allows you to have N outstanding packets for K  
> destination addresses. It is much more flexible.
> 
> On one hand, it may turn out that this is not flexible enough, and  
> that experience shows that having a dynamic allocation pool of send  
> pool entries is needed. But I don't think that we can answer this  
> question without a good deal of experience.
> 
> That is, I wouldn't argue that this abstraction is perfect. But I  
> would argue it's an improvement. The first question is, based on  
> network protocols we have implemented, or data link layers we've  
> worked with, are there key pieces of functionality that this  
> interface is missing? The second question is, does this interface  
> include functionality that you think is unnecessary and so should be  
> cut for simplicity? The third and final question is, would you want  
> to write code against this interface, if doing so could greatly  
> improve protocol efficiency, or would you prefer something different?
> 

For discussions sake, I'd like to throw out the idea that the handling of 
futures is overly expressive. 

Specifically, i'll claim that futures could be folded 
into the "one-bit philosphy" of urgent/reliable/congestion: the protocol 
just tells SP "i have more than my current packet" rather than saying "i 
have specifically N packets to come". 

Rationale: Futures are a lot of fine-grained state to deal with for 
SP. Does SP really want to differentiate (on each entry) whether a client 
has n or n+2 futures? Putting aside implementation complexity, are there 
many situations where this can lead to a clear win? Take for example LPL: 
all you care about is 1 bit that tells the receiver to stay awake because 
more is coming.

At the same time, the more granularity you put into futures, the greater 
the likelihood that the protocol will be frequently changing its futures 
as the entry runs. This makes it that much harder for SP to do something 
meaningful with the futures count. 
See the sub-thread starting with Prabal's post on 2.0wg: 
http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-November/001517.html

And changing a future on a running entry can lead to inefficiencies: e.g 
in the LPL example, SP sens a packet with the bit indicating 
"stay awake - more to come" and then the protocol changes its mind 
and tells SP it's not ready.

Final point: with a 1-bit future, it becomes that much easier to specify 
informal semantics of what 'future' means: i have another packet which i 
will be ready to give you "right away" (where "right away" could mean
"without posting a task"). 


Thoughts?

Henri