Re: [dtn-interest] Document status check

Alternatively the implementation just signals this constraint up from
the convergence layer to the bundle layer which engages the bundle
fragmentation mechanism to break large bundles up into smaller
ones. That was my original design intent for DTN2, but I never got
around to implementing it.

This is analogous to ethernet or other link layer MTU causing IP to
fragment large packets.

One could clearly design other convergence layers over UDP with
features such as fragmentation/reassembly, reliability, congestion
control, etc. From what I recall Saratoga is an example of just such a
protocol. But that doesn't mean there isn't room for a simple
datagram-based convergence layer as well.

-m

On Thu, Jul 29, 2010 at 9:52 AM, Ivancic, William D. (GRC-RHN0)
<william.d.ivancic@nasa.gov> wrote:
> I concur for TCP.
>
> The current UDP Convergence layer is rather limiting but is implemented in most if not all DTN implementations.  I would rather UDP not have all the limitations it does.  A better UDP convergence layer that doesn't limit one to 64kbyte packets would be preferred.
>
> - Will
>
>>-----Original Message-----
>>From: dtn-interest-bounces@maillists.intel-research.net [mailto:dtn-
>>interest-bounces@maillists.intel-research.net] On Behalf Of Daniel
>>Ellard
>>Sent: Thursday, July 29, 2010 12:28 PM
>>To: dtn-interest@maillists.intel-research.net
>>Subject: Re: [dtn-interest] Document status check
>>
>>On 7/29/10 10:59 AM, Stephen Farrell wrote:
>>>
>>> Hi all,
>>>
>>> As usual, there're a bunch of I-Ds with dtnrg in their
>>> name, so I'd just like to get a sense of the state-of-play
>>> for these. Feel free to reply to the list, or just Kevin
>>> and I.
>>>...
>>> If you think the draft should live, but no longer have
>>> cycles to work on it, then that's interesting too - we
>>> may be able to recruit some new authors.
>>> ...
>>> DTNRG expired:
>>>...
>>> 19 Nov 2008          draft-irtf-dtnrg-udp-clayer
>>> 03 Nov 2008          draft-irtf-dtnrg-tcp-clayer
>>
>>I am not an author or custodian of either of these, but am
>>willing to help keep them moving forward.  We (BBN anyway,
>>but I suspect nearly everyone else) use these all the time
>>and they should be moved forward to RFC status instead of
>>just being de facto standards.
>>
>>-Dan
>>
>>--
>>Daniel Ellard, Ph.D.
>>Senior Scientist, Network Research
>>BBN Technologies
>>10 Moulton Street
>>Cambridge, MA 02138
>>dellard@bbn.com
>>_______________________________________________
>>dtn-interest mailing list
>>dtn-interest@maillists.intel-research.net
>>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>