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 1CB5E11E8097 for ; Wed, 18 Apr 2012 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 mjkqP5pi2aa5 for ; Wed, 18 Apr 2012 13:43:27 -0700 (PDT) Received: from kahuna.puaa.net (jwright145.dsl.frii.net [216.17.155.145]) by ietfa.amsl.com (Postfix) with ESMTP id AB6EC11E8091 for ; Wed, 18 Apr 2012 13:43:26 -0700 (PDT) Received: from kipu.bioserve.prv (bioserve.colorado.edu [128.138.158.99]) by kahuna.puaa.net (Postfix) with ESMTP id 08D2CE44789; Wed, 18 Apr 2012 14:43:20 -0600 (MDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4" From: Jim Wright In-Reply-To: <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> Date: Wed, 18 Apr 2012 14:43:20 -0600 Message-Id: References: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> <6FE448E4-0205-4852-97F6-A91D8E5C0E6F@nasa.gov> To: "Ivancic, William D. (GRC-RHN0)" X-Mailer: Apple Mail (2.1257) X-PuaaConsulting-MailScanner-Information: Please contact the ISP for more information X-PuaaConsulting-MailScanner-ID: 08D2CE44789.A5906 X-PuaaConsulting-MailScanner: Found to be clean X-PuaaConsulting-MailScanner-From: james.r.wright@colorado.edu 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:43:31 -0000 --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 not take custody of the bundle. Node C receives the bundle = and accepts custody. 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 already in the DTN, then my confusion is cleared up. If an = application wants custody transfer, and the originating 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 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 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. >=20 >=20 > 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? >=20 > 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. =20= >=20 > - Will >=20 >=20 >=20 > On Apr 18, 2012, at 3:58 PM, Jim Wright wrote: >=20 >> 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. >>=20 >> 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? >>=20 >> Thanks, >> Jim >>=20 >>=20 >>=20 >> --=20 >> Jim Wright >> BioServe Space Technologies >> james.r.wright@colorado.edu >> 303-492-1579 >>=20 >> _______________________________________________ >> dtn-interest mailing list >> dtn-interest@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-interest >=20 --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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 not take custody of = the bundle. Node C receives the bundle and accepts custody. 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 = already in the DTN, then my confusion is cleared up. If an application = wants custody transfer, and the originating 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 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 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
=
_______________________________________________
dtn-interest = mailing list
dtn-interest@irtf.org
https://www.ir= tf.org/mailman/listinfo/dtn-interest

<= /blockquote>

= --Apple-Mail=_2EEFD67A-F3C7-42F7-8B82-069A8DBBF8A4--