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

[Jonathan Hui]

On 12/1/05, henri dubois-ferriere <henridf at gmail.com> wrote:
> 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'd argue that we've seen both on TinyOS. RTS-CTS has been implemented
and any network protocol with queues 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).

Let's say we did create a BulkTransfer interface. I'd then argue that
SP would have to provide the BulkTransfer interface and 1-bit futures
would need to be emulated on top (opposite to your proposal).
Otherwise, MACs that do require channel reservation will have no
chance at getting information on what to reserve. This model also fits
better with the telescoping abstractions concept.

> 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 main 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.

One of the main problems when making reliable and urgent uint8_t's is
what do the numbers actually mean? I wouldn't even know how to start
defining these values such that they have uniform meaning across all
links, and defining them is a prerequisite to using them
appropriately. With futures, the number is clearly defined and easily
understood.

Finally, I'd argue that link-layers that are perfectly fine with 1-bit
futures are no less complex than n-bit futures. They simply checking
for non-zero futures. Any futures manipulations will be handled in the
common SP library, and I'd say that the current SendPoolEntry
interface makes it easy to implement those manipulations.

--
Jonathan W. Hui
jwhui at cs.berkeley.edu
http://www.cs.berkeley.edu/~jwhui/