Re: [dtn-interest] on ditching fragmentation

Leigh Torgerson wrote:
>
> Scott wrote:
>

>> I think all of the other motivations we've identified for 
>> fragmentation in Bundling derive from our (usually unconscious) 
>> assumption that bundles may be very large.  I think this is an 
>> unhelpful assumption.
>>

I think what you actually mean is "for any size payload that we want to send using bundling", and of course I agree with that. I'm pretty sure that nothing I said would be any more limiting than what we've got now.

In fact, the optional, general-purpose "DTN Fragmentation" protocol I proposed that we insert "above" bundling [maybe I should call it "DTN Segmentation" instead, since it's happening above the forwarding layer] could very much improve our ability to send extremely large payloads via bundling. The current Bundling spec limits the size of any single *original* bundle payload to 4 Gbytes; no matter what you do about fragmentation, Bundling can't reassemble a payload that's any bigger than that -- it's a hard limit on bundle size. But this notional DTN Segmentation protocol could use larger-than-32-bit integers (maybe SDNVs) to represent offsets and lengths within an original payload, so that (for example) a terabyte payload could be presented to it and split up into a gazillion payload fragments, each of which could be forwarded individually through the network in a single bundle of quite ordinary size, and the huge payload could be reassembled at the destination from the de livered (fragmentary) payloads of all those bundles. You can't do that now.

> Forcing a bundle to be restricted to a small maximum length (now you

No, you don't have to define "small" and you don't have to force a bundle to be restricted to any particular length. You just segment your payloads (as CFDP does, for example) before presenting them to Bundling for shipment; when you do this, you segment at sizes that make sense for your application and for the network environment you're working in, exactly as you would if you were doing proactive fragmentation within Bundling itself.

As for ATM-like inefficiency: yes, as I said, you have more bundle header overhead if you've got more bundles. You have this whether you fragment the payload within Bundling (generating multiple bundles) or segment it before presenting it to Bundling (and thereby generating multiple bundles). I don't think there's a lot of additional cost here.

> If we take fragmentation out of bundling, we've just pushed the problem

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related mailman.dtnrg.org Links dtn-interest Request more information about Pantek

Yes, that was what I was proposing.

> which might be OK - but if fragmentation is optional, and not implemented everywhere in a given network, we'd have efficiency

I don't think so. As I said, fragmentation to suit the transmission characteristics of individual links is something we already do at the convergence layer, underneath bundling. I quite carefully didn't say this requirement goes away. I just said it's better done someplace else -- someplace where in fact we are already doing it.

> If we make fragmentation a required part of a convergence layer (or overlay), then

Of course we do. However, I guarantee that we already have to specify interoperable standards at the convergence layer.

This is kind of the beauty of layering, though: you do end up with more protocols, but each one individually is simpler, therefore easier and cheaper to design and implement and maintain, and usually more robust. We can get arbitrarily complex and powerful behavior from the interaction of things that are individually simple enough to describe and reason about.

The idea that it is good to dump all possible functionality into a single protocol rather than break it apart into modules -- "layers" -- with clean interfaces is one that I hope we've gotten past by now. Complexity doesn't go away when you put it all in one box. It gets worse.

Scott

Do you need more help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related mailman.dtnrg.org Links dtn-interest Request more information about Pantek