[net2-wg] Collection (and more in general, multihop routing)

[Rodrigo Fonseca]

Thanks,

Henri. Yes, there are some details that I went over, and some
adaptation I should have done.

> I don't understand all the details of the proposal (ie, what exactly
> does getnexthops return, what is a SPHandle, why/when would the
> CostBasedRouting interface be used),

SPHandles are what we are using to address links at the network layer,
but that is not important. For now, since we are going to use the
Send/SendDone interface, just think of these as uint16_t addr, "link"
addresses of the next hops.

CostBasedRouting is used when doing OppotunisticForwarding.

The pseudo-code for the simplest Opp. Fwd is something like:

receive {
    CostBasedRouting.getMyCost(void * RoutingHeader, uint16_t *mycost);
    if (mycost < pkt.cost) {
        pkt.cost = mycost;
        schedule forwarding for some future time
    }
    If I hear someone send the same message, cancel my send.
    Otherwise, broadcast message when timer expires
}

The requirement for this to work, or, in other words, for a
RoutingEngine to provide this interface, is that it can establish for
each possible destination a globally consistent 'cost' that is
non-increasing towards the destination.

>
> - Is it necessary for the app to know what protocol is implementing
> the collection interface beneath it? (and hence, be aware of the
> addressing scheme being used). Can't we just have
>    command result_t collect(TOS_MsgPtr msg, uint16_t length);
> and not specify the address (since this is message is for "collection" anyway.

No, the application itself shouldn't need to, but some component that
would abstract this away from the application can sit right above the
networking layer and know about the specific addressing of the
RoutingEngine being used.

>
> - Similarly, my understanding of the 3rd-to last para is that if we
> have multiple sinks, the address would be chosen by the app to
> indicate up which tree to send a message. In other words, a component
> above Collection must make the routing/collection decision of which
> tree to use. Shouldn't this be transparent to the application?
>

Same as above.

> - It might be nice to have some sort of Intercept interface to allow
> in-network processing (if we have a clear enough idea of this..)
>

Sure. This can be present in the ForwardingEngine (and in the
interface it provides) and have the same semantics as it has today. We
can have intercept and snoop. This doesn't change the Routing Engine
at all.


Rodrigo.