IETF Logo Mail Archive

Re: [dtn-interest] Custody transfer specification in RFC5050

"Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov> Wed, 18 April 2012 20:22 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 AB5CE11E8094 for <dtn-interest@ietfa.amsl.com>; Wed, 18 Apr 2012 13:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.307
X-Spam-Level:
X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqjDmCXpQPR9 for <dtn-interest@ietfa.amsl.com>; Wed, 18 Apr 2012 13:22:22 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by ietfa.amsl.com (Postfix) with ESMTP id 971FC11E8080 for <dtn-interest@irtf.org>; Wed, 18 Apr 2012 13:22:22 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id D04762D8523; Wed, 18 Apr 2012 15:22:21 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3IKMLo0003270; Wed, 18 Apr 2012 15:22:21 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Wed, 18 Apr 2012 15:22:20 -0500
From: "Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov>
To: Jim Wright <James.R.Wright@colorado.edu>
Date: Wed, 18 Apr 2012 15:22:42 -0500
Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050
Thread-Index: Ac0doPTMwgCLhHLNQFurmPh2NrPlWA==
Message-ID: <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>
References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu>
In-Reply-To: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-04-18_07:2012-04-18, 2012-04-18, 1970-01-01 signatures=0
Cc: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [dtn-interest] Custody transfer specification in RFC5050
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, 18 Apr 2012 20:22:26 -0000

I was just discussing custody transfer with a few colleagues.  I haven't gone into RFC5050 to confirm you confusion.  However, my understanding of  custody transfer is that if a node B accepts custody from node A, node A may decide to clear its storage.  Node B is suppose to then do its best to forward the bundle.  I believe node B can accept a bundle from node A without accepting custody and forward on to node C which accepts custody.  However, how does node C let node A know it has custody in a meaningful way if they are disconnected for long periods of time?  In the mean time, node A would likely NOT clear its storage until receiving an acknowledgement of custody acceptance from some node.


In reality, I think custody transfer is just a warm fuzzy good feeling for the space operations community.  In reality, if  node accepts a bundle, isn't it going to do its best to forward it?  If bundles are different sizes with different lifetimes and different priorities to different destinations, what is the proper algorithm to decide which to forward first?

I would like to see an analysis regarding custody transfer.  I would not be surprised to find out that custody transfer actually results in worse performance in complex networks.  If you are string network (A to B to C to D), it is likely to be a wash.  Furthermore, much depends on the routing algorithms used as well if if your system is multi-homed.

- Will



On Apr 18, 2012, at 3:58 PM, Jim Wright wrote:

I have been reading RFC5050 and specifically trying to understand the custody transfer mechanism. In my reading of RFC5050, I see no provision to allow for a Bundle Node to receive a bundle with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.

Is this correct? If it is not correct, and it is allowed to have a Bundle Node that receives and forwards bundles without taking custody, then where in RFC5050 is this specified?

Thanks,
Jim



--
Jim Wright
BioServe Space Technologies
james.r.wright@colorado.edu<mailto:james.r.wright@colorado.edu>
303-492-1579

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

v2.46.0 | Report a Bug | By Email | System Status