[net2-wg] Packet interface

[Philip Levis]

\On Nov 30, 2005, at 7:02 AM, Kyle Jamieson wrote:

> This interface sounds like the right idea; we started down a similar
> road when we implemented the Fusion network stack.
>
> One question I have is the following: suppose we have multiple apps
> running on a node, and want them to share a common congestion manager.
> Wouldn't this be difficult, since each app uses its own
> SendPoolEntry.start/stop methods to respond to congestion (if I'm
> reading this correctly...)?
>

Yes. Among other things, different protocols may need to respond to  
congestion differently (e.g., broadcast vs. unicast packets).

One way to have a shared congestion manager is to have them share a  
single pool entry. Of course, this means that some component above is  
going to have to organize their outgoing packets in order to meet the  
pool entry requirement of a single destination address at a time.

Another way is to put a decorator on top of the pool:

module CongestionManagerC {
   provides interface SendPoolEntry[uint8_t id];
   uses interface SendPoolEntry as Below[uint8_t id];
}
implementation {
   uint8_t state;
   message_t* myMsg;

   event message_t* Below.next[uint8_t id](message_t* msg) {
      if (PoolPacket.congested(msg)) {
        state = STOPPING;
        myMsg = msg;
        return NULL;
      }
      else {
        return SendPoolEntry.next[id](msg);
      }
   }

   event void Below.stopped(message_t* msg, error_t err) {
     if (msg == NULL && state == STOPPING) {
       state = IDLE;
       signal SendPoolEntry.stopped(myMsg, EBUSY);
       return;
     }
     signal SendPoolEntry.stopped(msg, err);
   }
}

Then, a client wires like this:

// SEND_POOL_CLIENT is #define to some string
enum {
   CLIENT_ID = unique(SEND_POOL_CLIENT)
};

configuration ProtocolC {
   provides interface Send;
}
implementation {
   components ProtocolP, CongestionManagerC, SendPoolC;

   ProtocolP.SendPoolEntry -> CongestionManagerC.SendPoolEntry 
[CLIENT_ID];
   CongestionManagerC.Below[CLIENT_ID] -> SendPoolC.Entry[CLIENT_ID];
}


> Second question: seems like there is no way of setting per-packet
> urgent/reliable/destination metadata.  I must be missing something
> here; could you clarify?

Correct. The issue is that for some data link layers, these bits can  
affect scheduling decisions. For example, under a low-power-listening  
CSMA layer, urgent can mean "send a long preamble." If we allow per- 
packet metadata, then there are all kinds of scheduling issues that  
arise (e.g., an urgent packet in a queue sitting behind un-urgent  
packets).

For example, whether or not you have ACKs enabled on 15.4 greatly  
changes packet times, due to the two RX/TX transitions you need to  
make. A time-based RTS/CTS would have issues if you could change  
reliability.

If, for example, you want high-priority control traffic and normal- 
priority data traffic, then you can allocate two pool entries.

Phil

-------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot,  'Little Gidding'