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

"Ivancic, William D. (GRC-RHN0)" <william.d.ivancic@nasa.gov> Wed, 18 April 2012 21:10 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 1A5B321F84A7 for <dtn-interest@ietfa.amsl.com>; Wed, 18 Apr 2012 14:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.356
X-Spam-Level:
X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, 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 7p9-AGnla681 for <dtn-interest@ietfa.amsl.com>; Wed, 18 Apr 2012 14:10:30 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by ietfa.amsl.com (Postfix) with ESMTP id 89BCD21F84A1 for <dtn-interest@irtf.org>; Wed, 18 Apr 2012 14:10:30 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id ED8E7260864; Wed, 18 Apr 2012 16:10:29 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02-pub.ndc.nasa.gov [198.117.1.161]) by ndjsppt04.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id q3ILATNB019615; Wed, 18 Apr 2012 16:10:29 -0500
Received: from NDJSSCC07.ndc.nasa.gov ([198.117.4.178]) by ndjshub02.ndc.nasa.gov ([198.117.1.161]) with mapi; Wed, 18 Apr 2012 16:10:29 -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 16:10:51 -0500
Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050
Thread-Index: Ac0dp662QDX8ySSzSYaVDCaNCyg39g==
Message-ID: <408DC84E-6E39-44E9-AD7D-D02BFF9C9330@nasa.gov>
References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> <DD4BBBCC-0C4E-4C3B-ADBB-993D8112198B@colorado.edu>
In-Reply-To: <DD4BBBCC-0C4E-4C3B-ADBB-993D8112198B@colorado.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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_08: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 21:10:31 -0000

On Apr 18, 2012, at 4:43 PM, Jim Wright wrote:

> I think custody transfer is more than a warm fuzzy, it is an important part of the store-and-forward routing in DTN. Custody transfer acknowledgement allows a node to clear a stored bundle. Without that the only way to flush bundles from a node's storage would be through timeout.
> 

I reiterate:   

if  node accepts a bundle, isn't it going to do its best to forward it - custody accepted or not? 

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?

If C cannot contact A with Custody Accepted, but forwards A's bundle on and the bundle reaches its final destination, A either re-forwards to another node; or the bundle times out on A and A does not release storage.  Or, A can release storage if needed because it knows B at least got the bundle and "hopefully" forwarded it on. 

Think "Disconnected Networks."  Think beyond Space Networks.


- Will