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

[Philip Levis]

On Fri, 2005-12-02 at 00:44 +0100, Henri DF wrote:
> > 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.

I think that the guiding principle is "these seem necessary and
sufficient." 

I also think it's pretty clear that having the concept of futures (more
than one to send) meets the requirement of "necessary." In the light of
the principle, one way to rephrase your question is to ask:

"Is a futures bit, rather than a counter, sufficient?"

I'll argue that the "bulk transfer" approach is a non-starter. This is
supposed to be a unified interface to a very wide range of connection-
free MACs/data links. To say "well, except RTS/CTS (e.g., SMAC)" isn't
really feasible. The goal here is that you can implement a routing
protocol on top of this abstraction and it will work well on BMAC, SMAC,
ZMAC, TMAC or, when we run out of Latin letters, OmegaMAC. As this very
large class of MAC would require a count, then I think it's worthwhile
to include. Plus, it makes a very nice clocking mechanism underneath:
the pool entry keeps track of when to stop, rather than requiring a stop
from above.

Of course, if we did take a bulk transfer approach, then you might well
be right. In that case, a "more" bit could be sufficient. But my feeling
is that RTS/CTS is too big a class to ignore.

What do other people think?

To be honest, the one part of the interface which I do not think
experience has shown to be necessary is the urgent bit. There are very
few protocols that have traffic classes. Fusion does, right? That's the
only one I can recall. But common wisdom suggests that this could be
very important in the future, e.g., for control traffic.

Phil