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

["Fall, Kevin" <[e-mail]>]

Some comments below..

On 12/5/12 4:46 PM PST, "[e-mail]" <[e-mail]> wrote:

>
>> The DTN fragmentation has the same functionality as IP Fragmentation.
>
>only if you believe a bundle is a replacement for an IP packet, rather
>than being a replacement for a MIME-type file object. We've moved large
>bundles (hundreds of megabyte files) from orbit, so we believe that a
>bundle was not intended to be a little IP packet.

Right.  The DTN fragmentation isn't intended for the same purposes as IP
fragmentation.
While IP fragmentation is about adapting an abstract datagram (IP
datagram) to be carried on various underlying link layers, DTN
fragmentation is about dividing a big thing into chunks appropriate to
contacts (for proactive fragmentation) and to help in recovery for
unexpected outages (for reactive).

>
>> It is really used to get around limitations in the CLA link protocols.
>>In general, there is a practical limit on the size of a bundle, either
>>because of protocol limits (such as UDP), or contact time.
>
>Contact time (constrained by location/visibility/power) is often the
>driver in a delay tolerant network, especially when you're bringing
>across large amounts of sensor data. Protocol limits (such as LTP
>implementation 64K limitations) should not be a factor.

I also agree with Lloyd here.  There may be limitations in the current
implementation due to selections of the particular transport, but the
underlying shouldn't really be the driver for the top interface.

>
>Given the deficiencies in the bundle protocol design (reliability,
>clocking, etc.), the claim that the bundle protocol compensates for
>limitations in the CLA _transport_ protocols (again, bundle is not IP),
>when the reverse is obviously the reality (and there's a reason most
>bundle work has been done over TCP), is really rather amusing,

This is not correct.  Indeed the DTN architecture (and the BP) are
intended to deal with a certain set of underlying limitations (e.g., size
limitations, connectivity limitations, issues with interconnection of
disparate name space structures).  While I would also not call CLA
"transport protocols", the BP does pretty much what was intended.

- K

> 
>
>Lloyd Wood
>http://sat-net.com/L.Wood/dtn
>
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/dtn-interest