[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

In the sample implementation, AM releases the resource after each
packet.  If everyone did this, it would effectively implement a round
robin queue.  Since the only implementors using this interface are
already deep in the stack, I feel that it's more valuable to have the
most possible freedom rather defend against potential fairness issues.

Virtualization is unlikely to cause problems for AM since it's already
virtualized.  It is unlikely to be more then a nuisance for blip.

Do I detect that you prefer the other approach?
Steve

On Sun, Jun 28, 2009 at 5:13 PM, Philip Levis<pal at cs.stanford.edu> wrote:
>
> On Jun 28, 2009, at 3:20 PM, Stephen Dawson-Haggerty wrote:
>
>> Just like in the AM layer, we need resource sharing between different
>> senders.  However, I am loathe to add another layer of buffering since
>> most existing code assumes it "owns" the radio and does its own
>> buffering-- both blip and the AM stack do this.  The lightest-weight
>> solution seems to be adding a Resource lock around the radio; with
>> FCFS it will be reasonably fair.
>
> I think the tradeoffs are these:
>
> Queueing
> Pros: Isolates clients, enforces fairness
> Cons: Virtualization can interleave packets
> Cost: 2N+K bytes for message queue
>
> Locking
> Pros: Allows clients to time packets
> Cons: Clients can starve others
> Cost: Cost of lock (N/8 + K or N+K)
>
> How would virtualization cause problems for AM or blip?
>
> Phil
>
>
>
>