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

Hi Scott,

Yes, let's keep this thread focused on the higher level discussion. In
particular, how do we set focused chartered working group items so that
the working group can make progress while still having an avenue for
bringing in new work items as they are ready. Do you see it that the
DTNRG would be the forum for advanced development, and DTNWG as the
engineering standards body?

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

> -----Original Message-----
> From: Burleigh, Scott C (312G) [mailto:scott.c.burleigh@jpl.nasa.gov]
> Sent: Monday, April 28, 2014 1:46 PM
> To: Templin, Fred L; dtn-interest@irtf.org
> Subject: RE: [dtn-interest] DTN BoF Proposal for IETF90
> 
> Sorry, my fault for taking us down into the weeds on this thread; I will desist.  But one quick answer
> off the top of my head: I think the proactive fragmentation size I was talking about would function as
> the MBU you propose, controlling head-of-line blocking.  Configuring nodes to apply appropriate
> proactive fragmentation sizes would be a network management function, I think, and therefore something
> that might be addressed in the context of the DTN network management specs that APL and several NASA
> centers are working on.  Additionally, though, QoS in BP provides a way to defeat head-of-line
> blocking for small important bundles -- if they've got higher priority they ought to jump the queue of
> bigger ones, and if they don't then maybe it's not such a big deal if they wait for bigger bundles
> that are ahead of them.
> 
> But let's take continuation of this discussion, if any, to a new thread.
> 
> Scott
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Monday, April 28, 2014 1:32 PM
> To: Burleigh, Scott C (312G); dtn-interest@irtf.org
> Subject: 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