[dtn-interest] more on reactive fragmentation

["Burleigh, Scott C (312G)" <[e-mail]>]

Will, I well remember reading about how useful you found reactive fragmentation in the UK-DMC experiments, so I can understand why you now feel it is a requirement.  My thinking has developed in the opposite direction: I was a big fan of reactive fragmentation originally, but now I believe it's the wrong answer.  Here's my reasoning:
*       The problem we're trying to solve is the waste of bandwidth that is caused by needing to retransmit a large amount of data that has already been transmitted, simply because connectivity was lost part way through transmission of a single large indivisible protocol data unit (bundle).
*       Reactive fragmentation solves this problem by dynamically dividing the original large bundle at the time of connectivity loss: most or all of the portion that has already been transmitted becomes a new (fragmentary) bundle, and the residual portion that hasn't yet been transmitted likewise becomes a fragmentary bundle.
*       But reactive fragmentation is possible only when the receiving entity can somehow notify the sender of how much of the original bundle was received prior to the end of connectivity.  (Otherwise the sender has no idea of how much data it need not retransmit.)
*       So there has to be a constant stream of "I got this much" messages returned from the receiver to the sender.  Those messages constitute bandwidth consumption that to some extent offsets what you save by reactively fragmenting.  (And of course the handling of these messages also consumes processing cycles at both the sender and the receiver.)
*       The benefit (bandwidth savings) that you get from reactive fragmentation varies directly with the size of your bundles and the frequency of contact truncation.  If contact truncations are rare or if your bundles are small then the cost of enabling reactive fragmentation outweighs the benefit.
*       From the size of the "I got this much" messages and the rate at which they are returned, we can compute the minimum bandwidth savings that must result from reactive fragmentation in order for it to be cost justified.  Divide that by the estimated frequency of contact truncation and you get the minimum mean bundle size at which reactive fragmentation makes sense.  Now, if you proactively fragment bundles to never exceed that size, then reactive fragmentation is unnecessary.

That's why ION implements "just in time" proactive fragmentation, at the moment of transmission, rather than reactive transmission.  (I wrote a little about this a few days ago.)

When BP is running over TCP/IP in the terrestrial Internet, the probability of unanticipated contact truncation is extremely low, so mostly there's no point in bothering with proactive fragmentation.

When BP is running in a space link environment, it arguably ought to be running over LTP rather than TCP/IP.  In ION, LTP is driven by a plan of scheduled contacts, so again the probability of unanticipated contact truncation is low -- contact truncation happens all the time, but it's almost always anticipated.  Moreover, LTP segments outbound bundles anyway; the segments are usually pretty small, so if one gets lost due to contact truncation there's negligible waste of bandwidth.

(As an aside, there is an open work item to modify ION's LTP to proactively truncate an outbound bundle that is too large to fit within the expected remaining seconds of the current contact.  This enables part of the bundle to be transmitted in the current contact, fully utilizing the contact, and the rest may be transmitted on a subsequent contact, possibly with a different network neighbor.  And again you don't miss reactive fragmentation.)

In your UK-DMC experiments you were running BP in a space link environment over TCP/IP, and I'll admit that this is a configuration in which reactive fragmentation is a bacon-saving feature: you were sending big bundles and you had several unanticipated contact truncations.  But I'll argue that this is a configuration that we should stay away from, for this reason among others.

Scott

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]]
Sent: Friday, May 02, 2014 1:59 PM
To: Ivancic, William D. (GRC-RHN0); Burleigh, Scott C (312G); [e-mail]
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

On 02/05/14 21:24, Ivancic, William D. (GRC-RHN0) wrote:
> Some really nice slides from Scott- seriously.  I found these while
> preparing for a talk. These do a nice job of highlight the difference
> between CFDP and DTN.
>
> http://chapters.comsoc.org/comsig/Slides/Jan2004_BurleighS_IPN_DTN.pdf
>
>  Interesting that reactive fragmentation is called out.  I was not a
> big fan originally, but not I feel it is a requirement.
>
> Has anyone done reactive fragmentation over LTP?  I was the
> beneficiary over TCP.

Not with our LTP implementation. LTPlib and the LTPCL we implemented would handle the disruption the LTP session and not tell the BPA. Not sure about ION. Handing the problem back to the bundle layer at some point would be an idea but I've not looked to see if it'd be easy or hard to code up.

> Stephen, was your experience with reactive fragmentation over TCP or
> some other convergence layer?

The N4C stuff was all TCP.

Cheers,
S.