Re: [dtn-interest] DTN BoF Proposal for IETF90

Internet links have Maximum Transmission Units (MTUs). For IPv6, the
maximum MTU (i.e., the maximum IPv6 packet size) is 4GB (obviously,
most Internet links have considerably smaller MTUs). Then the path
MTU is the minimum of all link MTUs in the end-to-end path.

Similarly, paths between DTN nodes should have a Maximum Bundle Unit
(MBU). The MBU should be sized so that large bundles don't cause
unacceptable head-of-line blocking thus starving out smaller bundles.

So, an end-to-end DTN path may traverse many individual hops that have
diverse MBUs. But, each hop should have a well defined MBU so that
fragmentation can work correctly. Do we need text to this effect
in the specs?

Thanks - Fred
fred.l.templin@boeing.com 

> -----Original Message-----
> From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Burleigh, Scott C (312G)
> Sent: Monday, April 28, 2014 12:55 PM
> To: dtn-interest@irtf.org
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
> 
> Will, a comment along these lines: one alternative to reactive fragmentation, that is compatible with
> bundle authentication as currently spec'd, is "just in time" proactive fragmentation.  At the moment
> you de-queue a bundle for transmission you can retrieve its size, consider the data rate of your
> outbound link, and carve off (as a fragment) however much of the bundle you are willing to risk having
> to re-forward  in the event that the link is lost before transmission of the fragmentary bundle
> completes.
> 
> For example, if your original bundle is 400 MB and your outbound data rate is 8 Mbps, maybe you don't
> mind having to re-forward a bundle that takes only four seconds to transmit; in that case, you can
> proactively slice 4MB fragments off the outbound bundle 100 times and attach authentication to each
> fragment in the usual way.  Worst case on transmission failure is 4 seconds of wasted bandwidth, which
> normally you don't pay (because normally you don't lose the link), and the cost is an additional 99
> bundle headers -- which is offset by the fact that you no longer need additional protocol overhead at
> the convergence layer to support reactive fragmentation.
> 
> This approach is especially handy in environments where you know in advance the time at which the link
> will be turned off: you can size your outbound fragment to fit into however many seconds of
> transmission you've got left.
> 
> Scott
> 
> -----Original Message-----
> From: Ivancic, William D. (GRC-RHN0) [mailto:william.d.ivancic@nasa.gov]
> Sent: Monday, April 28, 2014 12:03 PM
> To: Stephen Farrell; Burleigh, Scott C (312G); dtn-interest@irtf.org
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
> 
> Stephen,
> 
> Thanks for that information.  Like with the UK-DMC, it appears reactive fragmentation saved you.  So,
> I suspect this deployment did not apply bundle security as reactive fragmentation and bundle security
> don't mix (if I recall correctly).  IMHO, this is the type of useful information from DTNRG
> deployments that we can use the generate the requirements.
> 
> Will
> 
> ******************************
> 
> 
> 
> 
> On 4/28/14 2:30 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> 
> >
> >
> >On 28/04/14 19:18, Ivancic, William D. (GRC-RHN0) wrote:
> >> To date, most everything I've seen has been small bundles (with the
> >> exception of the UK-DMC work).
> >
> >We were sometimes sending ~400MB bundles as part of one of the N4C
> >trials. It worked. IIRC one of 'em was split into
> >55 fragments and still got there in the end via different mules. It
> >wasn't fast though:-)
> >
> >Those large bundles were only needed when we wanted to overwrite all
> >the stored "pushed" HTTP web content so it wasn't a daily thing but it
> >did work when we had to do it.
> >
> >S.
> 
> 
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest