Return-Path: 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 77B2C11E8095 for ; Wed, 18 Apr 2012 13:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 ClxHPVkEhB6k for ; Wed, 18 Apr 2012 13:57:44 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 57FFD21E801E for ; Wed, 18 Apr 2012 13:57:44 -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.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3IKvgLg026548 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 18 Apr 2012 13:57:42 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.170]) by ap-ehub-sp02.RES.AD.JPL ([fe80::dd85:7b07:1e36:7e3c%15]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 13:57:42 -0700 From: "Burleigh, Scott C (313B)" To: Jim Wright , "Ivancic, William D. (GRC-RHN0)" Thread-Topic: [dtn-interest] Custody transfer specification in RFC5050 Thread-Index: AQHNHZ3y3VFz0gABUU+zvnTAjjjH75ahfCAAgAAFxAD//41cGg== Date: Wed, 18 Apr 2012 20:57:40 +0000 Message-ID: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov>, In-Reply-To: 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_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:57:48 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim, yes, section 5.2 does pertain only to initial issuance of a bundle, bu= t 5.4 applies on every transmission of a bundle including the first. I thi= nk the more general answer to your question is in the second paragraph of 5= .10: each node makes its own decision as to whether or not to take custody = of each bundle for which custodial transmission was requested. Scott ________________________________ From: dtn-interest-bounces@irtf.org [dtn-interest-bounces@irtf.org] on beha= lf of Jim Wright [james.r.wright@colorado.edu] Sent: Wednesday, April 18, 2012 1:43 PM To: Ivancic, William D. (GRC-RHN0) Cc: dtn-interest@irtf.org Subject: Re: [dtn-interest] Custody transfer specification in RFC5050 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. Regarding your example, I believe this happens: Node A sends a bundle with the Custody Transfer Requested bit set, and the = Request Reporting of Custody Acceptance bit set. The bundle is sent to node= B. Node B receives the bundle and forwards it to node C, but node B does n= ot take custody of the bundle. Node C receives the bundle and accepts custo= dy. Node C looks in the dictionary to find the Custodian EID, and sends an = administrative record bundle to node A to signal custody acceptance. Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission deals = only with initial transmission from an application agent (getting a bundle = into the DTN), and if section 5.4 Bundle Forwarding deals with bundles alre= ady in the DTN, then my confusion is cleared up. If an application wants cu= stody transfer, and the originating node does not support that, then fail i= mmediately. I was reading 5.2 as being a required step for forwarding of bu= ndles in the network. So does this make sense and answer my question? Jim On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote: I was just discussing custody transfer with a few colleagues. I haven't go= ne into RFC5050 to confirm you confusion. However, my understanding of cu= stody 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 forw= ard the bundle. I believe node B can accept a bundle from node A without a= ccepting 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 w= ith 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 perf= ormance 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 algor= ithms 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 custo= dy transfer mechanism. In my reading of RFC5050, I see no provision to allo= w for a Bundle Node to receive a bundle with the Custody Transfer Request b= it set and simply forward it on, without taking custody of the bundle. It s= eems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a Bundle N= ode that receives and forwards bundles without taking custody, then where i= n RFC5050 is this specified? Thanks, Jim -- Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jim, yes, section 5.2 does pertain only to initial issuance of a bun= dle, but 5.4 applies on every transmission of a bundle including the first.=  I think the more general answer to your question is in the second paragraph of 5.10: each node makes its o= wn decision as to whether or not to take custody of each bundle for which c= ustodial transmission was requested.

Scott
From: dtn-interest-bounces@irtf.org [dtn= -interest-bounces@irtf.org] on behalf of Jim Wright [james.r.wright@colorad= o.edu]
Sent: Wednesday, April 18, 2012 1:43 PM
To: Ivancic, William D. (GRC-RHN0)
Cc: dtn-interest@irtf.org
Subject: Re: [dtn-interest] Custody transfer specification in RFC505= 0

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 acknowledge= ment allows a node to clear a stored bundle. Without that the only way to f= lush bundles from a node's storage would be through timeout.

Regarding your example, I believe this happens:

Node A sends a bundle with the Custody Transfer Requested bit set, and= the Request Reporting of Custody Acceptance bit set. The bundle is sent to= node B. Node B receives the bundle and forwards it to node C, but node B d= oes not take custody of the bundle. Node C receives the bundle and accepts custody. Node C looks in the dictio= nary to find the Custodian EID, and sends an administrative record bundle t= o node A to signal custody acceptance.


Hmm, maybe I've found my problem. If section 5.2 Bundle Transmission d= eals only with initial transmission from an application agent (getting a bu= ndle into the DTN), and if section 5.4 Bundle Forwarding deals with bundles= already in the DTN, then my confusion is cleared up. If an application wants custody transfer, and the originati= ng node does not support that, then fail immediately. I was reading 5.2 as = being a required step for forwarding of bundles in the network. So does thi= s make sense and answer my question?

Jim


On Apr 18, 2012, at 2:22 PM, Ivancic, William D. (GRC-RHN0) wrote:
I was just discussing custody transfer with a few colleagues.  I = haven't gone into RFC5050 to confirm you confusion.  However, my under= standing 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 a= nd 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 t= ime, node A would likely NOT clear its storage until receiving an acknowled= gement 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 accept= s a bundle, isn't it going to do its best to forward it?  If bundles a= re different sizes with different lifetimes and different priorities to different destinations, what is the proper algorit= hm to decide which to forward first?

I would like to see an analysis regarding custody transfer.  I wo= uld not be surprised to find out that custody transfer actually results in = worse performance in complex networks.  If you are string network (A t= o 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 specifi= cally 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 Bun= dle Node that receives and forwards bundles without taking custody, then wh= ere in RFC5050 is this specified?

Thanks,
Jim



-- 
Jim Wright
BioServe Space Technologies
303-492-1579

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


--_000_A5BEAD028815CB40A32A5669CF737C3B03ED93apembxsp40RESADJP_--