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 AB5CE11E8094 for ; 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 ; 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 ; 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)" To: Jim Wright 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" 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:22:26 -0000 --_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_6FE448E40205485297F6A91D8E5C0E6Fnasagov_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 forwa= rd the bundle.  I believe node B can accept a bundle from node A witho= ut 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 acknowledgeme= nt of custody acceptance from some node.


In reality, I think custody transfer is just a warm fuzzy good feelin= g for the space operations community.  In reality, if  node accep= ts 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 di= fferent destinations, what is the proper algorithm to decide which to forwa= rd first?

I would like to see an analysis regardin= g 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. &n= bsp;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 W= right wrote:

I have been reading RFC5050 and spec= ifically 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 bun= dle with the Custody Transfer Request bit set and simply forward it on, wit= hout taking custody of the bundle. It seems every Bundle Node MUST implemen= t custody transfer.

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

Thanks,
Jim


=
-- 
Jim Wright
BioServe Space Technologies
<= a href=3D"mailto:james.r.wright@colorado.edu">james.r.wright@colorado.edu
303-492-1579

_______________________________________________
dtn-interest m= ailing list
dtn-interest@irtf.o= rg
https://www.irtf.org/mailman/listinfo/dtn-interest

= --_000_6FE448E40205485297F6A91D8E5C0E6Fnasagov_--