[net2-wg] Collection interface

[Omprakash Gnawali]

> > Because we want it to be an application defined data type, I think we
> > should support arbitrary length data. Of course there is always a size
> > limit because of the platform but this seems to be the wrong place to
> > impose such constraint. If Cyclops applications want to ship the image
> > to the sink, they will appreciate this functionality.
> >
> 
> What does Intercept mean if you can send arbitrary-length objects?  
> I.e., how do you give the upper layer information on the  
> fragmentation/defragmentation?
> 
> Do you assume that objects are re-assembled on a per-hop basis, or  
> that it's end-to-end? In the former case, how do you allocate  
> buffering space?


Phil, thanks for your comment. What I was saying about the existence
of Intercept interface and end-to-end reassembly are contradictory. If
we provide the Intercept interface and fragmentation is allowed, we
would have to reassemble the packets on a per-hop basis.

The real question here seems to be if we want the application writers
to do their own fragmentation or should the collection layer provide
fragmentation. We should decide this based on how common the two cases
are:

1. Streaming data or data logically divided into small chunks. You are
already planning to call a series of Collect call every epoch or
logical slice of the data. For this scenario, it does not seem helpful
to provide fragmentation by the collection protocol because
"fragmentation" is part of the application logic and it is natural to
make several Collect calls.

2. Periodic chunks of data that do not fit in a packet. For example,
you operate a camera and the image that it returns is 1K. Or, you
command a vibration sensor for two seconds and the data it generates
is 500 bytes. In such scenarios when the data is generated in one-shot
and is logically one unit of data, the application developer will have
to provide fragmentation functionality.

For the second scenario, I still think it will be useful to have
fragmentation provided by the collection but I can not decide how
common the second scenario is.



> If re-assembly is end-to-end, then you do assume end-to-end NACKs/ACKs?

NACK will probably be preferable in most cases but I think it is up to
the designer of the forwarding engine to implement whatever is
appropriate for that particular engine. So, my preference is to not
make assumptions about NACK/ACK. Most forwarding engines will probably
only offer best-effort reliability - nothing beyond per-hop
retransmission to enhance reliability.