[net2-wg] Collection interface

[Omprakash Gnawali]

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

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 with your suggestion of looking at collection as a simple
datagram service (length limited by packet size, no absolute
guarantees about reliability) and leaving the possibility of
implementing other types of delivery/forwarding services on top of it
in the future.

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 ?

I am also interested in hearing from other folks what they had in mind
when we mentioned multiple sinks during our conversations. Does the
interface that I proposed addresses the multi-sink scenarios they had
in mind ?

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