Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

"Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov> Wed, 12 December 2012 14:00 UTC

Return-Path: <william.d.ivancic@nasa.gov>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF721F8967 for <dtn-interest@ietfa.amsl.com>; Wed, 12 Dec 2012 06:00:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level:
X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltm5vDD7A5zs for <dtn-interest@ietfa.amsl.com>; Wed, 12 Dec 2012 06:00:53 -0800 (PST)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by ietfa.amsl.com (Postfix) with ESMTP id 66CBF21F8964 for <dtn-interest@irtf.org>; Wed, 12 Dec 2012 06:00:52 -0800 (PST)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id D6439A8674; Wed, 12 Dec 2012 08:00:51 -0600 (CST)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt03.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id qBCE0gQT015067; Wed, 12 Dec 2012 08:00:51 -0600
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 12 Dec 2012 08:00:42 -0600
From: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>
To: Eric Travis <eric.dot.travis@gmail.com>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Date: Wed, 12 Dec 2012 08:00:48 -0600
Thread-Topic: [dtn-interest] DTN architecture issues for handling Huge Content Objects
Thread-Index: Ac3UwoCNb8V3z/zNSlW++6AZA4d28gDrpW3Q
Message-ID: <CCEDF840.DAFA%william.d.ivancic@nasa.gov>
In-Reply-To: <CAKovV0zcsYT5eNZMHtZxJqcPYE7ObCUP-r=o7WbreLJZX=1KiA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CCEDF840DAFAwilliamdivancicnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2012-12-12_03:2012-12-12, 2012-12-12, 1970-01-01 signatures=0
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.12
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: Wed, 12 Dec 2012 14:00:55 -0000

Sorry to not get back to you sooner.  Comments in line.

- Will


________________________________
From: Eric Travis <eric.dot.travis@gmail.com>
Date: Fri, 7 Dec 2012 15:33:28 -0600
To: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content Objects

Will,

If you could clarify - where do you believe the responsibility (and more importantly, the mechanisms) reside to authenticate the source of the bundle? (And by "source", do you mean what is in the bundle header or the node that is currently attempting to hand-off the bundle to you?)

Source is the originator of the data.

The protection of the local *resources* supporting bundle operation is *not* the responsibility of the bundle protocol.  Replace "bundle protocol" with another comparable DTN protocol and it still applies.

I sort of agree. But the mechanism must be there to allow one to authenticate the source in order to protect the system resources because the source is indirectly requesting to use those resources.  The way the RFC5050 and BSP are design, that task is difficult because one has to receive and entire bundle in order to authenticate.  For small bundles, this is not an issue, but for large bundles, it can be.

The issue of resource allocation is a separate area (and to me), far more complex one.  Peering agreements between mythical bundle operators would likely be interesting...  Even within a single operational network, the service policies are likely to vary on a node-by-node basis - the well connected bundle nodes having a differing demands on local resources than the more sparsely connected nodes.

Yes.  Agree completely.

Eric


On 12/7/12, Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov> wrote:
> IMHO, protecting the content is not the responsibility of the Bundle Agent
> but rather the user or application.  Think of email.  Email is encrypted by
> the user, not the IP layer.
>
> On the other hand, I would like to authenticate the source of the bundle,
> because I am not going to let just anyone use my resources (battery,
> storage, bandwidth, etc...).  IMHO, this is the major issue in deploying
> Store, Carry, and Forwarding distributed applications across domains owned
> and operated by various entities.  It is not an issue if you own the entire
> network (Military, US Space).  But, if you want to move across domains, the
> agreement to share some amount of resource is of major importance.
>
> - Will
>

On Fri, Dec 7, 2012 at 9:53 AM, Ivancic, William D. (GRC-RHN0) <william.d.ivancic@nasa.gov> wrote:
IMHO, protecting the content is not the responsibility of the Bundle Agent
but rather the user or application.  Think of email.  Email is encrypted by
the user, not the IP layer.

On the other hand, I would like to authenticate the source of the bundle,
because I am not going to let just anyone use my resources (battery,
storage, bandwidth, etc...).  IMHO, this is the major issue in deploying
Store, Carry, and Forwarding distributed applications across domains owned
and operated by various entities.  It is not an issue if you own the entire
network (Military, US Space).  But, if you want to move across domains, the
agreement to share some amount of resource is of major importance.

- Will


On 12/7/12 1:32 AM, "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk> wrote:

> Good to see the BP's lack of recognition of end-to-end considderation being
> addressed - even if it takes a higher layer to do it.
>
> "functionality that applies only in pairwise fashion between two neighboring
> nodes in the network belongs at that layer too"
>
> Question: with adding a higher layer, why bother with security in the bundle
> protocol? Implement end-to-end payload encryption in DTCP, you're done. That
> would greatly simplify bundling implementations across the network.
>
> Lloyd Wood
> http://sat-net.com/L.Wood/dtn
>
>
> ________________________________________
> From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] On Behalf
> Of Burleigh, Scott C (313B) [scott.c.burleigh@jpl.nasa.gov]
> Sent: 07 December 2012 01:50
> To: John Zinky; dtn-interest@irtf.org
> Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content
> Objects
>
> We may diverge a little bit on this, John.  I am a big fan of the layer-free
> extension of BP (and, to a lesser extent, LTP) that we can do in DTN, but I
> think there's still a place for layering.  In my earlier email I suggested
> that anything that has to do with operating the BP network itself belongs in
> extension blocks rather than in additional layers -- but that there are still
> application protocols that shouldn't be made part of BP, so they're at a
> different layer, and there are still underlying transport protocols that
> shouldn't be made part of BP, so they're also at a different layer.  The new
> application services we're looking at in DTPC seem to me to belong at an
> application layer above BP, not within BP itself.
>
> The analogy with TCP/IP is actually pretty close, I believe.  BP's functions
> need to be invoked at every forwarding agent along the end-to-end path, just
> like the IP functions.  But DTPC's functions are end-to-end only; they need to
> be invoked at the source and destination and nowhere else, just like the
> functions of TCP.
>
> That is, there's a sort of topological isomorphism that I find myself using in
> thinking about when it makes sense to layer and when it doesn't.
>
> Suppose we've got a chain of four nodes, A->B->C->D and we're sending a bundle
> from A to D.  Bundle protocol itself needs to operate at all four nodes:
> receiving the bundle, storing it, computing the route to forward it on, and
> forwarding it to the next node along that route.  We also want
> operator-specified class of service to be honored at every forwarding point,
> so something like ECOS belongs inside BP as an extension.  The metadata that
> describes the bundle might be consulted in route computation, so it too
> operates at every node and therefore belongs inside BP as an extension.  And
> so on.
>
> But the link between A and B is a space link, reinforced by LTP, while the
> B->C link is DCCP/UDP and the C->D link is TCP.  Since LTP runs only between
> nodes A and B it shouldn't be a BP extension; it belongs at the underlying
> convergence layer.  And other functionality that applies only in pairwise
> fashion between two neighboring nodes in the network belongs at that layer
> too, such as retransmission timeout interval computation that needs to be done
> in entirely different ways on different segments of the end-to-end path.
>
> The functions that are included in DTPC are things like end-to-end
> acknowledgment, end-to-end retransmission, resequencing received data into
> transmission order, that can only be done at the source and the destination.
> They're not functions that need to operate at all four nodes, so they don't
> belong inside BP as extensions.  These are functions that operate on a common
> topology, but it's not the topology that functions like route computation and
> class of service operate at -- it's the A<->D topology, not the A->B->C->D
> topology.  They belong at a different layer.
>
> Scott
>
> -----Original Message-----
> From: dtn-interest-bounces@irtf.org [mailto:dtn-interest-bounces@irtf.org] On
> Behalf Of John Zinky
> Sent: Thursday, December 06, 2012 2:30 PM
> To: dtn-interest@irtf.org
> Subject: Re: [dtn-interest] DTN architecture issues for handling Huge Content
> Objects
>
> Scott,
> I hope that your new application services will put their headers as extension
> blocks and not layer them inside the bundle payload. I was really encouraged
> by your previous posts about non-layered protocols!
>
> On Dec 6, 2012, at 3:46 PM, "Burleigh, Scott C (313B)"
> <scott.c.burleigh@jpl.nasa.gov> wrote:
>
>> It would be a standardized application service layer -- similar to a
>> transport layer -- running immediately above BP.
>
> On Dec 5, 2012, at 1:53 PM, "Burleigh, Scott C (313B)"
> <scott.c.burleigh@jpl.nasa.gov> wrote:
>
>> Which it already has, to some extent, because additional features such as QoS
>> are added in extension blocks (e.g., BSP and Extended Class of Service)
>> rather than in additional layers.
>
>> The only DTN extension blocks that can be said to nest are the BSP
>> extensions, and I there's a strong argument for removing that nesting as
>> well.
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-interest


******************************
William D. Ivancic
Phone 216-433-3494 <tel:216-433-3494>
Fax 216-433-8705 <tel:216-433-8705>
Networking Lab 216-433-2620 <tel:216-433-2620>
Mobile 440-503-4892 <tel:440-503-4892>
http://roland.grc.nasa.gov/~ivancic


_______________________________________________
dtn-interest mailing list
dtn-interest@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-interest