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

[Henri DF]

> On 12/1/05, Henri DF <henri.dubois-ferriere at epfl.ch> wrote:
> > 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".
> 
> The number of futures is important for protocols that notify neighbors
> about the number of packets in a pending transmission. For example, an
> RTS-CTS scheme might transmit an RTS with 8 packets to send. Also, a
> beacon-based protocol like 802.15.4 might announce the number of
> pending packets to send in the beacon packet.


Sure. Indicating the number of futures can allow efficiency 
gains when:

a) we have a MAC layer which supports some form of "reservation"

and

b) we have an upper layer which can deliver packets in bursts of size >= 
3.

I would argue that the combination of these two prerequisites is one 
case amongst many others, but is not clearly mainstream to the 
point of justifying features in the interface that are tailored to 
the particular case. 
If it really is that important though, then i think it should be 
addressed through an explicit "Bulk Transfer" interface which clearly 
exposes the semantics of channel reservation/allocation. For MACs such as 
CSMA/LPL or TDMA which do not support this, the interface could be 
emulated as a thin layer on top of SendPoolEntry (using 1-bit futures).


An analogy to your example above: Many MAC layers can trade off 
reliability for efficiency at richer than 0|1 granularity 
(e.g through variable re-xmits or variable error protection rate); 
others can trade off latency for efficiency to variable degrees; would 
that justify making reliable and urgent uint8_t's? 

Maybe yes, maybe no -- my only point is that there are lots of 
possible combinations of upper/lower layers, and i don't see at this 
point a clear guiding principle on what is/not important enough 
to be explicitly supported in the interface.

Henri