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

["Burleigh, Scott C (313B)" <[e-mail]>]

-----Original Message-----
From: Ivancic, William D. (GRC-RHN0) [mailto:[e-mail]] 
Sent: Wednesday, December 05, 2012 11:28 AM
To: Burleigh, Scott C (313B); John Zinky; [e-mail]
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects


> Erasure Coding embraces that architecture, but unfortunately Huge 
> Content (multiple GBs) can not go into one bundle. So this may be the 
> first use case where DTN must deal with the end-to-end transfer of GROUPS of bundles.
> 
>>>> 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?

>>>> But grouping of bundles is already handled by core BP 
>>>> (fragmentation and reassembly), and forwarding order is already 
>>>> handled by BP's class of service and the various routing 
>>>> mechanisms.  And does payload format actually have anything to do 
>>>> with erasure coding, or indeed with network operation at all?
>>>> Incorporating erasure coding into an end-to-end transfer service 
>>>> may indeed make a lot of sense, but that is the one piece of the 
>>>> picture that really
>>>> *should* be at a layer above BP.  It ought to be operating only at 
>>>> the ends, not at every bundle forwarding agent along the path.

Agreed.  Otherwise more things will break.

>>>> Given all of which, I don't see a strong argument for redesigning 
>>>> the Bundle Protocol.  What am I missing?

For erasure codes I agree. There are a whole lot of other reasons to redesign the protocol.  But that is another issue.

	>>>	Sure, I think we all have our lists of things we'd like to see changed in an RFC 5050bis.  But not quite yet.

> So the question for the community is:
> "How should a DTN protocol suite be designed that can handle the wide 
> range of Application with a wide range of QoS requirements?"

If you want it widely deployed, sure.

-Will