Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

["Ivancic, William D. (GRC-RHN0)" <[e-mail]>]

>>>>> Is this really true?  Payload size is an SDNV, and bundle
>>>>> fragmentation in DTN is pretty well defined; there's nothing in the
>>>>> spec to prevent you from sending a Huge Content item in a single
>>>>> bundle, then proactively fragmenting that bundle into N fragmentary
>>>>> bundles.  The fragments would then be forwarded to the destination
>>>>> endpoint, where their fragmentary payloads would be reassembled
>>>>> into the original Huge Content item for delivery.  In this sense,
>>>>> dealing with the end-to-end transfer of a group of related bundles has
>>>>> been covered by DTN for many years, right?
> 
> But Reactive Fragmentation  and proactive fragmentation in the middle of a
> transmission and Bundle Security do not mix.  FEC may not have this problem if
> done at the source.  It is analogous to proactive fragmentation then securing
> each bundle.
> 
>>>>     Will, I think that might well be an argument against doing reactive
>>>> fragmentation and/or mid-stream proactive fragmentation (though I'm not
>>>> altogether convinced of this).  But the fact remains that core BP already
>>>> handles end-to-end transfer of groups of related bundles, right?
> 
Scott, About 2008 or so we showed the usefulness of reactive fragmentation.
In a scheduled network where everything is know and transport delays between
systems may be long, reactive fragmentation may not be to useful, but for
opportunistic networks, reactive fragmentation is likely to be the norm.
You don't know how long the contact will be or when it will end.  You have
sent 7 Mbytes of a 10 Mbyte file.  It sure would be nice to just send the
remainder.  But BPS and reactive fragmentation don't mix in the current
design.

- Will