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

["Templin, Fred L" <[e-mail]>]

Hi Stephen,

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, April 28, 2014 3:13 PM
> To: Templin, Fred L; Burleigh, Scott C (312G); [e-mail]
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
> 
> 
> Hi Fred,
> 
> On 28/04/14 23:02, Templin, Fred L wrote:
> > 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
> 
> Is your/Boeing's preference to try to keep as close to 5050 as
> possible for a 5050bis or are you also considering changes that
> are less minimal, e.g. along the lines I've been discussing?
> 
> I think it will help to be very clear about that and is needed
> to get to the focused charter you describe above.

I submitted some mini problem statement drafts that touch on areas
that I think would need to be addressed in a 5050bis, but my list
was not exhaustive. Scott also posted a laundry list of 5050bis
candidate items last year. In terms of Boeing's interests, security
is a high priority for us for what we think we need in the near term.
 
> > 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?
> 
> I think the topic is the BoF though, if a WG is formed the above
> is pretty obvious for as long as DTNRG exists I guess.

OK, and yes we want to stay focused on the BoF.

Thanks - Fred
[e-mail]

> Ta,
> S.
> 
> 
> >
> > Thanks - Fred
> > [e-mail]
> >
> >> -----Original Message-----
> >> From: Burleigh, Scott C (312G) [mailto:[e-mail]]
> >> Sent: Monday, April 28, 2014 1:46 PM
> >> To: Templin, Fred L; [e-mail]
> >> 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:[e-mail]]
> >> Sent: Monday, April 28, 2014 1:32 PM
> >> To: Burleigh, Scott C (312G); [e-mail]
> >> 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
> >> [e-mail]
> >>
> >>> -----Original Message-----
> >>> From: dtn-interest [mailto:[e-mail]] On Behalf Of
> >>> Burleigh, Scott C (312G)
> >>> Sent: Monday, April 28, 2014 12:55 PM
> >>> To: [e-mail]
> >>> 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:[e-mail]]
> >>> Sent: Monday, April 28, 2014 12:03 PM
> >>> To: Stephen Farrell; Burleigh, Scott C (312G); [e-mail]
> >>> 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" <[e-mail]> 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
> >>> [e-mail]
> >>> https://www.irtf.org/mailman/listinfo/dtn-interest
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/dtn-interest
> >
> >