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

"Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov> Fri, 02 May 2014 15:09 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628D51A6FB4 for <dtn-interest@ietfa.amsl.com>; Fri, 2 May 2014 08:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.849
X-Spam-Level:
X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpQAwhbms5Ja for <dtn-interest@ietfa.amsl.com>; Fri, 2 May 2014 08:09:08 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 657AA1A0A0D for <dtn-interest@irtf.org>; Fri, 2 May 2014 08:09:08 -0700 (PDT)
Received: from mail.jpl.nasa.gov (ap-ehub-sp02.jpl.nasa.gov [128.149.137.149]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s42F95hG019420 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO) for <dtn-interest@irtf.org>; Fri, 2 May 2014 08:09:05 -0700
Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.218]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.03.0174.001; Fri, 2 May 2014 08:09:05 -0700
From: "Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov>
To: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Thread-Topic: [dtn-interest] DTN BoF Proposal for IETF90
Thread-Index: AQMd7bN+5AdKiKifsbMYUWPTP2/PtAJUPfgDAeDENgaYa9Y8AIACveQAgAAJYrA=
Date: Fri, 02 May 2014 15:09:04 +0000
Message-ID: <A5BEAD028815CB40A32A5669CF737C3B4238A33F@ap-embx-sp40.RES.AD.JPL>
References: <CAKovV0yoYztDz=6SVw_F2b5S-2OTay3CawgbtYFh=oT53vteAA@mail.gmail.com> <CF866276.161F8%william.d.ivancic@nasa.gov> <CAKovV0zTb7tMLkhUcmqXy=VBdpkovWEfag36TCwBa4CZHvacfg@mail.gmail.com>
In-Reply-To: <CAKovV0zTb7tMLkhUcmqXy=VBdpkovWEfag36TCwBa4CZHvacfg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.149.137.114]
Content-Type: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B4238A33Fapembxsp40RESAD_"
MIME-Version: 1.0
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-interest/8ou20ZDk9s_C9jSrsPbdi8RaRt0
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-interest/>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 15:09:12 -0000

I think this interesting discussion is a bit off-topic for this thread; how about moving it to a new one?

But while we’re here:

·         IPN did indeed have its origins in CFDP.  The original motivation for InterPlanetary Networking, as discussed in the very first meeting at MCI, was to devise a set of communication standards that would be more capable and more extensible than CFDP – a superset of what could be done with CFDP.

o   In that sense, CFDP was a prototype for IPN.  An entirely valid way of looking at the basic structure of IPN was to divide the CFDP monolith into three layers: the retransmission procedures of CFDP were eventually re-imagined in LTP, the CFDP store-and-forward overlay procedures were a crude checklist for the basic functionality of the Bundle Protocol, and CFDP itself would be whittled back to just file transfer, for which it was fine.

o   That said, I will certainly agree that most people involved in the early IPN work took their design ideas from their Internet experience rather than from familiarity with CFDP.  Ideas about IPN were always discussed in the context of what had already been shown to work (or not work) in the Internet.

·         DTN did indeed have its origins in IPN, but it immediately moved beyond those origins.  DARPA funded DTN not because they were eager for space networking but because they recognized that protocols that would solve the problems of space networking would solve some knotty terrestrial networking problems as well.

·         So while IPN was certainly space-centric, DTN is not.  Terrestrial DTN has gotten far more research attention than space networking.  The DTN protocols are usually designed to be suitable for use in space networking, because in most cases that has been the most challenging environment for them: with a few exceptions, if a protocol will work in deep space then getting it to work on the surface of Earth is easy.

·         In particular, I don’t see how DTN can be viewed as growing more space-centric than the IPN work was.

o   Virtually all research published on DTN routing addresses opportunistic connectivity, not scheduled connectivity.

o   I can’t think of any DTN Internet Drafts that presume fault tolerance.  Mechanisms for detecting data corruption, either in transit or in situ, have been included in DTN since the publication of RFC 6257.  One might not care for those mechanisms, but that in itself seems like a pretty slender argument for claiming that DTN is space-centric.

o   Universal clock synchronization via GPS or NTP is a capability that has specifically not been available to spacecraft.  In any case I think removing this dependence is an issue on which DTNRG had long ago reached agreement (the Bundle Age I-D) before turning its attention elsewhere.

All of which, I will suggest, is moot at this point.  The question at hand is who among us is interested in standardizing the DTN protocols within IETF and who is not.  I think we’ve already got some sense of this from the posts so far on this thread, and I think it would be good to hear some more.

Scott

From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Eric Travis
Sent: Thursday, May 01, 2014 11:38 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90

Will,

I'm a bit confused - which has caused me to pause prior to responding.

A few days ago in this thread, you expressed a concern about scalability:
Also, if we are talking large scale deployments, we really need to address
scalability.  To start with, I know some where investigating use of DTN
for thousands to tens of thousands of units.
Then in advocating an example for the need for bundle authentication mechanisms, you espoused possibly the least
scalable *policy* for using authentication.

In response to my subsequent blathering (not recopied, but available below), you reply:
It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.

However, your "I'm not about to let just anyone use my truck" example that led to my response was hardly advocating an "open" access policy... So, I suppose I am to take the quoted text to mean that there is no scalability issue with authentication?

I simply don't understand (nor can I agree to) for "closed" networks/systems, scaling is not all that much of a consideration relative to a global or universal deployment).
Hence, I am confused and curious, but more than willing to simply agree to disagree - with whatever happens to be the argument.
OK, so we're done with that.

Transitioning to the non-sequitur part of your message:

Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF

No.

and

No.

Addressing the Second No first - IPN/Bundling did NOT have its origins with CFDP.
You meant that  the Licklider Transmission Protocol (LTP) has its origins in CFDP. As I remember, LTP was influenced by and ultimately can (/does?) replace the "lower half" of CFDP. I *think* BP over LTP can be used in place of CFDP, but wouldn't trust that equivalence
to be correct.
Certainly CFDP experience influenced at least one of the IPN team members, but within the group, larger influences on the conceptual development of Bundling included SMTP, NNTP, UUCP - as well as the evolution of the US Postal Service (the Pony Express dominated discussions in the very earliest meetings).

http://www.ietf.org/rfc/rfc2821.txt
http://www.ietf.org/rfc/rfc3977.txt
https://www.ietf.org/rfc/rfc976
https://www.usps.com

All of which can be considered space centric.


Leading to the First No - "Much of Bundling always been space centric":

IPN leaf nodes (in situ networks) performing geological surveys while rolling around on a distant (extra-terrestrial) rock or floating atop the Bering Sea were considered equally valid and part of the same problem space.  If you mean to equate "space centric" with "not directly/permanently connected with the terrestrial internet", then your assumption is correct (IMHO).
(Speaking only for *myself*, not anyone else involved with the IPN study)

The defining characteristics underlying the IPN was the assumption that the problem space could *not* depend  on ubiquitous infrastructure (power, communications) - whatever infrastructure was required (including time synchronization) was to be provided
by the network itself. Nor could one assume the ultimate endpoints of communications would be supporting identical/pairwise-compatible communications stacks.   (At one point, there were Ten Commandments regarding IPN assumptions, but the above works for this discussion)

The concept did indeed start with the desire to lay the groundwork for supporting the eventual deployment  of IP-based networks as part of the exploration of the Solar System - so I concede that is a "space centric" goal.
The underlying "Interplanetary" meme provided a non-threatening backdrop to consider different ways of doing things.  This is analogous to the way Science Fiction has been used as a non-threatening means for exploring social issues.

The context for the IPN (and bundling) could just have easily been a terrestrial environment where nations start deploying national internets, each with their own naming/addressing systems and some with home-grown networking stacks (network and transport protocols).  Anticipating the deploying chunks of the Internet on and around remote rocks and snowballs was a much more fun/attractive playground.

Fanciful > Distopian.

There has never been anything in bundling mechanisms (IPN or DTN) that was "space centric". Space applicable, but not space centric.

But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.

Strangely, my feeling has been that, over time, DTN became MORE "space centric" than IPN.   Opportunistic connectivity seemed to be deprecated for deterministic connectivity, communications & storage components are considered to be more fault-tolerant and there seemed to be an increased reliance of infrastructure (universal clock synchronization via GPS or NTP). Consideration has seemed to favor deployments into rather controlled environments. Publication of RFC 5050 seemed to serve as a lock on Bundling development rather than being a stable checkpoint.  These are all simply my perceptions, but over time DTN tended to get less interesting (to me).

Actually, space is *very* large, but the space exploration environment is a lot better curated than a random terrestrial deployment. When deploying in the space exploration environment one is able to leverage off of a LOT of engineering and coordination.  The fact that you depict space a "simpler deployment environment" is a terrific illustration of this.
I'm far from the biggest fan of RFC-5050, but could someone please articulate what it is about the "protocol" that terrestrial users are finding "not very deployable"?   Once upon a time, I put up a few DTN2 nodes and didn't find it any more frustrating than deploying Apache or XMPP...


Regards,
Eric
eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>

On Wed, Apr 30, 2014 at 8:46 AM, Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>> wrote:
In Line

From: Eric Travis <eric.dot.travis@gmail.com<mailto:eric.dot.travis@gmail.com>>
Date: Wednesday, April 30, 2014 12:20 AM
To: William Ivancic <william.d.ivancic@nasa.gov<mailto:william.d.ivancic@nasa.gov>>
Cc: "l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>" <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>>, "stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>>, "Burleigh, Scott C (JPL-312G)[Jet Propulsion Laboratory]" <scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>>, "dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>" <dtn-interest@irtf.org<mailto:dtn-interest@irtf.org>>

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


Will,
Are you suggesting that the (originating) sender should be validated at each
transfer point (from Bob's truck to my truck to your truck)?

Not necessarily every transfer point, just transfer points that care.


If this is even possible,
it certainly won't scale.
Nor is it enforceable: What if Stephen enters into a secret side agreement with Lloyd to encapsulate bundles?

If they have such an agreement, I don't know that I care.

Way back in the days of the IPN (presumably back in the time "before
gaining experience with reality" - nod to Lloyd), we used to talk about
admissions control...  The bundle sender was to be verified at the entry
bundle portal. Only authorized sources could submit bundles.   As bundle
nodes were to be "mutually suspicious" [1], the interacting bundle nodes would
validate each other (at each contact episode) prior to exchanging bundles,
but  bundles would travel between nodes w/o requiring subsequent individual
source verifications (though there was to be a mandatory integrity check to verify
a content of the bundle was not altered by the intermediate "sending" node).

It seems like this assumes a closed system and thus, scaling is not all that much of a consideration relative to a global or universal deployment.
Much of Bundling has, IMHO, always been very space centric.   Understandably so, as it did start as Interplanetary Network (IPN) with origins in CFDP.
http://public.ccsds.org/publications/archive/720x1g3.pdf
http://public.ccsds.org/publications/documents/SO2002/SPACEOPS02_P_T5_22.PDF


But, once this hit DTRNG, I think the hope was to make this more universal, which opened up a complete new user space and expectations.  However, to date, the terrestrial users have not found the protocol, as is, very deployable.  Space is a much smaller and much simpler deployment environment.  In many ways, Space  is very small and extremely predictable.


Once the bundle was "in the system", there was no need to validate the source
of bundles in transit.
Rather than "not letting just anybody use your truck", you don't let just any
other truck driver offload it's contents into your truck.  Truck drivers are not
permitted to accept freight from unauthorized customers.

Thus, assumes a closed network.  No?






--
The problem with the world is that the intelligent people are full of doubts,
while the stupid ones are full of confidence.
                                                                                  - Charles Bukowski