[net2-wg] Collection interface

[Philip Levis]

On Dec 28, 2005, at 10:24 AM, Omprakash Gnawali wrote:

> I was thinking of collection as the top level component with which an
> application interacts and
> bulk/non-bulk/reliable/fragmentation/ack/nack/hop-by-hop repair happen
> depending on what you select as your collection/forwarding protocol
> and how you configure them.
>

I agree completely with your approach. A variety of implementations  
could sit below the component specification.


> Any comment on separating the Intercept interface into network
> intercept and application intercept ? It does not make sense to pass
> the whole tos msg pointer to an application if it is only interested
> in the payload and the rest of the interaction with the collection
> system (collect/Sink, collectRecv) is in terms of payload. On the
> other hand, to implement a generic network instrumentation using the
> Intercept interface will most likely require tos msg pointer in which
> why would we want to pass a pointer to the payload ?

The standard approach is to pass both as parameters to the event. The  
issue with passing only the application payload is that higher-level  
components can't choose to optimize in an implementation-specific  
manner. E.g., I can't ask an underlying layer what address the packet  
came from. Once you discard this parameter, it can't be passed  
further up.

Just because it's the standard approach so far, however, doesn't mean  
it's the right one. One of the design principles in 2.x is  
telescoping abstractions, that is, there's a spectrum of fine-grained  
abstraction layers, ranging from the most powerful and hardware  
specific to the most simple and portable. The names of the components  
and interfaces generally let you know where on the spectrum you're  
sitting. (E.g., Packet vs. AMPacket vs. CC2420Packet, this last one  
doesn't exist yet but probably will soon).

>
> We can do that in our reference implementation. But we are not
> suggesting that these behaviors are part of the "specification" of how
> one should write a forwarding engine/collection protocol in this
> framework ?

OK, makes sense. It was the combination of datagram-based intercept  
and chunk-based send that threw me off.

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'