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

[Stephen Farrell <[e-mail]>]

Hi Scott,

On 28/04/14 18:40, Burleigh, Scott C (312G) wrote:
> Will's view here makes sense to me.  The initiative for requesting
> the BoF -- the first serious commercial interest in delay-tolerant
> networking that we've seen, I think -- is coming from Boeing.  I
> think it the energy behind the BoF initiative might evaporate if this
> conversation diverts that BoF initiative in a direction that diverges
> dramatically from Boeing's interests.

I agree. But its not clear to me what Boeing do envisage in
terms of minimal or more change vs. 5050. Maybe its clear to
others, but I didn't get that from the text Fred has sent
so far.

> In particular, the HTTP-DTN concept clearly merits serious
> consideration as a way of addressing the well-known challenges of
> delay-tolerant networking, but I don't think this BoF request
> discussion is the right place to try to conduct that serious
> consideration.  

I think Lloyd's http-dtn stuff is maybe one possible approach
but the issue of whether or not an IETF WG prioritises ease of
terrestrial deployment or prioritises minimal change to 5050
is basically independent of http-dtn. So we shouldn't get hung
up on a false dichotomy there.

> What I think would make more sense would be for a
> couple of experimental HTTP-DTN implementations to be developed and
> exercised in practical deployment scenarios, just as has been done
> with the DTNRG's BP-based protocol suite over the past decade, so
> that we can all get a better sense of the architecture's demonstrated
> advantages and disadvantages.  The DTNRG seems to me to be the right
> venue for that research.
> 
> Meanwhile, though, the experience of NASA, N4C, the U.S. Defense
> Department, Boeing, and others seems to indicate that the Bundle
> Protocol and adjunct protocols can be used to operate delay- and
> disruption-tolerant networks successfully.  

"Can be used" is correct. But to be fair, I'd have to say that
"can easily be used" is not correct for a bunch of use-cases,
including the N4C ones. And for others that I've investigated
since N4C finished. I'm not saying that 5050 doesn't work by
any means (modulo the known set of relatively minor things to
fix) but that its not really easy to deploy a DTN using 5050
and maybe that could be improved a lot if we do consider bigger
changes to 5050 for a 5050bis.

> This suggests that it
> could be advantageous to the networking community to standardize
> protocols derived from the DTNRG stack (certainly adopting some of
> the improvements to those protocols that have been proposed over the
> years).  I think that's the proposition that this BoF request
> conversation should be contemplating.

Personally, I think it'd be far more interesting if we did
not try to aim for minimal change to 5050, but were more ambitious
and tried for something that could get much broader deployment.
(While at the same time making sure one could easily gateway
from a 5050bis DTN to a 5050 DTN.)

But if minimal-change is what those who are proposing to do the
work want, then yes, that is what the BoF ought (clearly) propose
and what the IESG and IAB will evaluate. (And even though I'm
not fond of that plan myself, I'll be supportive of the work
being done if I think there's enough of a constituency for it
in the IETF.)

S.

> 
> Scott
> 
> -----Original Message----- From: dtn-interest
> [mailto:[e-mail]] On Behalf Of Ivancic, William
> D. (GRC-RHN0) Sent: Monday, April 28, 2014 6:25 AM To:
> [e-mail] Cc: [e-mail] Subject: Re:
> [dtn-interest] DTN BoF Proposal for IETF90
> 
> Fred,
> 
> Since Boeing is requesting the BOF, what is their (or your)
> perspective on the deployment scenario?
> 
> I know NASA is working to standardize RFC5050 as a space protocol via
> CCSDS (http://cwe.ccsds.org/sis/default.aspx#_SIS-DTN).  They don't
> appear to be concerned with the numerous known problems.
> 
> On the International Space Station, they are interested in using DTN
> to automatically buffer data and commands between Loss-of-Signal
> (LOS) and Acquisition-of-Signal (AOS).  See-
> http://ipnsig.org/wp-content/uploads/2014/02/ISS-DTN-Presentation-IPNSIG.pd
>
> 
f
> 
> DTN Goals are:
> 
> €Increase reliability of payload data transfers between ISS and
> remote payload control centers during AOS/LOS transitions €Increase
> automation of Payload Developer (PD) requests for data transfers
> €Alleviate extensive support to plan payload transfers around AOS/LOS
> and operator required transfers
> 
> Today, payload operations are highly scheduled and highly manned.
> But, with dramatic increases in uplink and downlink bandwidth to the
> payloads, the link utilization doesn't have to be so tightly
> controlled and automation to reduce manpower costs is highly
> desirable.  Note, the ISS DTN deployment is a very small scale
> network.
> 
> 
> 
> We need to understand what problem space we are addressing.  If it is
> the small space community, that can probably be handled by CCSDS.  If
> it is large scale terrestrial deployment, we need to understand that
> environment.
> 
> Will ******************************
> 
> 
> 
> 
> 
> On 4/28/14 8:51 AM, "Stephen Farrell" <[e-mail]>
> wrote:
> 
>> 
>> Hiya,
>> 
>> On 28/04/14 11:25, Joerg Ott wrote:
>>> 
>>> I don't disagree with this.  But I don't want to be presumptious
>>> on how the answer should look like either (which also implies not
>>> ruling out options).
>> 
>> Well, isn't that last more appropriate for an RG than a WG? I mean
>> we presumably don't want a WG that thrashes endlessly on the amount
>> of change vs. 5050 that's acceptable and I think that could happen
>> if we can't decide on this while chartering the putative WG.
>> 
>> I also think it might (not 100% sure) be the case that different
>> folks would be more or less interested in a WG depending on the
>> answer to this question, so another danger for chartering a WG
>> could be that if the answer to this question only emerges some
>> months down the road, then half the WG participants might lose
>> interest at that point and the whole thing might fizzle.
>> 
>> 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 
> _______________________________________________ dtn-interest mailing
> list [e-mail] 
> https://www.irtf.org/mailman/listinfo/dtn-interest
>