[net2-wg] Collection interface

[Philip Levis]

On Dec 26, 2005, at 2:30 PM, Omprakash Gnawali wrote:

> 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.
>

There's another way to look at this problem, which is to consider  
whether you can implement one solution on top of the other.

A general assumption in existing TinyOS collection layers (e.g.,  
MintRoute) is that you could implement some kind of bulk data  
transfer on top of their routing engine. E.g., it's possible to use  
Intercept to take advantage of the built tree but actually perform  
per-hop fragmentation/assembly. Of course, this introduces overhead  
in terms of packet headers which might be unnecessary. So while you  
*can* do it, an integrated solution tends to be more efficient (and a  
lot more work).

I think it's clear that bulk data transfer is a class of network  
protocol that some applications need. However, I'd argue that its  
requirements, in terms of buffering, ACK/NACK, and failure edge  
cases, mean that it probably deserves a completely separate  
treatment. The best analogy I can come up with is collection:UDP ::  
bulk data transfer:TCP. Following the analogies, it also makes sense  
if the two don't necessarily have the same interface.

I think that, for now, we should focus on the simpler case: datagram- 
based collection. There's no question that chunk-based collection is  
needed, but it's a more difficult case. Maybe that should be item 3  
on our agenda?

> 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.
>

I am very leery of end-to-end, rather than per-hop, re-assembly. I  
know that Sukun Kim's STRAW protocol took this approach. The issue is  
that over multiple hops you're going to see an increase in packet  
loss, which can be much more easily repaired on a per-hop basis. E2E  
also requires a reverse path, which is possible, but introduces a  
whole new level of protocol complexity.

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'