Re: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct

Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Fri, 10 November 2006 16:05 UTC

Received: from nmta3.jpl.nasa.gov (nmta3.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAAG5QY01227 for <dtn-interest@mailman.dtnrg.org>; Fri, 10 Nov 2006 08:05:26 -0800
Received: from xmta1.jpl.nasa.gov (xmta1.jpl.nasa.gov [137.78.160.144]) by nmta3.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id kAAG5Llx017147 for <dtn-interest@mailman.dtnrg.org>; Fri, 10 Nov 2006 08:05:21 -0800
Received: from [127.0.0.1] (vpn-149-240-046.jpl.nasa.gov [128.149.240.46]) by xmta1.jpl.nasa.gov (Switch-3.1.9/Switch-3.1.9) with ESMTP id kAAG5Cis025106 for <dtn-interest@mailman.dtnrg.org>; Fri, 10 Nov 2006 08:05:19 -0800
Message-ID: <4554A338.7080207@jpl.nasa.gov>
Date: Fri, 10 Nov 2006 08:05:12 -0800
From: Scott Burleigh <Scott.Burleigh@jpl.nasa.gov>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: dtn-interest@mailman.dtnrg.org
Subject: Re: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE 30 Oct
References: <20061105200001.9649.82769.Mailman@webbie.berkeley.intel-research.net> <1163058566.4773.32.camel@lap10-c703.uibk.ac.at>
In-Reply-To: <1163058566.4773.32.camel@lap10-c703.uibk.ac.at>
Content-Type: multipart/alternative; boundary="------------050005070107010109000001"
X-Source-IP: vpn-149-240-046.jpl.nasa.gov [128.149.240.46]
X-Source-Sender: Scott.Burleigh@jpl.nasa.gov
X-AUTH: Authorized
Sender: dtn-interest-admin@mailman.dtnrg.org
Errors-To: dtn-interest-admin@mailman.dtnrg.org
X-BeenThere: dtn-interest@mailman.dtnrg.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>
List-Post: <mailto:dtn-interest@mailman.dtnrg.org>
List-Help: <mailto:dtn-interest-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-interest/>

Michael Welzl wrote:
>>> Hm, does that mean that any node that generates a BSR of any kind would have
>>> know in advance whether that message can reach its destination? That doesn't
>>> seem like a realistic assumption to me. Or am I misinterpreting the "members
>>> characterize the BSR issuance opportunity" part?
>>>       
>> Right, a two-sentence description of this notion isn't quite enough.  The intent is that BRLs are pre-placed in some or all of the nodes of the network (by some delay-tolerant mechanism that's maybe similar to the pre-placement of encryption keys or the pre-placement of routing information) and each BRL is in effect a statement that "This node is authorized to issue a BSR in the course of processing a bundle with status reporting flag X turned on, provided the source EID of the bundle is Y and the bundle's report-to EID is Z."  The BRL would say nothing about the likelihood that the BSR would reach the report-to, only about whether or not the BSR may be issued.  Where BSRs are absent, no BSRs are ever issued.
>>     
>
> That sounds very good to me - but I would suggest to realize this
> as per-flow *soft* state in the intermediate nodes, and not store
> BSRs in all nodes *in the network* but *along the path*. Now I know
> that paths are not supposed to stay up for long in DTNs, but maybe
> the assumption could be relaxed for this mechanism, as it's only
> for BSRs of a diagnostic nature anyway. By the way, I would only
> require this soft state mechanism for the per-bundle BSRs that
> we discussed, not for all BSRs.
>   
Having selected, potentially hazardous BRLs time out and expire sounds 
fine to me.  We absolutely do want to minimize the potential for 
production of destructive traffic.

I'm not quite so comfortable with the concept of pre-placing BRLs along 
a path, in part because discovery of the path might be part of the 
reason to establish the BRLs.  I can certainly see how one wouldn't want 
BRLs for traffic-tracing BSRs installed at every node in the network, 
and I wouldn't argue for that.  My notion is that the subset of nodes at 
which we'd install some set of mutually-referencing BRLs would be 
selected by whoever "owned" and/or was responsible for network 
management at those nodes and was interested in getting specific kinds 
of traffic handling information from them.  Membership in the subset 
would be more a function of administrative interest than of topology.

Scott