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

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

But I'd argue that you can do just as well with proactive fragmentation within the network.  "Would be nice" implies that there is some value in retransmitting 3 MB instead of all 10 MB of the bundle.  How much value is that?  If your link is running at 1 Gbps then the extra cost of not doing reactive fragmentation is .056 seconds of transmission, which you incur not for every bundle but only for the bundle that you're transmitting at the end of the contact.  If your mean contact duration is 5 minutes, then the cost of not doing retransmission is .0187% of your bandwidth.  Whereas if you are doing reactive fragmentation then you are paying for additional signaling traffic for all of your bundle transmissions; does the benefit of doing reactive fragmentation (that is, the cost of not doing it) outweigh that cost in additional bandwidth consumption?  (Certainly there's no other benefit, right?)

Okay, suppose your link is only 4800 bps.  Now the extra cost of not doing reactive fragmentation is 11,667 seconds of transmission -- unless you do proactive fragmentation at the time you start sending the bundle, i.e., you break off 600-byte fragments of the bundle one at a time and send them over the link.  Now when the link fails the cost of not doing reactive fragmentation is one entire bundle, but it's only 600 bytes long, still only 1 second of transmission.  Sure, you're paying more in overhead because you're sending more bundles, but you'd also be paying plenty more in overhead if you were sending reactive fragmentation signals fast enough to achieve the same effect.

This is of course a topic on which we've been arguing for over a decade in DTNRG and I am confident that I haven't changed many minds here.  I just want to suggest that it's possible to engineer DTN to be relatively efficient over an opportunistic contact without jettisoning bundle authentication.

Scott

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


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