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

[Rodrigo Fonseca]

> Would we rather design and implement core network protocols on top of
> the standard send/sendDone interface, or something more like
> SendPoolEntry?

So let us try to extract exactly what advantages/flexibility the
SendPoolEntry is warrantying us, versus the added complexity of
programming against it.

Many details aside, the core issue is that the SendPoolEntry, or the
SPSend interface in the case of SP, is:
   - giving each client (network protocol, application, etc), one
"queue" of many packets (futures)
   - letting SP (let me call the link layer abstraction SP) schedule
among these queues with an unspecified order

The heart of the idea is the "pool" concept: SP can optimize
transmissions and have different protocols share the radio in a better
way, for some MACs, if it can order the transmissions based on things
like wake-up schedules and long preambles. When it can't thus
optimize, the performance will be no worse than that of a normal
(fair) queue, so this point is a good one.

The futures (the fact that each PoolEntry is a "queue"), also allows
optimizations in the same fashion as before, if SP can assume the
declared entries are for the same destination.

This is the point I think might generate confusion: if each client has
to allocate entries for each destination, this can be a hard decision
to make statically. On the other hand, what I see will happen is that
clients will start changing the futures in order to multiplex
destinations on the same pool entry. In this case, SP can't do
optimizations, and if this is not done right, the practice may fool SP
in its optimizations.

The last point is that there will be an interaction between scheduling
decisions that clients will be doing on each pool entry with the
scheduling that SP will be doing among different pool entries. What
are the semantics of the scheduling decisions that SP will make such
that there won't be some strange feedback look among the schedulings
at different levels?

I didn't discuss the urgent/reliable bits, but I think these are fine,
and at first expressible enough for most foreseeable uses.

So, to summarize, I think the model of allocation of entries should be
discussed, so as not to create destination-multiplexing behaviors in
clients that may hinder the ability of SP to do its optimizations.
Maybe there is a simple model in which SP has a fixed number of
entries in its pool, and these are recycled among the clients on
demand. Second, we need to define the scheduling semantics so as to be
able to reason about the interactions between scheduling decisions
intra-pool and inter-pool.

Thoughts?

Thanks,
Rodrigo