Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability
From: Adrian Hooke <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 30 Nov 2009 20:56:14 -0500 (GMT-05:00)
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

On 30 Nov 2009 L. Wood wrote:
> I'll note that my team was the first to raise the 
> reliability and time/clock issues with the bundle protocol, 

Who, exactly, are the members "my team"? Are they an organized band of active DTNRG dissidents, or is "my team" just you?

> and that "A Bundle of Problems" is the first peer-reviewed 
> conference paper describing those issues in detail.

Did your peer reviewers also "peer review" the presentation that you made -- 

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems-slides.pdf

-- a presentation that many would regard (at best) as being self-serving and trite?

///adrian hooke

Date: Mon, 30 Nov 2009 12:32:36 -0800 (PST)
From: =?iso-8859-1?Q?savanted1=A9?= <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] (no subject)
Reply-To: [email-masked]

--0-141283209-1259613156=:76354
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Dear, Esteemed Forum Professionals
=A0
=A0 Does any subsonic activity involving the sound barrier affect the DTN B=
undle and its associated protocols while traversing in any manner in partic=
ular within the reenrty of space craft or the takeoff sequences after lifto=
ff and leaving the Earth's gravitational pull?
=A0
Very Respectfully

Savanted1=A9Mr. Garrett Hord=20
Towson University Computer Science / Mathematics
ACFE Associate Member
ACP International
Infragard Baltimore Chapter
__|__=20
-@--@--(_)--@--X--=20
[email-masked]
[email-masked]
[email-masked]
Engineering Science To Watch All Networks
http://www.securitytalks.com http://spaces.msn.com/members/savantedlyspeaki=
ng/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
FOR OFFICIAL USE ONLY: This message may contain personnel data or informati=
on covered by the Privacy Act of 1974. Please ensure this information is pr=
otected from unauthorized access and/or disclosure.=20
This electronic message contains information which may be privileged and/or=
 confidential. The information is intended for use only by the individual(s=
) or entity named/indicated above. If you are not the identified/intended r=
ecipient, be aware that any disclosure, copying, distribution, or use of th=
e contents of this message/information is prohibited.=0A=0A=0A      
--0-141283209-1259613156=:76354
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV>Dear, Esteemed Forum Professionals</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp; Does any subsonic activity involving the sound barrier affect t=
he DTN Bundle and its associated protocols while traversing in any manner i=
n particular within the reenrty of space craft or the takeoff sequences aft=
er liftoff and leaving the Earth's gravitational pull?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Very Respectfully<BR><BR>Savanted1=A9Mr. Garrett Hord <BR>Towson Unive=
rsity Computer Science / Mathematics<BR>ACFE Associate Member<BR>ACP Intern=
ational<BR>Infragard Baltimore Chapter<BR>__|__ <BR>-@--@--(_)--@--X-- <BR>=
[email-masked]<BR>[email-masked]<BR>[email-masked]<BR>E=
ngineering Science To Watch All Networks<BR>http://www.securitytalks.com ht=
tp://spaces.msn.com/members/savantedlyspeaking/<BR>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>FOR OFFICIAL USE ONLY: This m=
essage may contain personnel data or information covered by the Privacy Act=
 of 1974. Please ensure this information is protected from unauthorized acc=
ess and/or disclosure. <BR>This electronic message contains information whi=
ch may be privileged and/or confidential. The information is intended for u=
se only by the individual(s) or entity named/indicated above. If you are no=
t the identified/intended recipient, be aware that any
 disclosure, copying, distribution, or use of the contents of this message/=
information is prohibited.</DIV></td></tr></table><br>=0A=0A=0A=0A      
--0-141283209-1259613156=:76354--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Mon, 30 Nov 2009 10:58:59 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of	bundle reliability

Lloyd, your remarks on this thread have gone well past the point of being informative or constructive in any way.  Everyone on this list is amply aware of the points you note, and is already giving them exactly the consideration they merit.  Let's move on.

Scott
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lloyd Wood [[email-masked]]
Sent: Monday, November 30, 2009 10:18 AM
To: Stephen Farrell
Cc: [email-masked]; Lloyd Wood
Subject: Re: [dtn-interest] noting paper commenting on practical effects of     bundle reliability

On 30 Nov 2009, at 16:34, Stephen Farrell wrote:
> some of which are in the process of being fixed and
> all of which have been discussed on this list and
> elsewhere. The paper also lists some things on which
> we're still working. I don't recall seeing anything
> new in the paper.

Frankly, that's marketing whitewash.

I'll note that my team was the first to raise the reliability and time/clock issues with the bundle protocol, and that "A Bundle of Problems" is the first peer-reviewed conference paper describing those issues in detail.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Lloyd Wood <[email-masked]>
Date: Mon, 30 Nov 2009 18:18:58 +0000
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 30 Nov 2009, at 16:34, Stephen Farrell wrote:
> some of which are in the process of being fixed and
> all of which have been discussed on this list and
> elsewhere. The paper also lists some things on which
> we're still working. I don't recall seeing anything
> new in the paper.

Frankly, that's marketing whitewash.

I'll note that my team was the first to raise the reliability and time/clock issues with the bundle protocol, and that "A Bundle of Problems" is the first peer-reviewed conference paper describing those issues in detail.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Lloyd Wood <[email-masked]>
Date: Mon, 30 Nov 2009 17:02:36 +0000
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 30 Nov 2009, at 16:34, Stephen Farrell wrote:

> If you want an honest opinion of your paper, I guess
> my overall reaction would be that it describes a small
> number of minor things that we could fix with the BP,

They're always minor unless they're security-related, eh, Stephen?

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Mon, 30 Nov 2009 16:34:36 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

Hi Lloyd,

I assume you meant me rather than Marshall.

Lloyd Wood wrote:
> That was a response to Scott's 'anemic', and you are quoting out of context.

True. Attempted humour I guess. Perhaps that wasn't
obvious.

> If that's the best rebuttal you can produce...

Its not, but I have other things to do.

If you want an honest opinion of your paper, I guess
my overall reaction would be that it describes a small
number of minor things that we could fix with the BP,
some of which are in the process of being fixed and
all of which have been discussed on this list and
elsewhere. The paper also lists some things on which
we're still working. I don't recall seeing anything
new in the paper.

Stephen.

> 
> On 30 Nov 2009, at 14:52, Marshall Eubanks wrote:
> 
>> On Nov 30, 2009, at 7:08 AM, Stephen Farrell wrote:
>>
>>>
>>> Lloyd Wood wrote:
>>>> Why, yes, the list of issues in "A Bundle of Problems" is only an anaemic sixteen pages long.
>>> Citing the thickness of your argument is not really
>>> convincing:-)
>>>
>> We called it "science by the pound" when I was in the US Government, and
>> it was certainly _viewed_ as convincing.
>>
>> Regards
>> Marshall
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 
> 

From: Lloyd Wood <[email-masked]>
Date: Mon, 30 Nov 2009 15:33:15 +0000
To: Marshall Eubanks <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

That was a response to Scott's 'anemic', and you are quoting out of context.

If that's the best rebuttal you can produce...

On 30 Nov 2009, at 14:52, Marshall Eubanks wrote:

> 
> On Nov 30, 2009, at 7:08 AM, Stephen Farrell wrote:
> 
>> 
>> 
>> Lloyd Wood wrote:
>>> Why, yes, the list of issues in "A Bundle of Problems" is only an anaemic sixteen pages long.
>> 
>> Citing the thickness of your argument is not really
>> convincing:-)
>> 
> 
> We called it "science by the pound" when I was in the US Government, and
> it was certainly _viewed_ as convincing.
> 
> Regards
> Marshall

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Marshall Eubanks <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 30 Nov 2009 09:52:38 -0500
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On Nov 30, 2009, at 7:08 AM, Stephen Farrell wrote:

>
>
> Lloyd Wood wrote:
>> Why, yes, the list of issues in "A Bundle of Problems" is only an  
>> anaemic sixteen pages long.
>
> Citing the thickness of your argument is not really
> convincing:-)
>

We called it "science by the pound" when I was in the US Government, and
it was certainly _viewed_ as convincing.

Regards
Marshall

> Stephen.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Mon, 30 Nov 2009 12:08:46 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

Lloyd Wood wrote:
> Why, yes, the list of issues in "A Bundle of Problems" is only an anaemic sixteen pages long.

Citing the thickness of your argument is not really
convincing:-)

Stephen.

From: Lloyd Wood <[email-masked]>
Date: Fri, 27 Nov 2009 17:57:25 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 27 Nov 2009, at 17:29, Burleigh, Scott C (313B) wrote:

> I think people look at this rather anemic list of issues and figure hey, if these are the only things anyone's found to complain in ten years of DTN technology development, this stuff must be pretty sound.

Why, yes, the list of issues in "A Bundle of Problems" is only an anaemic sixteen pages long.

http://dx.doi.org/10.1109/AERO.2009.4839384
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#bundle-problems

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, Kevin Fall <[email-masked]>
Date: Fri, 27 Nov 2009 09:29:52 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of	bundle reliability

A perfectly valid technical opinion, Lloyd, but it's one for which I believe there is as yet no experimental corroboration.  The very same Bundle Protocol has been used both for highly successful exercises in tactical military applications over links characterized by frequent, unannounced disruptions and insignificant signal propagation delay and also for a highly successful exercise in a deep space mission application over links characterized by very lengthy scheduled disruptions, occasional unexpected disruptions, and signal propagation times on the order of minutes.  Nothing in DTN demonstration experience to date suggests that the DTN architecture is not equally suitable for all of the challenged network environments to which it has been applied.

This is not to say that the Bundle Protocol is perfect, only that it is perfectible and worth perfecting.  We have all got pet peeves with one aspect or another of RFC 5050, and I would be somewhat surprised if the Bundle Protocol specification that should eventually make its way to the standards track of IETF were in all ways identical to the current specification.

But the fundamental design choice you allude to has borne up remarkably well.  A lot of effort has been put into trying to make mountains out various DTN molehills over the past few years, on this list and in the published literature, to no very great effect.  The scope of that effort is, in fact, one of the most encouraging elements of the history of DTN to date: I think people look at this rather anemic list of issues and figure hey, if these are the only things anyone's found to complain in ten years of DTN technology development, this stuff must be pretty sound.

I suspect we will find some way to tweak RFC 5050 to accommodate computers that lack clocks, and I wouldn't be surprised if we eventually agreed on some sort of low-overhead end-to-end bundle checksum for environments in which it is found to be useful.  But accepting those minor adjustments as a justification for abandoning the architecture would be simply wrong.

Scott
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lloyd Wood [[email-masked]]
Sent: Thursday, November 26, 2009 4:08 PM
To: Kevin Fall
Cc: [email-masked]; Lloyd Wood
Subject: Re: [dtn-interest] noting paper commenting on practical effects of     bundle reliability

On 26 Nov 2009, at 22:53, Kevin Fall wrote:

> yes, I read that paper quite some time ago; much of it mentions the consequences of some design decisions that I still wouldn't change,

I'd say that the assumption in your 2003 SIGCOMM paper that the bundle architecture can be generalised, to cover and support very dissimilar networks with very different requirements, is the fundamental choice from which everything else follows.

Subsequent experience and analysis relating to clocks and timing, reliability, need for and how to handle fragmentation, choice of bundle sizes, routing... in different network environments suggests to me that that fundamental assumption and generalization is simply not supportable. There is no single suitable complex overlay architecture. Entirely ignoring the properties and requirements of the underlying networks as an overlay does not lead to compatibility with those underlying networks or meet their needs.

Trying to get all of civil space communications moving towards a single networked model is one problem that is likely achievable with enough effort, and that's what the bundle model was originally designed for. Trying to get all disparate challenged networks to move towards a bundle overlay model that cannot support their different needs is imo not achievable. ("Delay tolerant is not disruption tolerant" encapsulates that.) And that's even before asking about common shared applications.

Kludging bundling with relative time or reliability fixes is still buying into that flawed first assumption that bundling can be made to support enough of the underlying varying network conditions to be widely useful. We need to recognise those few networks where bundling may be sufficiently useful or promoted for non-technical political reasons, and those many other networks where it is not, and where other solutions need to be developed.

From: Lloyd Wood <[email-masked]>
Date: Fri, 27 Nov 2009 00:08:15 +0000
To: Kevin Fall <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 26 Nov 2009, at 22:53, Kevin Fall wrote:

> yes, I read that paper quite some time ago; much of it mentions the consequences of some design decisions that I still wouldn't change,

I'd say that the assumption in your 2003 SIGCOMM paper that the bundle architecture can be generalised, to cover and support very dissimilar networks with very different requirements, is the fundamental choice from which everything else follows.

Subsequent experience and analysis relating to clocks and timing, reliability, need for and how to handle fragmentation, choice of bundle sizes, routing... in different network environments suggests to me that that fundamental assumption and generalization is simply not supportable. There is no single suitable complex overlay architecture. Entirely ignoring the properties and requirements of the underlying networks as an overlay does not lead to compatibility with those underlying networks or meet their needs. 

Trying to get all of civil space communications moving towards a single networked model is one problem that is likely achievable with enough effort, and that's what the bundle model was originally designed for. Trying to get all disparate challenged networks to move towards a bundle overlay model that cannot support their different needs is imo not achievable. ("Delay tolerant is not disruption tolerant" encapsulates that.) And that's even before asking about common shared applications.

Kludging bundling with relative time or reliability fixes is still buying into that flawed first assumption that bundling can be made to support enough of the underlying varying network conditions to be widely useful. We need to recognise those few networks where bundling may be sufficiently useful or promoted for non-technical political reasons, and those many other networks where it is not, and where other solutions need to be developed.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Kevin Fall <[email-masked]>
Date: Thu, 26 Nov 2009 14:53:38 -0800
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

yes, I read that paper quite some time ago; much of it mentions the consequences of some design decisions that I still wouldn't change, and includes some commentary that is, in my opinion, erroneous;  yet, having an "experience" paper is useful...but that mostly aside, fixed-length fields are not a panacea.  You will no doubt recall IP stacks that crashed when fed inappropriately overlapping fragments.  Even the IP header checksum doesn't help there.  You still need software that handles these problematic cases.  Those things evolve over time as software and experience with it improves... today we don't see many successful attacks of that sort (for example).

- K

On Nov 26, 2009, at Nov 262:02 PMPST, Lloyd Wood wrote:

> On 26 Nov 2009, at 19:32, Kevin Fall wrote:
> 
>> right.  bugs in dtnd can cause it to crash..  we'll get on that.
> 
> http://maillists.intel-research.net/pipermail/dtn-interest/2009-February/003533.html
> 
> "A Bundle of Problems", section 4.12.
> 
> L.
> 
> when you predict the future you no longer need to invent it.
> 
>> 
>> - K
>> 
>> 
>> On Nov 26, 2009, at Nov 264:13 AMPST, Lloyd Wood wrote:
>> 
>>> http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf
>>> 
>>> Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.
>>> 
>>> says:
>>> 
>>> [..]
>>> In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.
>>> 
>>> This has two major ramifications.
>>> 
>>> - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or
>>> 
>>> - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn�t an example of the lack of error detection� in this case error detection may not have caught the problem� it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
>>> [..]
>>> 
>>> interesting.
>>> 
>>> L.
>>> 
>>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>> 
>>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Nov 2009 22:02:11 +0000
To: Kevin Fall <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 26 Nov 2009, at 19:32, Kevin Fall wrote:

> right.  bugs in dtnd can cause it to crash..  we'll get on that.

http://maillists.intel-research.net/pipermail/dtn-interest/2009-February/003533.html

"A Bundle of Problems", section 4.12.

L.

when you predict the future you no longer need to invent it.

> 
> - K
> 
> 
> On Nov 26, 2009, at Nov 264:13 AMPST, Lloyd Wood wrote:
> 
>> http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf
>> 
>> Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.
>> 
>> says:
>> 
>> [..]
>> In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.
>> 
>> This has two major ramifications.
>> 
>> - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or
>> 
>> - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn�t an example of the lack of error detection� in this case error detection may not have caught the problem� it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
>> [..]
>> 
>> interesting.
>> 
>> L.
>> 
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>> 
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Kevin Fall <[email-masked]>
Date: Thu, 26 Nov 2009 11:35:55 -0800
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

it would be nice if we could have library functions that a dtn app could use for e2e integrity
(separate from - above - the bundle layer).

- K

On Nov 26, 2009, at Nov 268:26 AMPST, Stephen Farrell wrote:

> 
> Now that's what I call speedy!
> 
> I hope to get a chance to play about with that soonish (probably
> be the new year at this stage though).
> 
> Good stuff,
> S.
> 
> Lloyd Wood wrote:
>> On 26 Nov 2009, at 13:11, Stephen Farrell wrote:
>> 
>>> 2) Be great if the authors would publish their AX25 CL code. (Or
>>> if they have...thanks:-)
>> 
>> http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer
>> 
>> L.
>> 
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>> 
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
Date: Thu, 26 Nov 2009 11:32:42 -0800
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

right.  bugs in dtnd can cause it to crash..  we'll get on that.

- K

On Nov 26, 2009, at Nov 264:13 AMPST, Lloyd Wood wrote:

> http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf
> 
> Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.
> 
> says:
> 
> [..]
> In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.
> 
> This has two major ramifications.
> 
> - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or
> 
> - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn�t an example of the lack of error detection� in this case error detection may not have caught the problem� it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
> [..]
> 
> interesting.
> 
> L.
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 26 Nov 2009 16:26:10 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

Now that's what I call speedy!

I hope to get a chance to play about with that soonish (probably
be the new year at this stage though).

Good stuff,
S.

Lloyd Wood wrote:
> On 26 Nov 2009, at 13:11, Stephen Farrell wrote:
> 
>> 2) Be great if the authors would publish their AX25 CL code. (Or
>> if they have...thanks:-)
> 
> http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer
> 
> L.
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 
> 

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Nov 2009 13:27:43 +0000
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

On 26 Nov 2009, at 13:11, Stephen Farrell wrote:

> 
> 2) Be great if the authors would publish their AX25 CL code. (Or
> if they have...thanks:-)

http://www.dtnrg.org/wiki/AX25ConnectedModeConvergenceLayer

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Darren Long <[email-masked]>
Date: Thu, 26 Nov 2009 13:20:25 +0000
To: Stephen Farrell <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

Hi,

I can publish the AX.25 CL code, but I've not touched it for a few months, and the last time I tried to locally merge my branch with the sourceforge upstream, things went a bit iffy.  I do need to get back to it again sometime soon, so I might just push my branch up to bitbucket.org rather than commit to sourceforge when it looks fit for purpose again.

Darren

On 26 Nov 2009, at 13:11, Stephen Farrell wrote:

> 
> Nice paper. I guess its worth pointing out that its conclusions
> are actually positive rather than what one might conclude from the
> quote below.
> 
> Two things I'd note:
> 
> 1) Wouldn't it be nice if someone had time to write some code
> implementing the checksum draft so's we could know whether or not
> it helps? E.g. in its absence the authors here seem to conclude
> that integrity mechanisms in the CL may be best for now:
> 
>  "The issue of bundle integrity is a more difficult one than it appears
>   at first inspection, and it still is not clear how the often
>   conflicting requirements (network transport neutrality versus
>   confidence in bundle integrity) can be easily reconciled. The
>   author�s approach is to effectively ignore the entire problem at
>   the bundle protocol level, but implement a robust AX25 CL in order
>   to at least ensure that it didn�t exacerbate the problem or take
>   down the node�s dtnd service."
> 
> 2) Be great if the authors would publish their AX25 CL code. (Or
> if they have...thanks:-)
> 
> S.
> 
> 
> Lloyd Wood wrote:
>> http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf
>> 
>> Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.
>> 
>> says:
>> 
>> [..]
>> In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.
>> 
>> This has two major ramifications.
>> 
>> - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or
>> 
>> - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn�t an example of the lack of error detection� in this case error detection may not have caught the problem� it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
>> [..]
>> 
>> interesting.
>> 
>> L.
>> 
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>> 
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 26 Nov 2009 13:11:27 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] noting paper commenting on practical effects of bundle reliability

Nice paper. I guess its worth pointing out that its conclusions
are actually positive rather than what one might conclude from the
quote below.

Two things I'd note:

1) Wouldn't it be nice if someone had time to write some code
implementing the checksum draft so's we could know whether or not
it helps? E.g. in its absence the authors here seem to conclude
that integrity mechanisms in the CL may be best for now:

  "The issue of bundle integrity is a more difficult one than it appears
   at first inspection, and it still is not clear how the often
   conflicting requirements (network transport neutrality versus
   confidence in bundle integrity) can be easily reconciled. The
   author’s approach is to effectively ignore the entire problem at
   the bundle protocol level, but implement a robust AX25 CL in order
   to at least ensure that it didn’t exacerbate the problem or take
   down the node’s dtnd service."

2) Be great if the authors would publish their AX25 CL code. (Or
if they have...thanks:-)

S.

Lloyd Wood wrote:
> http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf
> 
> Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.
> 
> says:
> 
> [..]
> In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.
> 
> This has two major ramifications.
> 
>  - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or
> 
>  - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn’t an example of the lack of error detection— in this case error detection may not have caught the problem— it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
> [..]
> 
> interesting.
> 
> L.
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Nov 2009 12:13:53 +0000
To: <[email-masked]>
Cc: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] noting paper commenting on practical effects of bundle reliability

http://www.tapr.org/pdf/DCC2009-DelayandDisruptionTolerantNetworking-EI7IG-G0HWW-Walsh.pdf

Ronan, Walsh and Long, Experiments with Delay and Disruption Tolerant Networking in AX.25 and D-Star Networks, ARRL/TAPR 28th annual, Digital Communications Conference, 25-27 September 2009, Chicago.

says:

[..]
In [13] the authors highlight issues of lack of checksum for error detection with bundles, and bundle integrity is a big issue in the current DTN architecture. Without using bundle security mechanisms, there is no built-in error detection (or correction) mechanism available at the bundle layer.

This has two major ramifications.

 - Bad bundles can crash the Bundle Protocol daemon (in our case dtnd), or

 - Bundles can be delivered to their destination as if they were valid data. As an illustration of the effect of corrupt data on dtnd, in early experiments with Prophet router [2], a byte-order issue in the Prophet code was able to bring down an entire dtnd network. One of the authors used a PowerPC-equipped computer (big-endian) to connected to a DTN running with Intel and ARM devices (little-endian) machines. As soon as the PowerPC node transmitted Prophet routing data, all other dtnd instances in the network crashed. While this isn�t an example of the lack of error detection� in this case error detection may not have caught the problem� it does, however, illustrate the problems posed by malformed data being ingested into dtnd instances.
[..]

interesting.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 23 Nov 2009 22:29:48 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

I don't blame you, Lloyd, the DINET stack really is very mind-bending, and you are absolutely right: now that you remind me, we were indeed incurring legacy CFDP overhead as well as BP/LTP overhead.  To try to reduce the confusion somewhat, we referred to the original Deep Impact CFDP system as "PX" (from "Protocol X", an antediluvian name from the dawn of CFDP).  The reason to tunnel DTN traffic through the PX PDUs was that it enabled us to leverage off the existing interfaces to the link-layer protocols, both in flight and on the ground, without changing any of the existing flight or ground data system software.  Our bundles were aggregated into LTP blocks, which were chopped up into LTP segments, which were encapsulated in PX "file data segment PDUs" (as if they were hunks of a file), which became the contents of space packets, which were transmitted in CCSDS TM/TC frames.

So the real answer to your original question is that the reason LTP retransmission was needed even in this configuration was that PX (the legacy Deep Impact CFDP) was hard-coded to use only unacknowledged mode for file downlink from the spacecraft: PX did indeed see the data before LTP did, but there was no ARQ operating at that layer.  The lowest layer of retransmission was LTP, and there was backup custodial retransmission for occasions on which LTP sessions simply failed due to excessive retransmission: BP would reforward the bundles in the canceled LTP block, possibly over a different path.

For DINET 2 the stack gets even weirder: we use unacknowledged CFDP (preserving the application interface, as you say) to segment a file and transmit each CFDP PDU as the payload of a single bundle.  Ultimately we're tunneling class-1 CFDP over class-1 CFDP, with BP and LTP layers in between.

If we were starting from scratch with a new mission we obviously wouldn't use this sort of configuration, but as a way to get onto a spacecraft in interplanetary space at minimal cost it was tough to beat.  For all the complexity and proliferation of state machinery in this approach, it was way cheaper than trying to modify flight software in place.

Scott
________________________________________
From: Lloyd Wood [[email-masked]]
Sent: Monday, November 23, 2009 4:57 PM
To: Burleigh, Scott C (313B)
Cc: Lloyd Wood; [email-masked]
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

hi Scott,

inline below...

On 23 Nov 2009, at 16:54, Burleigh, Scott C (313B) wrote:

>> On 20 Nov 2009, at 23:17, Burleigh, Scott C (313B) wrote:
>> ....
>>> When we did the arithmetic for DINET we determined that the CFDP, BP, and
>> LTP overhead was acceptable.
>>
>> Wouldn't erasure detection and retransmission have first fallen to the
>> lowest level of CFDP, so that LTP would not have seen the errors? (Am I
>> right in thinking that CFDP's unacknowledged mode was used there to prevent
>> that and increase testing of LTP?)
>
> Sorry, good catch, we actually weren't using CFDP during the DINET experiment: we didn't have a DTN-enabled implementation of CFDP yet, and we were sending very small files (none larger than about 40 KB), so we simply sent each file in a single bundle.  There was only BP/LTP overhead.

For a moment there, I was thoroughly confused. Please bear with me as I walk through my confusion.

I was under the impression that, as Deep Impact (now renamed EPOXI) is one of the few missions already running CFDP operationally (the first - Messenger to Mercury's apparently running some stripped-down "CFDP lite" implementation, don't know about others):
http://dx.doi.org/10.1109/AERO.2007.352896
Sanders, Jones, Levesque, Transfer of Files Between the Deep Impact Spacecrafts and the Ground Data System Using CFDP: a Case Study, IEEE Aerospace 2007.

and given that DINET had very limited access to the spacecraft and was fitting around the existing operational model, that the BP/LTP implementation was layered 'in userspace' on top of the existing CFDP install with the existing CFDP as the 'link service adapter'.

I also understood that, given development of applications using CFDP, as CFDP was the preferred CCSDS networking model of choice before the Bundle Protocol, that preserving the CFDP APIs is important for those apps, and that, as you mention, you've now developed an unacked CFDP that runs over BP/LTP.

So, in your first tests, I thought you did BP/LTP over the existing CFDP already running operationally on Deep Impact, while the planned second tests would be CFDP (to preserve application interfaces) over BP over LTP -- over the existing link service adapter, which on Deep Impact would be the CFDP install that BP/LTP acts as an application to. So that leads to CFDP (for the apps, and DTN-enabled to run over BP) over BP over LTP over CFDP (which is already there) - and using unacked mode in the lower CFDP to test out LTP's state machine seemed to make sense.

In fact:
Disruption Tolerant Networking Flight Validation Experiment on NASA's EPOXI Mission
Wyatt, J.; Burleigh, S.; Jones, R.; Torgerson, L.; Wissler, S.
http://dx.doi.org/10.1109/SPACOMM.2009.39

mentions that you were able to modify the CFDP onboard somewhat, but had it modified to a dummy shim rather than an unacked mode to skip the protocol engine, saying, and I quote: 'In effect, we �tunnel� DTN traffic through underlying CFDP.'

>From that, it sounds like there was CFDP overhead there regardless; you may have not been using its features and dummied it out (instead of using unacked mode) to avoid getting trapped by the effects of its protocol state machine whose ack reliability would have prevented testing of the higher layers, but it was there.

So your second tests would have done CFDP over BP over LTP (which can be thought of as a redesigned stripped-down CFDP Mk2) over (okay, a dummied) CFDP? And each one of those layers could run independently over UDP (okay, the BP, not so well)... wow. That's a lot of complexity, redundancy, state machinery, code and programmer time. imo. Still, you know how to migrate your userbase and keep them happy.

thanks,

L.

>
> Since then, though, we have indeed developed a class-1 (Unacknowledged) CFDP that uses BP/LTP as its UT layer.  We had planned to use that code for a second DINET experiment this month, but we ran short of time to correct some bugs in integration with EPOXI's flash file system that were discovered at the last minute, so instead we'll be doing some ground testing with that CFDP over the next couple of months.  Because CFDP runs over BP over LTP in this configuration, incoming data is seen by LTP first, then BP, then CFDP.  We could implement Acknowledged procedures in CFDP as well and forego retransmission at the LTP and BP layers, but there doesn't seem to be a lot of benefit: LTP's retransmission mechanism is lifted directly from CFDP, the main difference being that in this configuration it can support other kinds of traffic in addition to file transfers.
>
> Scott

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Lloyd Wood <[email-masked]>
Date: Tue, 24 Nov 2009 00:57:05 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

hi Scott,

inline below...

On 23 Nov 2009, at 16:54, Burleigh, Scott C (313B) wrote:

>> On 20 Nov 2009, at 23:17, Burleigh, Scott C (313B) wrote:
>> ....
>>> When we did the arithmetic for DINET we determined that the CFDP, BP, and
>> LTP overhead was acceptable.
>> 
>> Wouldn't erasure detection and retransmission have first fallen to the
>> lowest level of CFDP, so that LTP would not have seen the errors? (Am I
>> right in thinking that CFDP's unacknowledged mode was used there to prevent
>> that and increase testing of LTP?)
> 
> Sorry, good catch, we actually weren't using CFDP during the DINET experiment: we didn't have a DTN-enabled implementation of CFDP yet, and we were sending very small files (none larger than about 40 KB), so we simply sent each file in a single bundle.  There was only BP/LTP overhead.

For a moment there, I was thoroughly confused. Please bear with me as I walk through my confusion.

I was under the impression that, as Deep Impact (now renamed EPOXI) is one of the few missions already running CFDP operationally (the first - Messenger to Mercury's apparently running some stripped-down "CFDP lite" implementation, don't know about others):
http://dx.doi.org/10.1109/AERO.2007.352896
Sanders, Jones, Levesque, Transfer of Files Between the Deep Impact Spacecrafts and the Ground Data System Using CFDP: a Case Study, IEEE Aerospace 2007.

and given that DINET had very limited access to the spacecraft and was fitting around the existing operational model, that the BP/LTP implementation was layered 'in userspace' on top of the existing CFDP install with the existing CFDP as the 'link service adapter'.

I also understood that, given development of applications using CFDP, as CFDP was the preferred CCSDS networking model of choice before the Bundle Protocol, that preserving the CFDP APIs is important for those apps, and that, as you mention, you've now developed an unacked CFDP that runs over BP/LTP.

So, in your first tests, I thought you did BP/LTP over the existing CFDP already running operationally on Deep Impact, while the planned second tests would be CFDP (to preserve application interfaces) over BP over LTP -- over the existing link service adapter, which on Deep Impact would be the CFDP install that BP/LTP acts as an application to. So that leads to CFDP (for the apps, and DTN-enabled to run over BP) over BP over LTP over CFDP (which is already there) - and using unacked mode in the lower CFDP to test out LTP's state machine seemed to make sense.

In fact:
Disruption Tolerant Networking Flight Validation Experiment on NASA's EPOXI Mission
Wyatt, J.; Burleigh, S.; Jones, R.; Torgerson, L.; Wissler, S.
http://dx.doi.org/10.1109/SPACOMM.2009.39

mentions that you were able to modify the CFDP onboard somewhat, but had it modified to a dummy shim rather than an unacked mode to skip the protocol engine, saying, and I quote: 'In effect, we �tunnel� DTN traffic through underlying CFDP.'

>From that, it sounds like there was CFDP overhead there regardless; you may have not been using its features and dummied it out (instead of using unacked mode) to avoid getting trapped by the effects of its protocol state machine whose ack reliability would have prevented testing of the higher layers, but it was there.

So your second tests would have done CFDP over BP over LTP (which can be thought of as a redesigned stripped-down CFDP Mk2) over (okay, a dummied) CFDP? And each one of those layers could run independently over UDP (okay, the BP, not so well)... wow. That's a lot of complexity, redundancy, state machinery, code and programmer time. imo. Still, you know how to migrate your userbase and keep them happy.

thanks,

L.

> 
> Since then, though, we have indeed developed a class-1 (Unacknowledged) CFDP that uses BP/LTP as its UT layer.  We had planned to use that code for a second DINET experiment this month, but we ran short of time to correct some bugs in integration with EPOXI's flash file system that were discovered at the last minute, so instead we'll be doing some ground testing with that CFDP over the next couple of months.  Because CFDP runs over BP over LTP in this configuration, incoming data is seen by LTP first, then BP, then CFDP.  We could implement Acknowledged procedures in CFDP as well and forego retransmission at the LTP and BP layers, but there doesn't seem to be a lot of benefit: LTP's retransmission mechanism is lifted directly from CFDP, the main difference being that in this configuration it can support other kinds of traffic in addition to file transfers.
> 
> Scott 

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Mon, 23 Nov 2009 18:25:22 +0000
From: Stephen Farrell <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: Kevin Fall <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

So this part of the discussion is about how to do stuff,
rather than what to do. I think I'd prefer to do the
what first, and then consider how. But since we're on
the topic...

Daniel Ellard wrote:
> Kevin Fall wrote:
> 
>> regarding hop limit, why would one not just have an 
>> extension block for this?
> 
> In theory, an extension block would work, but in practice,
> there are two reasons why we don't think this is the right
> approach:
> 
> - Extension blocks are for extensions.  We want this to be a
> core requirement of the protocol, not something that's an
> extension that some implementor might decide to omit or
> ignore.  It doesn't work if people don't use it.

To me that implies starting with an extension block now
and then if and when we revise 5050, we include as "core"
whichever expiry mechanism(s) are most useful.

> - The additional overhead of parsing the entire primary
> block and then scanning through the extension blocks before
> we can make basic decisions about how to process a bundle.
> We'd rather know the simple things up front. Efficiency and
> simplicity are important to us.  We'd like to be able to put
> the basic bundle handling into an FPGA, and it's a much
> smaller FPGA if we don't have to deal with extension blocks.

But your FPGA has to jump over the dictionary already so
its not very simple at the moment in any case, so again,
I'd see such optimisations as something for which we're not
yet ready.

S.

> 
>> (also, I believe it should count up rather than down so
>> we can know how far a bundle has come so far)
> 
> What do you plan to do with that info?  (you must be
> thinking of something we've overlooked)
> 
> -Dan
> 

Date: Mon, 23 Nov 2009 12:34:35 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Kevin Fall <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

Kevin Fall wrote:

> regarding hop limit, why would one not just have an 
> extension block for this?

In theory, an extension block would work, but in practice,
there are two reasons why we don't think this is the right
approach:

- Extension blocks are for extensions.  We want this to be a
core requirement of the protocol, not something that's an
extension that some implementor might decide to omit or
ignore.  It doesn't work if people don't use it.

- The additional overhead of parsing the entire primary
block and then scanning through the extension blocks before
we can make basic decisions about how to process a bundle.
We'd rather know the simple things up front. Efficiency and
simplicity are important to us.  We'd like to be able to put
the basic bundle handling into an FPGA, and it's a much
smaller FPGA if we don't have to deal with extension blocks.

> (also, I believe it should count up rather than down so
> we can know how far a bundle has come so far)

What do you plan to do with that info?  (you must be
thinking of something we've overlooked)

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Mon, 23 Nov 2009 12:15:06 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

Stephen Farrell wrote:

> I don't see what the CoS stuff has to do with expiry.

It doesn't have anything directly to do with expiry.  This
document came out of a list of what we (the BBN DTN
projects) would like to see in the header for the future.
(if you're going to change the format anyway, might as well
change it once rather than N times for N different features)

I should have removed it; it's an unnecessary distraction
from this particular discussion.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 23 Nov 2009 08:54:22 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Sunday, November 22, 2009 12:39 PM
> To: Burleigh, Scott C (313B)
> Cc: Lloyd Wood; [email-masked]
> Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib
> 
> Hi Scott,
> 
> inline below.
> 
> On 20 Nov 2009, at 23:17, Burleigh, Scott C (313B) wrote:
> ....
> > When we did the arithmetic for DINET we determined that the CFDP, BP, and
> LTP overhead was acceptable.
> 
> Wouldn't erasure detection and retransmission have first fallen to the
> lowest level of CFDP, so that LTP would not have seen the errors? (Am I
> right in thinking that CFDP's unacknowledged mode was used there to prevent
> that and increase testing of LTP?)

Sorry, good catch, we actually weren't using CFDP during the DINET experiment: we didn't have a DTN-enabled implementation of CFDP yet, and we were sending very small files (none larger than about 40 KB), so we simply sent each file in a single bundle.  There was only BP/LTP overhead.

Since then, though, we have indeed developed a class-1 (Unacknowledged) CFDP that uses BP/LTP as its UT layer.  We had planned to use that code for a second DINET experiment this month, but we ran short of time to correct some bugs in integration with EPOXI's flash file system that were discovered at the last minute, so instead we'll be doing some ground testing with that CFDP over the next couple of months.  Because CFDP runs over BP over LTP in this configuration, incoming data is seen by LTP first, then BP, then CFDP.  We could implement Acknowledged procedures in CFDP as well and forego retransmission at the LTP and BP layers, but there doesn't seem to be a lot of benefit: LTP's retransmission mechanism is lifted directly from CFDP, the main difference being that in this configuration it can support other kinds of traffic in addition to file transfers.

Scott 

Date: Mon, 23 Nov 2009 16:22:20 +0000
From: Stephen Farrell <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

Hi Dan,

Daniel Ellard wrote:
> Ivancic, William D. (GRC-RHN0) wrote:
>> I believe BBN and/or NASA GRC will be putting a ID out
>> soon.  The GRC group will be meeting this morning to
>> discuss this and find out where we are relative to
>> discussions with BBN.
> 
> I'm not sure this made it to the whole list, so just in
> case, here's the outline of what we've been working on at
> BBN.  No ID yet; we're hoping for a little more feedback first.

Feedback: write an I-D!

I'm gonna mostly agree with Kevin I think.

I'd like to do this without revising 5050 - I don't think
we're yet at the point where we want to open that up. Maybe
in a while, but not yet. (If we did, then e.g I'd be trying
to change the dictionary encoding, I'm sure others would
have their fav. thing to change etc. so it could be a can of
worms.)

The hop count stuff in both proposals seems more or less
the same.

The relative time thing in yours differs from our proposal,
but would our idea of a deferred window scheme work well
enough for you? (Do I understand the RT idea correctly
in that it implies the primary block changes at each hop?
If so, then maybe its really a "queuing time" expiry
scheme and not actually "relative" time?) Having said
that, I don't think I'd have a problem with including
a "queuing time" expiry scheme as yet another one in
our I-D if that was what folks thought useful.

I don't see what the CoS stuff has to do with expiry.

Cheers,
S.

> 
> -Dan
> 

From: Kevin Fall <[email-masked]>
Date: Mon, 23 Nov 2009 08:08:32 -0800
To: Daniel Ellard <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

As you might expect, I have some concerns with this direction.
First, I don't see a need to change the version.

Beyond that:

regarding clocks, I'm sure we will debate that

regarding hop limit, why would one not just have an extension block for this?
	(also, I believe it should count up rather than down so we can know how far a bundle has come so far)

regarding CoS bits, what is the "large benefit"?

- K

On Nov 23, 2009, at Nov 237:31 AMPST, Daniel Ellard wrote:

> Ivancic, William D. (GRC-RHN0) wrote:
>> I believe BBN and/or NASA GRC will be putting a ID out
>> soon.  The GRC group will be meeting this morning to
>> discuss this and find out where we are relative to
>> discussions with BBN.
> 
> I'm not sure this made it to the whole list, so just in
> case, here's the outline of what we've been working on at
> BBN.  No ID yet; we're hoping for a little more feedback first.
> 
> -Dan
> 
> -- 
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
> # $Id: dtnv7.txt 18715 2009-10-02 17:53:46Z dellard $
> 
> A specification for "DTN v7".
> 
> This specification is relative to RFC 5050.  The reader is assumed to
> be familiar with the terms, definitions, and concepts described in RFC
> 5050 and in general DTN concepts.
> 
> For more info, consult http://www.rfc-editor.org/rfc/rfc5050.txt
> 
> INTRODUCTION
> 
> This document proposes three major changes to the DTNv6 (as defined by
> RFC5050 and related documents).
> 
> 1.  The ability to use relative time instead of absolute time as
>    a way to tolerated inaccurate and/or unsynchronized clocks
> 
> 2.  The addition of 'hops to live' as a way to detect and handle
>    routing loops or other pathological behavior
> 
> 3.  The addition of extended CoS bits for use by advanced routers
> 
> BACKGROUND AND MOTIVATION
> 
> == Relative timestamps:
> 
>    We need the ability to tolerate inaccurate and/or unsynchronized
>    clocks in some environments. 
> 
>    We have nodes with bad clocks; we can't count on GPS or any other
>    time source being available; and the bundle expiration time on
>    some bundles may actually be on par with the clock skew from one
>    node to another (i.e., a message saying "duck!" probably doesn't
>    have much value after a few seconds).
> 
>    There are domains where relative timestamps aren't needed,
>    (because either good, synchronized are either readily available or
>    not required) and we accept that, but there are important
>    applications we cannot address today and in the foreseeable future
>    without them.
> 
> == Hops to Live (aka Time to Live)
> 
>    (Note that we deviate from the common term of "time to live"
>    because this term already has a non-standard use in DTN, and "hops
>    to live" is a more accurate description in any case.)
> 
>    In order to detect problems in routing, particularly loops, it is
>    helpful to have a HTL counter that is decremented each time a
>    bundle is forwarded.  When the HTL reaches zero, the bundle can be
>    discarded.
> 
>    Discussion:  we could either mandate that the bundle is
> 	automatically and invariably dropped with the HTL reaches
> 	zero, or we could make this advisory and say that the bundle
> 	MAY be dropped.  If the routing problems are transient, then
> 	perhaps we could permit a BPA to decide what to do:  wait for
> 	a few moments or for updated info from the router, and then
> 	try again with a small, probationary HTL.  Or we could allow a
> 	BPA that detects a preposterously large HTL to chop it down to
> 	some smaller value if it has a high confidence in its estimate
> 	of the network radius.
> 
> == Class of Service
> 
>    We believe that there would be a large benefit to having more bits
>    for CoS than 5050 provides.
> 
>    It is currently possible to use extension blocks to represent
>    arbitrary information about each bundle, but routers can benefit
>    from having at least a few extra bits to use in a well-known,
>    easy-to-access location in the bundle header (instead of requiring
>    the bundle be parsed in order to access this information).
> 
> CHANGES FROM RFC 5050
> 
> RFC 5050 provides the specification of version 6 of the DTN protocol;
> this document provides the specification of what we have been calling
> "DTN version 7".
> 
> == Changes Relative to DTN v6:
> 
> Version: changed to 0x27
> 
> Proc Flags:
> 
>    Bits 0-19:  no changes in the lower 20 bits, except that the TOS
> 	bits in the processing flags are ignored and MUST always be
> 	zero.  These are replaced by bits 22-27
> 
>    (NEW) Bit 20:  if 1, then use relative time (RT) instead of
> 	absolute time (AT).  If 0, use absolute time, in a manner
> 	compatible with v6.
> 	
>    (NEW) Bit 21:  if 1, then use HTL.  If 0, then the HTL field is
> 	ignored.  If the HTL field is ignored, then implementations
> 	MUST set it to zero. 
> 
>    (NEW) Bits 22-29:  Differentiated service bits, as defined by
> 	http://www.rfc-editor.org/rfc/rfc3168.txt.
> 
> Block Length: no change
> 
> Offsets (all eight): no changes
> 
> Creation Timestamp time:  is not required reflect an accurate (or
>    actual) time, but is set to some meaningful value so that it can
>    be used, in conjunction with the creation timestamp sequence
>    number, to create a unique identifier for the bundle.
> 
>    It could be a boot number, or other sequence number for the BPA.
> 
> Creation Timestamp Sequence Number: no change
> 
>    5050 suggests that the creation timestamp time should be the
>    wallclock time when the bundle was created, but this is a
>    secondary property.  The most important property of the creation
>    timestamp time and creation timestamp sequence number is that
>    together they can be used to form (together with the node
>    identifier) a unique identifier for every bundle created by a
>    given node.
> 
>    Since some of the platforms we're trying to support have
>    incredibly terrible clocks, we don't assume we can use rely on the
>    clock to even provide a monotonically increasing sequence. 
>    Therefore, in the BBN BPA, we don't rely on the clock for
>    uniqueness.  Instead, we depend upon the sequence number.  We
>    split the sequence number into two fields:  a counter of bundles
>    generated with the current generation number, and the generation
>    number itself (incremented each time the system boots, or the
>    counter wraps).  This ensures that even if the clock travels
>    backwards, the sequence numbers are always unique and therefore
>    can be used (in conjunction with the source node) to uniquely
>    identify a bundle.
> 
>    Of course, we're trading the assumption of having a good clock for
>    the assumption that we have persistent storage that will survive
>    reboots, power loss, etc.  For our platforms, that's a reasonable
>    assumption, but it might not be universally true.
> 
> Lifetime: interpreted according to whether we are using RT or AT.
> 
>    In AT mode, the Lifetime contains the time (expressed in
>    seconds since the start of year 2000) when the bundle will
>    expire.
> 
>    In RT mode, the Lifetime field expresses the number of seconds
>    remaining until the bundle expires.
> 
> (NEW) Time to Live (TTL).  The TTL specifies how long the bundle can
>    remain in the system.  The TTL is expressed in seconds as an SDNV. 
>    It is decremented as the bundle is processed, and the bundle
>    expires when it reaches zero.
> 
>    If the bundle is created in AT mode, then the TTL is omitted from
>    the primary block.
> 
>    If the bundle is created in RT mode, then the initial value of the
>    TTL MUST be identical to the value of the Lifetime field.  At each
>    hop, the TTL is decremented by the length of time that has elapsed
>    since the previous hop, rounded DOWN to the nearest second.
> 
>    When the TTL reaches zero, the bundle should be discarded.
> 
> (NEW) Hops to Live -- number of hops permitted before the bundle is
>    discarded.  The HTL is decremented before the bundle is forwarded.
>    This value is expressed as an SDNV.
> 
>    If the bundle is created in AT mode, then the HTL is omitted from the
>    primary block.
> 
> All other fields are unchanged.
> 
> As a block diagram:
> 
>   +----------------+----------------+----------------+----------------+
>   |    Version     |                  Proc. Flags (*)                 |
>   +----------------+----------------+----------------+----------------+
>   |                          Block length (*)                         |
>   +----------------+----------------+---------------------------------+
>   |   Destination scheme offset (*) |     Destination SSP offset (*)  |
>   +----------------+----------------+----------------+----------------+
>   |      Source scheme offset (*)   |        Source SSP offset (*)    |
>   +----------------+----------------+----------------+----------------+
>   |    Report-to scheme offset (*)  |      Report-to SSP offset (*)   |
>   +----------------+----------------+----------------+----------------+
>   |    Custodian scheme offset (*)  |      Custodian SSP offset (*)   |
>   +----------------+----------------+----------------+----------------+
>   |                    Creation Timestamp time (*)                    |
>   +---------------------------------+---------------------------------+
>   |             Creation Timestamp sequence number (*)                |
>   +---------------------------------+---------------------------------+
>   |                           Lifetime (*)                            |
>   +----------------+----------------+----------------+----------------+
>   |                           (NEW) TTL (*)                           |
>   +----------------+----------------+----------------+----------------+
>   |                           (NEW) HTL (*)                           |
>   +----------------+----------------+----------------+----------------+
>   |                        Dictionary length (*)                      |
>   +----------------+----------------+----------------+----------------+
>   |                  Dictionary byte array (variable)                 |
>   +----------------+----------------+---------------------------------+
>   |                      [Fragment offset (*)]                        |
>   +----------------+----------------+---------------------------------+
>   |              [Total application data unit length (*)]             |
>   +----------------+----------------+---------------------------------+
> 
> DISCUSSION:
> 
>    TTL granularity:
> 
> 	If a bundle is forwarded "quickly" through a node, then its
> 	TTL might not be decremented (since the elapsed time is always
> 	rounded down to the nearest second, and many bundles will
> 	require less than one second to receive and forward). 
> 	Therefore a bundle may survive for many seconds longer than
> 	its TTL, if it makes steady progress and traverses enough
> 	hops.  The only time that the TTL will be decremented is if
> 	the bundle is "stalled" in a node and remains there for
> 	longer than one second.
> 
> 	Is this what we want, or should the TTL be measured in a finer
> 	unit (microseconds?  nanoseconds?), so that it is decremented
> 	even when a bundle is forwarded without any delay, and bundles
> 	can still expire even if they are never stalled?
> 
>    Compatibility with BSP
> 
> 	We can reuse the bundle header canonical format used by
> 	BSP in v6 for v7.  The only question is whether there is
> 	any need to protect the HTL or TTL in ways more powerful
> 	than the current hop-by-hop security.
> 
>    Startup Issues
> 
> 	If the BPA is shut down (or crashes, etc) or for some other
> 	reason loses track of the passage of time, it may not be able
> 	to update the TTL properly.
> 
> 	Two possible approaches:
> 
> 	1.  At startup, assume no time has passed since shutting down
> 	    and start counting TTL at whatever value we find on the
> 	    bundles when we load them from storage (which, since our
> 	    storage subsystem does not yet let us incrementally update
> 	    part of a bundle, is whatever time it had when we received
> 	    it).
> 
> 	2.  At startup, throw out all bundles with a TTL.
> 
>    Compatibility with v6
> 
> 	There is a mechanical way to rewrite bundle headers traversing
> 	from v6 to v7 and vice versa, assuming that all the
> 	intermediate nodes between the trans-version frontiers share a
> 	common clock (which is not *always* an invalid assumption).
> 
> 	This rewriting, however, hopelessly breaks BSP, because
> 	it changes elements in the canonical representation of
> 	the bundle header.
> 
> 	Is it worth providing this mechanism, even though we
> 	know that it doesn't work with BSP?
> 
> 	To work with BSP, the only practical alternative is to use
> 	Bundle-in-Bundle, with a special (to-be-defined) tag, but this
> 	has issues as well.
> 
> OPEN ISSUES
> 
> Bundle Status Reports
> 
>    Timestamps also appear in several fields in bundle status reports
>    (i.e., time when a bundle was deleted or delivered, etc).  In
>    DTNv6, these are all specified in absolute time.  In networks
>    whose nodes do not have a reasonably synchronized clock, it is not
>    clear how to interpret these values.
> 
>    One possible modification, whose interpretation makes sense in
>    "relative time" mode is to replace these timestamps with the value
>    of the time-to-live field on the bundle at the moment that the
>    status change occurred (e.g., "this bundle was delivered five
>    seconds before it would have expired"), or the lifetime field
>    minus the time-to-live field (e.g., "this bundle was delivered
>    twelve seconds after it was created").
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 23 Nov 2009 10:31:32 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

This is a multi-part message in MIME format.
--------------010406090404040807060109
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ivancic, William D. (GRC-RHN0) wrote:
> I believe BBN and/or NASA GRC will be putting a ID out
> soon.  The GRC group will be meeting this morning to
> discuss this and find out where we are relative to
> discussions with BBN.

I'm not sure this made it to the whole list, so just in
case, here's the outline of what we've been working on at
BBN.  No ID yet; we're hoping for a little more feedback first.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

--------------010406090404040807060109
Content-Type: text/plain;
 name="rt-091002.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="rt-091002.txt"

# $Id: dtnv7.txt 18715 2009-10-02 17:53:46Z dellard $

A specification for "DTN v7".

This specification is relative to RFC 5050.  The reader is assumed to
be familiar with the terms, definitions, and concepts described in RFC
5050 and in general DTN concepts.

For more info, consult http://www.rfc-editor.org/rfc/rfc5050.txt

INTRODUCTION

This document proposes three major changes to the DTNv6 (as defined by
RFC5050 and related documents).

1.  The ability to use relative time instead of absolute time as
    a way to tolerated inaccurate and/or unsynchronized clocks

2.  The addition of 'hops to live' as a way to detect and handle
    routing loops or other pathological behavior

3.  The addition of extended CoS bits for use by advanced routers

BACKGROUND AND MOTIVATION

== Relative timestamps:

    We need the ability to tolerate inaccurate and/or unsynchronized
    clocks in some environments. 

    We have nodes with bad clocks; we can't count on GPS or any other
    time source being available; and the bundle expiration time on
    some bundles may actually be on par with the clock skew from one
    node to another (i.e., a message saying "duck!" probably doesn't
    have much value after a few seconds).

    There are domains where relative timestamps aren't needed,
    (because either good, synchronized are either readily available or
    not required) and we accept that, but there are important
    applications we cannot address today and in the foreseeable future
    without them.

== Hops to Live (aka Time to Live)

    (Note that we deviate from the common term of "time to live"
    because this term already has a non-standard use in DTN, and "hops
    to live" is a more accurate description in any case.)

    In order to detect problems in routing, particularly loops, it is
    helpful to have a HTL counter that is decremented each time a
    bundle is forwarded.  When the HTL reaches zero, the bundle can be
    discarded.

    Discussion:  we could either mandate that the bundle is
	automatically and invariably dropped with the HTL reaches
	zero, or we could make this advisory and say that the bundle
	MAY be dropped.  If the routing problems are transient, then
	perhaps we could permit a BPA to decide what to do:  wait for
	a few moments or for updated info from the router, and then
	try again with a small, probationary HTL.  Or we could allow a
	BPA that detects a preposterously large HTL to chop it down to
	some smaller value if it has a high confidence in its estimate
	of the network radius.

== Class of Service

    We believe that there would be a large benefit to having more bits
    for CoS than 5050 provides.

    It is currently possible to use extension blocks to represent
    arbitrary information about each bundle, but routers can benefit
    from having at least a few extra bits to use in a well-known,
    easy-to-access location in the bundle header (instead of requiring
    the bundle be parsed in order to access this information).

CHANGES FROM RFC 5050

RFC 5050 provides the specification of version 6 of the DTN protocol;
this document provides the specification of what we have been calling
"DTN version 7".

== Changes Relative to DTN v6:

Version: changed to 0x27

Proc Flags:

    Bits 0-19:  no changes in the lower 20 bits, except that the TOS
	bits in the processing flags are ignored and MUST always be
	zero.  These are replaced by bits 22-27

    (NEW) Bit 20:  if 1, then use relative time (RT) instead of
	absolute time (AT).  If 0, use absolute time, in a manner
	compatible with v6.
	
    (NEW) Bit 21:  if 1, then use HTL.  If 0, then the HTL field is
	ignored.  If the HTL field is ignored, then implementations
	MUST set it to zero. 

    (NEW) Bits 22-29:  Differentiated service bits, as defined by
	http://www.rfc-editor.org/rfc/rfc3168.txt.

Block Length: no change

Offsets (all eight): no changes

Creation Timestamp time:  is not required reflect an accurate (or
    actual) time, but is set to some meaningful value so that it can
    be used, in conjunction with the creation timestamp sequence
    number, to create a unique identifier for the bundle.

    It could be a boot number, or other sequence number for the BPA.

Creation Timestamp Sequence Number: no change

    5050 suggests that the creation timestamp time should be the
    wallclock time when the bundle was created, but this is a
    secondary property.  The most important property of the creation
    timestamp time and creation timestamp sequence number is that
    together they can be used to form (together with the node
    identifier) a unique identifier for every bundle created by a
    given node.

    Since some of the platforms we're trying to support have
    incredibly terrible clocks, we don't assume we can use rely on the
    clock to even provide a monotonically increasing sequence. 
    Therefore, in the BBN BPA, we don't rely on the clock for
    uniqueness.  Instead, we depend upon the sequence number.  We
    split the sequence number into two fields:  a counter of bundles
    generated with the current generation number, and the generation
    number itself (incremented each time the system boots, or the
    counter wraps).  This ensures that even if the clock travels
    backwards, the sequence numbers are always unique and therefore
    can be used (in conjunction with the source node) to uniquely
    identify a bundle.

    Of course, we're trading the assumption of having a good clock for
    the assumption that we have persistent storage that will survive
    reboots, power loss, etc.  For our platforms, that's a reasonable
    assumption, but it might not be universally true.

Lifetime: interpreted according to whether we are using RT or AT.

    In AT mode, the Lifetime contains the time (expressed in
    seconds since the start of year 2000) when the bundle will
    expire.

    In RT mode, the Lifetime field expresses the number of seconds
    remaining until the bundle expires.

(NEW) Time to Live (TTL).  The TTL specifies how long the bundle can
    remain in the system.  The TTL is expressed in seconds as an SDNV. 
    It is decremented as the bundle is processed, and the bundle
    expires when it reaches zero.

    If the bundle is created in AT mode, then the TTL is omitted from
    the primary block.

    If the bundle is created in RT mode, then the initial value of the
    TTL MUST be identical to the value of the Lifetime field.  At each
    hop, the TTL is decremented by the length of time that has elapsed
    since the previous hop, rounded DOWN to the nearest second.

    When the TTL reaches zero, the bundle should be discarded.

(NEW) Hops to Live -- number of hops permitted before the bundle is
    discarded.  The HTL is decremented before the bundle is forwarded.
    This value is expressed as an SDNV.

    If the bundle is created in AT mode, then the HTL is omitted from the
    primary block.

All other fields are unchanged.

As a block diagram:

   +----------------+----------------+----------------+----------------+
   |    Version     |                  Proc. Flags (*)                 |
   +----------------+----------------+----------------+----------------+
   |                          Block length (*)                         |
   +----------------+----------------+---------------------------------+
   |   Destination scheme offset (*) |     Destination SSP offset (*)  |
   +----------------+----------------+----------------+----------------+
   |      Source scheme offset (*)   |        Source SSP offset (*)    |
   +----------------+----------------+----------------+----------------+
   |    Report-to scheme offset (*)  |      Report-to SSP offset (*)   |
   +----------------+----------------+----------------+----------------+
   |    Custodian scheme offset (*)  |      Custodian SSP offset (*)   |
   +----------------+----------------+----------------+----------------+
   |                    Creation Timestamp time (*)                    |
   +---------------------------------+---------------------------------+
   |             Creation Timestamp sequence number (*)                |
   +---------------------------------+---------------------------------+
   |                           Lifetime (*)                            |
   +----------------+----------------+----------------+----------------+
   |                           (NEW) TTL (*)                           |
   +----------------+----------------+----------------+----------------+
   |                           (NEW) HTL (*)                           |
   +----------------+----------------+----------------+----------------+
   |                        Dictionary length (*)                      |
   +----------------+----------------+----------------+----------------+
   |                  Dictionary byte array (variable)                 |
   +----------------+----------------+---------------------------------+
   |                      [Fragment offset (*)]                        |
   +----------------+----------------+---------------------------------+
   |              [Total application data unit length (*)]             |
   +----------------+----------------+---------------------------------+

DISCUSSION:

    TTL granularity:

	If a bundle is forwarded "quickly" through a node, then its
	TTL might not be decremented (since the elapsed time is always
	rounded down to the nearest second, and many bundles will
	require less than one second to receive and forward). 
	Therefore a bundle may survive for many seconds longer than
	its TTL, if it makes steady progress and traverses enough
	hops.  The only time that the TTL will be decremented is if
	the bundle is "stalled" in a node and remains there for
	longer than one second.

	Is this what we want, or should the TTL be measured in a finer
	unit (microseconds?  nanoseconds?), so that it is decremented
	even when a bundle is forwarded without any delay, and bundles
	can still expire even if they are never stalled?

    Compatibility with BSP

	We can reuse the bundle header canonical format used by
	BSP in v6 for v7.  The only question is whether there is
	any need to protect the HTL or TTL in ways more powerful
	than the current hop-by-hop security.

    Startup Issues

	If the BPA is shut down (or crashes, etc) or for some other
	reason loses track of the passage of time, it may not be able
	to update the TTL properly.

	Two possible approaches:

	1.  At startup, assume no time has passed since shutting down
	    and start counting TTL at whatever value we find on the
	    bundles when we load them from storage (which, since our
	    storage subsystem does not yet let us incrementally update
	    part of a bundle, is whatever time it had when we received
	    it).

	2.  At startup, throw out all bundles with a TTL.

    Compatibility with v6

	There is a mechanical way to rewrite bundle headers traversing
	from v6 to v7 and vice versa, assuming that all the
	intermediate nodes between the trans-version frontiers share a
	common clock (which is not *always* an invalid assumption).

	This rewriting, however, hopelessly breaks BSP, because
	it changes elements in the canonical representation of
	the bundle header.

	Is it worth providing this mechanism, even though we
	know that it doesn't work with BSP?

	To work with BSP, the only practical alternative is to use
	Bundle-in-Bundle, with a special (to-be-defined) tag, but this
	has issues as well.

OPEN ISSUES

Bundle Status Reports

    Timestamps also appear in several fields in bundle status reports
    (i.e., time when a bundle was deleted or delivered, etc).  In
    DTNv6, these are all specified in absolute time.  In networks
    whose nodes do not have a reasonably synchronized clock, it is not
    clear how to interpret these values.

    One possible modification, whose interpretation makes sense in
    "relative time" mode is to replace these timestamps with the value
    of the time-to-live field on the bundle at the moment that the
    status change occurred (e.g., "this bundle was delivered five
    seconds before it would have expired"), or the lifetime field
    minus the time-to-live field (e.g., "this bundle was delivered
    twelve seconds after it was created").

--------------010406090404040807060109--

Date: Mon, 23 Nov 2009 13:13:55 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Time & Expiry in the BP

Ivancic, William D. (GRC-RHN0) wrote:
> I believe BBN and/or NASA GRC will be putting a ID out soon.  The GRC group will be meeting this morning to discuss this and find out where we are relative to discussions with BBN.

Good stuff. An ETA for "soon" would be good too:-)

In the meantime, we'd welcome discussion as requested.

S.

PS: In case its not obvious, one of the reasons I wanted to push
this out was precisely to prompt others to do the same:-)

> 
> --Will
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Stephen
>> Farrell
>> Sent: Monday, November 23, 2009 6:25 AM
>> To: DTN
>> Subject: [dtn-interest] Time & Expiry in the BP
>>
>>
>> Hi All,
>>
>> We've discussed this a number of times without anyone
>> writing up an I-D.
>>
>> Now that we've got a bunch of documents out the RG-door,
>> a few of us have written up some ideas on other ways
>> to handle bundle expiry. [1]
>>
>> I guess the initial discussion should be around whether
>> folks think that this is sensible enough to warrant
>> making it an RG draft? In particular, is the scope
>> reasonable? If not, what should it be?
>>
>> Ideas and comments on the current content (which includes
>> a number of questions for the RG) are also welcome of
>> course. (As you'll see the draft is currently intended
>> to be nicely underspecified:-)
>>
>> If other folks have other ideas that they'd like to
>> suggest, now would be a good time to write them up in
>> an I-D so we can make real comparisons if we have
>> more than one scheme on the table.
>>
>> Thanks,
>> Stephen.
>>
>> [1] http://www.ietf.org/id/draft-farrell-dtnrg-alt-time-00.txt
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Mon, 23 Nov 2009 07:08:44 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Time & Expiry in the BP

I believe BBN and/or NASA GRC will be putting a ID out soon.  The GRC group will be meeting this morning to discuss this and find out where we are relative to discussions with BBN.

--Will

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Stephen
>Farrell
>Sent: Monday, November 23, 2009 6:25 AM
>To: DTN
>Subject: [dtn-interest] Time & Expiry in the BP
>
>
>Hi All,
>
>We've discussed this a number of times without anyone
>writing up an I-D.
>
>Now that we've got a bunch of documents out the RG-door,
>a few of us have written up some ideas on other ways
>to handle bundle expiry. [1]
>
>I guess the initial discussion should be around whether
>folks think that this is sensible enough to warrant
>making it an RG draft? In particular, is the scope
>reasonable? If not, what should it be?
>
>Ideas and comments on the current content (which includes
>a number of questions for the RG) are also welcome of
>course. (As you'll see the draft is currently intended
>to be nicely underspecified:-)
>
>If other folks have other ideas that they'd like to
>suggest, now would be a good time to write them up in
>an I-D so we can make real comparisons if we have
>more than one scheme on the table.
>
>Thanks,
>Stephen.
>
>[1] http://www.ietf.org/id/draft-farrell-dtnrg-alt-time-00.txt
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 23 Nov 2009 11:24:43 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Time & Expiry in the BP

Hi All,

We've discussed this a number of times without anyone
writing up an I-D.

Now that we've got a bunch of documents out the RG-door,
a few of us have written up some ideas on other ways
to handle bundle expiry. [1]

I guess the initial discussion should be around whether
folks think that this is sensible enough to warrant
making it an RG draft? In particular, is the scope
reasonable? If not, what should it be?

Ideas and comments on the current content (which includes
a number of questions for the RG) are also welcome of
course. (As you'll see the draft is currently intended
to be nicely underspecified:-)

If other folks have other ideas that they'd like to
suggest, now would be a good time to write them up in
an I-D so we can make real comparisons if we have
more than one scheme on the table.

Thanks,
Stephen.

[1] http://www.ietf.org/id/draft-farrell-dtnrg-alt-time-00.txt

From: Lloyd Wood <[email-masked]>
Date: Sun, 22 Nov 2009 20:39:19 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

Hi Scott,

inline below.

On 20 Nov 2009, at 23:17, Burleigh, Scott C (313B) wrote:
>> "In the DINET experiment we operated a DTN for a month over very noisy
>> interplanetary R/F links without any corruption of headers or data at any
>> time, thanks to the normal, quite robust CCSDS link-layer encoding."
> 
> Quite so.  There were no undetected bit errors, so such errors introduced no corruption of headers or data.  There were plenty of detected bit errors, and most of them were correctable; again, no corruption of headers or data.  There were a relatively small number of detected but uncorrectable bit errors; the frames in which these errors were detected were simply discarded, resulting in the detection of data loss -- not corruption -- in LTP, which caused retransmission.  Nothing very mysterious here.

Turning small corruption into larger frame loss, which isn't due to the coding, isn't the same as not having any corruption...

(I'm presuming here that deletion of link-layer frames leads to erasures in the larger CFDP frames, so the detection and discards happen outside the link layer.)

> When we did the arithmetic for DINET we determined that the CFDP, BP, and LTP overhead was acceptable.

Wouldn't erasure detection and retransmission have first fallen to the lowest level of CFDP, so that LTP would not have seen the errors? (Am I right in thinking that CFDP's unacknowledged mode was used there to prevent that and increase testing of LTP?)

thanks,

L.

> 
> Scott

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Sat, 21 Nov 2009 08:59:07 +0100
From: Emmanuel Lochin <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Clock synchronization in networks

Hi Lloyd,

It seems the authors are not aware of this excellent work :

Robust Synchronization of Absolute and Difference Clocks over Networks
Darryl Veitch, Julien Ridoux, Satish Babu Korada.
IEEE/ACM Transactions on Networking, to appear June 2009, June, 2009.

available here :
http://www.cubinlab.ee.unimelb.edu.au/~jrid/Publications/veitch_ton09.pdf

Emmanuel

2009/11/20 Lloyd Wood <[email-masked]>:
> http://arxiv.org/pdf/0911.3357
> Fundamentals of Large Sensor Networks: Connectivity, Capacity, Clocks and Computation
> Nikolaos M. Freris, Hemant Kowshik, and P. R. Kumar, 16 Nov 2009
>
> is an interesting read covering the problem of keeping time across networks, which this list has discussed for a couple of years now.
>
> "It was shown in [20], [17] that it is impossible to even synchronize just two clocks.
> [..]
> The following theorem [17] establishes the result that without any further assumptions, clock synchronization is impossible in any network."
>
> cheers,
>
> L.
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga
>
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
"This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy, use
or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed"

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, Peter Lovell <[email-masked]>
Date: Fri, 20 Nov 2009 15:32:02 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Clock synchronization in networks

I think network operators around the world would be surprised to learn that NTP doesn't synchronize their clocks.  Now, they probably wouldn't be surprised to learn that NTP doesn't synchronize their clocks to the nanosecond; they also probably wouldn't care.  Synchronizing to within a second seems to be more than good enough.

Clock synchronization in DTN is similar in some ways.  It very likely can't be done, to the nanosecond.  But we don't care.  Clock synchronization to within 8-10 seconds proved plenty good enough for the purposes of Bundle Protocol in DINET, and achieving that synchronization was trivial.

For DTN in flight mission operations, this is simply not an issue.  Let's all stop pretending that it is.

For nodes that don't have clocks at all, or that have no available mechanism for timely clock synchronization at all -- as in the case of the devices BBN is fielding -- sure, there's something to talk about.  Endlessly.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Lloyd Wood
> Sent: Friday, November 20, 2009 2:27 PM
> To: Peter Lovell
> Cc: [email-masked]; Lloyd Wood
> Subject: Re: [dtn-interest] Clock synchronization in networks
> 
> > I have passed on to a few people the comments, discussed here earlier,
> > about the relativistic correction required for correct operation of GPS.
> > Every one has been incredulous that (a) synchronization was hard, and
> > (b) that it was required in this situation. Sorry, Albert - people just
> > don't understand.
> 
> Vint understood (a) years ago. Shame that understanding is not reflected in
> the bundle protocol design...
> 
> "Timing, for instance. Internet routers around the globe synchronize their
> clocks by the millisecond in order to coordinate the flow of packets. That
> synchronization is far more difficult when a significant fraction of a
> light-year separates a spacecraft's onboard clock from its reference clock.
> "The problem with the interplanetary environment is that there ain't no
> such thing as 'now,' " Cerf says."
> 
> -- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, August 2005.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 15:17:16 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 2:16 PM
> To: Burleigh, Scott C (313B)
> Cc: Lloyd Wood; [email-masked]
> Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib
> 
> 
> On 20 Nov 2009, at 20:20, Burleigh, Scott C (313B) wrote:
> 
> >> It strikes me that not having CFDP PDUs at all, and just sending (large)
> >> files as bundles directly, so that there's one (custody transfer) ack
> per
> >> bundle/file, would cut down the uplink traffic tremendously.
> >
> > It would, but limiting ARQ to custody signals and retransmission at
> (large) bundle granularity wouldn't be an efficient use of deep space
> links.
> 
> even when the stack and hardware are (over)engineered from the bottom up
> and the only errors and resend requests that are ever seen are from
> artificially injecting errors in tests? In this scenario, the custody
> transfer ack mechanism simply formally indicates that the entire bundle was
> received.

Not at all.  Carefully FEC'd as these links are, there always remains a non-zero rate of detected but uncorrectable bit errors, typically in the range 10^-6 to 10^-5.  (The rate of undetected bit errors is much lower, quite close to zero.)  Retransmitting an entire multi-megabyte bundle in response to each such error would be an inefficient use of the link.

> As you said on this list on 19 February:
> "In the DINET experiment we operated a DTN for a month over very noisy
> interplanetary R/F links without any corruption of headers or data at any
> time, thanks to the normal, quite robust CCSDS link-layer encoding."

Quite so.  There were no undetected bit errors, so such errors introduced no corruption of headers or data.  There were plenty of detected bit errors, and most of them were correctable; again, no corruption of headers or data.  There were a relatively small number of detected but uncorrectable bit errors; the frames in which these errors were detected were simply discarded, resulting in the detection of data loss -- not corruption -- in LTP, which caused retransmission.  Nothing very mysterious here.

Scott

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 22:26:42 +0000
To: Peter Lovell <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Clock synchronization in networks

> I have passed on to a few people the comments, discussed here earlier,
> about the relativistic correction required for correct operation of GPS.
> Every one has been incredulous that (a) synchronization was hard, and
> (b) that it was required in this situation. Sorry, Albert - people just
> don't understand.

Vint understood (a) years ago. Shame that understanding is not reflected in the bundle protocol design...

"Timing, for instance. Internet routers around the globe synchronize their clocks by the millisecond in order to coordinate the flow of packets. That synchronization is far more difficult when a significant fraction of a light-year separates a spacecraft's onboard clock from its reference clock. "The problem with the interplanetary environment is that there ain't no such thing as 'now,' " Cerf says."

-- Joab Jackson, The Interplanetary Internet, IEEE Spectrum, August 2005.

> I guess that various dtns will have
> their own definition of "good enough" but there will be a problem down
> the road. When the dedicated dtns we'll have at first start to
> interconnect then the differences will cause problems.

They'll never need to interconnect...

cheers

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 22:16:14 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

On 20 Nov 2009, at 20:20, Burleigh, Scott C (313B) wrote:

>> It strikes me that not having CFDP PDUs at all, and just sending (large)
>> files as bundles directly, so that there's one (custody transfer) ack per
>> bundle/file, would cut down the uplink traffic tremendously.
> 
> It would, but limiting ARQ to custody signals and retransmission at (large) bundle granularity wouldn't be an efficient use of deep space links.

even when the stack and hardware are (over)engineered from the bottom up and the only errors and resend requests that are ever seen are from artificially injecting errors in tests? In this scenario, the custody transfer ack mechanism simply formally indicates that the entire bundle was received.

As you said on this list on 19 February:
"In the DINET experiment we operated a DTN for a month over very noisy interplanetary R/F links without any corruption of headers or data at any time, thanks to the normal, quite robust CCSDS link-layer encoding."

so, given that FEC is adequate in this deep-space scenario, what would any ARQ-induced resends be relied on for? Everything should be sent as LTP green packets, because they can rely on the link encoding to get there first time...

puzzled,

L.

> 
>> Doesn't the CFDP-in-bundle-in-LTP blocks incur a lot of overheard - especially when
>> CFDP was designed to run directly over CCSDS and IP?
> 
> It incurs some overhead, no question.  What constitutes "a lot" is an engineering issue, of course.  You incur overhead to obtain some benefit; if the benefit doesn't justify the cost of the additional overhead -- or if you can get the same benefit at less net cost by some other means -- then you want a different design, but otherwise the overhead is by definition not excessive.
> 
> When we did the arithmetic for DINET we determined that the CFDP, BP, and LTP overhead was acceptable.  (BP/LTP header overhead was about the same as UDP/IP header overhead.)  Other missions might reach a different conclusion.
> 
> Scott

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Peter Lovell <[email-masked]>
To: Lloyd Wood <[email-masked]>, [email-masked]
Date: Fri, 20 Nov 2009 17:08:08 -0500
Subject: Re: [dtn-interest] Clock synchronization in networks

On Fri, Nov 20, 2009, Lloyd Wood <[email-masked]> wrote:

>http://arxiv.org/pdf/0911.3357
>Fundamentals of Large Sensor Networks: Connectivity, Capacity, Clocks
>and Computation
>Nikolaos M. Freris, Hemant Kowshik, and P. R. Kumar, 16 Nov 2009
>
>is an interesting read covering the problem of keeping time across
>networks, which this list has discussed for a couple of years now.
>
>"It was shown in [20], [17] that it is impossible to even synchronize
>just two clocks.
>[..]
>The following theorem [17] establishes the result that without any
>further assumptions, clock synchronization is impossible in any network."
>
>cheers,
>
>L.

Discussed indeed !  Sometimes it seems that it's discussed so much that
I forgot where we were going :)

I have passed on to a few people the comments, discussed here earlier,
about the relativistic correction required for correct operation of GPS.
Every one has been incredulous that (a) synchronization was hard, and
(b) that it was required in this situation. Sorry, Albert - people just
don't understand.

However, back to the topic at hand. I believe that we have two issues,
but maybe more. And they're related but not really close.

One is to deal with nodes that start out with no clock, and maybe never
have one. We make use of the clock for (a) uniquely identifying bundles,
and (b) deciding when their lifetime is up. But we don't have a way to
deal with nodes that never get a clock setting (unless they're in a
completely closed system, which is not so interesting).

A second is to describe how much synchronization is needed in a network.
In other words, perfection is impossible, as you say. So let's not let
that get in the way of the good. I guess that various dtns will have
their own definition of "good enough" but there will be a problem down
the road. When the dedicated dtns we'll have at first start to
interconnect then the differences will cause problems.

Because the timestamp is part of the PIB canonicalization, it can't be
"corrected". But we will need some way to have an "offset" or
"adjustment", especially at points where networks interconnect.

Comments anyone?

Cheers.....Peter

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 20:26:56 +0000
To: <[email-masked]>
Cc: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Clock synchronization in networks

http://arxiv.org/pdf/0911.3357
Fundamentals of Large Sensor Networks: Connectivity, Capacity, Clocks and Computation
Nikolaos M. Freris, Hemant Kowshik, and P. R. Kumar, 16 Nov 2009

is an interesting read covering the problem of keeping time across networks, which this list has discussed for a couple of years now.

"It was shown in [20], [17] that it is impossible to even synchronize just two clocks.
[..]
The following theorem [17] establishes the result that without any further assumptions, clock synchronization is impossible in any network."

cheers,

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 12:20:13 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 11:05 AM
> To: Burleigh, Scott C (313B)
> Cc: Lloyd Wood; [email-masked]
> Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib
> 
> On 20 Nov 2009, at 16:54, Burleigh, Scott C (313B) wrote:
> 
> > Finally, yes, getting one ack for a set of bundles is indeed a huge win
> in the environment for which this CLA was designed.  We've got extremely
> asymmetric data rates, on the order of 1000:1, and a lot of the resistance
> to the use of CFDP that we've gotten from the Mars missions has been a
> concern that the volume of file acknowledgment traffic that would have to
> be sent over the tiny uplink pipe in any heavy file download episode would
> swamp that link.  Wrapping each CFDP PDU in a bundle and aggregating the
> bundles in large blocks solves that problem, decoupling the acknowledgment
> data rate from the volume of file download activity.
> 
> Hmmm. Saratoga's running at 40Mbps downlink to 19k2 uplink for LEO - that's
> just over 2000:1, and likely to go higher on future missions. A pretty
> similar setup to what you describe for deep space; large amounts of data
> down, just TT&C up.
> 
> Tricks in use to minimize uplink traffic include:
> - aggregating requests for data into one if there's just a few blocks
> between some holes; resending data is cheap.
> - altering the rate at which acks are requested from the receiver. Faster
> downlink == longer gaps between requests for acks giving receiver status.

Which is what LTP block aggregation does.  Using larger blocks increases the interval between checkpoints (requests for acks).

> It strikes me that not having CFDP PDUs at all, and just sending (large)
> files as bundles directly, so that there's one (custody transfer) ack per
> bundle/file, would cut down the uplink traffic tremendously.

It would, but limiting ARQ to custody signals and retransmission at (large) bundle granularity wouldn't be an efficient use of deep space links.

> Doesn't the CFDP-in-bundle-in-LTP blocks incur a lot of overheard - especially when
> CFDP was designed to run directly over CCSDS and IP?

It incurs some overhead, no question.  What constitutes "a lot" is an engineering issue, of course.  You incur overhead to obtain some benefit; if the benefit doesn't justify the cost of the additional overhead -- or if you can get the same benefit at less net cost by some other means -- then you want a different design, but otherwise the overhead is by definition not excessive.

When we did the arithmetic for DINET we determined that the CFDP, BP, and LTP overhead was acceptable.  (BP/LTP header overhead was about the same as UDP/IP header overhead.)  Other missions might reach a different conclusion.

Scott

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Nov 2009 19:05:06 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

On 20 Nov 2009, at 16:54, Burleigh, Scott C (313B) wrote:

> Finally, yes, getting one ack for a set of bundles is indeed a huge win in the environment for which this CLA was designed.  We've got extremely asymmetric data rates, on the order of 1000:1, and a lot of the resistance to the use of CFDP that we've gotten from the Mars missions has been a concern that the volume of file acknowledgment traffic that would have to be sent over the tiny uplink pipe in any heavy file download episode would swamp that link.  Wrapping each CFDP PDU in a bundle and aggregating the bundles in large blocks solves that problem, decoupling the acknowledgment data rate from the volume of file download activity.

Hmmm. Saratoga's running at 40Mbps downlink to 19k2 uplink for LEO - that's just over 2000:1, and likely to go higher on future missions. A pretty similar setup to what you describe for deep space; large amounts of data down, just TT&C up.

Tricks in use to minimize uplink traffic include:
- aggregating requests for data into one if there's just a few blocks between some holes; resending data is cheap.
- altering the rate at which acks are requested from the receiver. Faster downlink == longer gaps between requests for acks giving receiver status.

It strikes me that not having CFDP PDUs at all, and just sending (large) files as bundles directly, so that there's one (custody transfer) ack per bundle/file, would cut down the uplink traffic tremendously. Doesn't the CFDP-in-bundle-in-LTP blocks incur a lot of overheard - especially when CFDP was designed to run directly over CCSDS and IP?

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Fri, 20 Nov 2009 10:59:49 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

Sure, I'll add it to my list of Internet Drafts that I'm going to be writing.  Soon.

Scott

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 9:14 AM
> To: Burleigh, Scott C (313B)
> Cc: Ivancic, William D. (GRC-RHN0); [email-masked]
> research.net
> Subject: Re: [dtn-users] DTN2 & LTPlib
> 
> 
> Hi Scott,
> 
> So it sounds like someone (named Burleigh perhaps:-) could
> document an LTP CL that says how to put N bundles into one
> LTP session, presumably with "critical" bundles first and
> red, and less important ones (however those are defined)
> last and green. We'd be happy to help out with that as we
> do the DTN2/LTPlib integration here.
> 
> S.
> 
> Burleigh, Scott C (313B) wrote:
> > [Moving thread out of the dtn-users list.]
> >
> > Will, yes, this is strictly the way the LTP convergence-layer adapter is
> implemented in ION, which is all that Stephen was asking about.  It's not
> part of the LTP specification, though it's entirely conformant: the spec is
> silent on the structure of the user application data block that is
> transmitted during a single LTP session.
> >
> > The ION implementation of LTP itself (setting this CL adapter aside for
> the moment) complies fully with the spec, as far as I know;
> interoperability with other implementations should be no problem.
> >
> > It might very well be the case that it would make sense to draft an LTPCL
> spec that documents this design.  That hasn't been an issue up to now,
> because the CLA wasn't being used in a multi-implementation environment,
> but it's not a bad idea.
> >
> > Stephen, you're right, this CLA design does not exploit the LTP feature
> that a single block can be partially red and partially green.  In the
> application environment for which it was developed (conveying DTN bundles
> in space flight mission communications), that feature doesn't have any
> obvious utility.  Even without aggregation -- i.e., a single bundle per
> block -- it wouldn't have a lot of utility in that environment, since it's
> not clear that it would ever do anybody any good to receive the pre-payload
> blocks of a bundle reliably but part or all of the payload and post-payload
> block(s) unreliably.
> >
> > The CLA *does* use both red and green transmission, but only as applied
> to the entire block of N bundles; this is actually very useful, simplifying
> the implementation of the "critical bundles" feature of the Extended Class
> of Service extension that I plan to document Any Day Now.  And the
> inutility of partially-red transmission in this particular application
> environment says nothing about the usefulness of the feature in general.
> Where LTP is used on its own -- e.g., as a transport protocol in a LAN --
> it can be very valuable, as your own applications demonstrate.
> >
> > Finally, yes, getting one ack for a set of bundles is indeed a huge win
> in the environment for which this CLA was designed.  We've got extremely
> asymmetric data rates, on the order of 1000:1, and a lot of the resistance
> to the use of CFDP that we've gotten from the Mars missions has been a
> concern that the volume of file acknowledgment traffic that would have to
> be sent over the tiny uplink pipe in any heavy file download episode would
> swamp that link.  Wrapping each CFDP PDU in a bundle and aggregating the
> bundles in large blocks solves that problem, decoupling the acknowledgment
> data rate from the volume of file download activity.
> >
> > Scott
> >
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[email-masked]]
> >> Sent: Friday, November 20, 2009 5:16 AM
> >> To: Ivancic, William D. (GRC-RHN0)
> >> Cc: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; dtn-users mailing list
> >> Subject: Re: [dtn-users] DTN2 & LTPlib
> >>
> >>
> >>
> >> Ivancic, William D. (GRC-RHN0) wrote:
> >>>> Good question.  One of the major advantages of LTP that I've been
> >>>> trumpeting here is that unlike CFDP it gives you a degree of control
> >>>> over the data rate of acknowledgement traffic.  Acknowledgements are
> at
> >>>> block granularity, so if you aggregate multiple files (for example)
> into
> >>>> a single LTP block you'll only get a single ack for the whole lot
> rather
> >>>> than one for each file as with acknowledged CFDP.
> >>> Scott, is this part of the specification or a particular implementation
> >> or special case implementation?
> >>> What I mean is, will this cause interoperability problems with other
> >> independent implementations of LTP?
> >>> If this aggregation is not part of the specification, should it be?
> >> Good question. If we want to use this more broadly then it'd call for
> >> an LTP CL spec to be written that says how to do this. If that's the
> >> plan then we should discuss that on the dtn-interest list rather than
> >> here.
> >>
> >> However, its a bit odd though - it seems to make all the red/green stuff
> >> in LTP meaningless doesn't it?
> >>
> >> I'm also not that sure of the benefits of getting one ack for a set of
> >> bundles - is that really a huge win?
> >>
> >> S.
> >>
> >
> >

Date: Fri, 20 Nov 2009 17:14:19 +0000
From: Stephen Farrell <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

Hi Scott,

So it sounds like someone (named Burleigh perhaps:-) could
document an LTP CL that says how to put N bundles into one
LTP session, presumably with "critical" bundles first and
red, and less important ones (however those are defined)
last and green. We'd be happy to help out with that as we
do the DTN2/LTPlib integration here.

S.

Burleigh, Scott C (313B) wrote:
> [Moving thread out of the dtn-users list.]
> 
> Will, yes, this is strictly the way the LTP convergence-layer adapter is implemented in ION, which is all that Stephen was asking about.  It's not part of the LTP specification, though it's entirely conformant: the spec is silent on the structure of the user application data block that is transmitted during a single LTP session.
> 
> The ION implementation of LTP itself (setting this CL adapter aside for the moment) complies fully with the spec, as far as I know; interoperability with other implementations should be no problem.
> 
> It might very well be the case that it would make sense to draft an LTPCL spec that documents this design.  That hasn't been an issue up to now, because the CLA wasn't being used in a multi-implementation environment, but it's not a bad idea.
> 
> Stephen, you're right, this CLA design does not exploit the LTP feature that a single block can be partially red and partially green.  In the application environment for which it was developed (conveying DTN bundles in space flight mission communications), that feature doesn't have any obvious utility.  Even without aggregation -- i.e., a single bundle per block -- it wouldn't have a lot of utility in that environment, since it's not clear that it would ever do anybody any good to receive the pre-payload blocks of a bundle reliably but part or all of the payload and post-payload block(s) unreliably.
> 
> The CLA *does* use both red and green transmission, but only as applied to the entire block of N bundles; this is actually very useful, simplifying the implementation of the "critical bundles" feature of the Extended Class of Service extension that I plan to document Any Day Now.  And the inutility of partially-red transmission in this particular application environment says nothing about the usefulness of the feature in general.  Where LTP is used on its own -- e.g., as a transport protocol in a LAN -- it can be very valuable, as your own applications demonstrate.
> 
> Finally, yes, getting one ack for a set of bundles is indeed a huge win in the environment for which this CLA was designed.  We've got extremely asymmetric data rates, on the order of 1000:1, and a lot of the resistance to the use of CFDP that we've gotten from the Mars missions has been a concern that the volume of file acknowledgment traffic that would have to be sent over the tiny uplink pipe in any heavy file download episode would swamp that link.  Wrapping each CFDP PDU in a bundle and aggregating the bundles in large blocks solves that problem, decoupling the acknowledgment data rate from the volume of file download activity.
> 
> Scott
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[email-masked]]
>> Sent: Friday, November 20, 2009 5:16 AM
>> To: Ivancic, William D. (GRC-RHN0)
>> Cc: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; dtn-users mailing list
>> Subject: Re: [dtn-users] DTN2 & LTPlib
>>
>>
>>
>> Ivancic, William D. (GRC-RHN0) wrote:
>>>> Good question.  One of the major advantages of LTP that I've been
>>>> trumpeting here is that unlike CFDP it gives you a degree of control
>>>> over the data rate of acknowledgement traffic.  Acknowledgements are at
>>>> block granularity, so if you aggregate multiple files (for example) into
>>>> a single LTP block you'll only get a single ack for the whole lot rather
>>>> than one for each file as with acknowledged CFDP.
>>> Scott, is this part of the specification or a particular implementation
>> or special case implementation?
>>> What I mean is, will this cause interoperability problems with other
>> independent implementations of LTP?
>>> If this aggregation is not part of the specification, should it be?
>> Good question. If we want to use this more broadly then it'd call for
>> an LTP CL spec to be written that says how to do this. If that's the
>> plan then we should discuss that on the dtn-interest list rather than
>> here.
>>
>> However, its a bit odd though - it seems to make all the red/green stuff
>> in LTP meaningless doesn't it?
>>
>> I'm also not that sure of the benefits of getting one ack for a set of
>> bundles - is that really a huge win?
>>
>> S.
>>
> 
> 

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 20 Nov 2009 08:54:47 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] [dtn-users] DTN2 & LTPlib

[Moving thread out of the dtn-users list.]

Will, yes, this is strictly the way the LTP convergence-layer adapter is implemented in ION, which is all that Stephen was asking about.  It's not part of the LTP specification, though it's entirely conformant: the spec is silent on the structure of the user application data block that is transmitted during a single LTP session.

The ION implementation of LTP itself (setting this CL adapter aside for the moment) complies fully with the spec, as far as I know; interoperability with other implementations should be no problem.

It might very well be the case that it would make sense to draft an LTPCL spec that documents this design.  That hasn't been an issue up to now, because the CLA wasn't being used in a multi-implementation environment, but it's not a bad idea.

Stephen, you're right, this CLA design does not exploit the LTP feature that a single block can be partially red and partially green.  In the application environment for which it was developed (conveying DTN bundles in space flight mission communications), that feature doesn't have any obvious utility.  Even without aggregation -- i.e., a single bundle per block -- it wouldn't have a lot of utility in that environment, since it's not clear that it would ever do anybody any good to receive the pre-payload blocks of a bundle reliably but part or all of the payload and post-payload block(s) unreliably.

The CLA *does* use both red and green transmission, but only as applied to the entire block of N bundles; this is actually very useful, simplifying the implementation of the "critical bundles" feature of the Extended Class of Service extension that I plan to document Any Day Now.  And the inutility of partially-red transmission in this particular application environment says nothing about the usefulness of the feature in general.  Where LTP is used on its own -- e.g., as a transport protocol in a LAN -- it can be very valuable, as your own applications demonstrate.

Finally, yes, getting one ack for a set of bundles is indeed a huge win in the environment for which this CLA was designed.  We've got extremely asymmetric data rates, on the order of 1000:1, and a lot of the resistance to the use of CFDP that we've gotten from the Mars missions has been a concern that the volume of file acknowledgment traffic that would have to be sent over the tiny uplink pipe in any heavy file download episode would swamp that link.  Wrapping each CFDP PDU in a bundle and aggregating the bundles in large blocks solves that problem, decoupling the acknowledgment data rate from the volume of file download activity.

Scott

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, November 20, 2009 5:16 AM
> To: Ivancic, William D. (GRC-RHN0)
> Cc: Burleigh, Scott C. (JPL-313B)[Caltech-JPL]; dtn-users mailing list
> Subject: Re: [dtn-users] DTN2 & LTPlib
> 
> 
> 
> Ivancic, William D. (GRC-RHN0) wrote:
> >> Good question.  One of the major advantages of LTP that I've been
> >> trumpeting here is that unlike CFDP it gives you a degree of control
> >> over the data rate of acknowledgement traffic.  Acknowledgements are at
> >> block granularity, so if you aggregate multiple files (for example) into
> >> a single LTP block you'll only get a single ack for the whole lot rather
> >> than one for each file as with acknowledged CFDP.
> >
> > Scott, is this part of the specification or a particular implementation
> or special case implementation?
> >
> > What I mean is, will this cause interoperability problems with other
> independent implementations of LTP?
> >
> > If this aggregation is not part of the specification, should it be?
> 
> Good question. If we want to use this more broadly then it'd call for
> an LTP CL spec to be written that says how to do this. If that's the
> plan then we should discuss that on the dtn-interest list rather than
> here.
> 
> However, its a bit odd though - it seems to make all the red/green stuff
> in LTP meaningless doesn't it?
> 
> I'm also not that sure of the benefits of getting one ack for a set of
> bundles - is that really a huge win?
> 
> S.
> 

Date: Fri, 20 Nov 2009 15:06:02 +0100
From: Anders Lindgren <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

An updated version of the PRoPHET draft (with comments from Stephen,
Kevin, and others addressed) is now posted at:

http://www.ietf.org/id/draft-irtf-dtnrg-prophet-03.txt

/A

On Fri, Nov 20, 2009 at 2:25 PM, Stephen Farrell
<[email-masked]> wrote:
>
> So I've started the IRSG review for the 5 drafts
> named below. Premature congratulations to all the
> authors involved:-)
>
> draft-irtf-dtnrg-sdnv
> draft-irtf-dtnrg-bundle-previous-hop-block
> draft-irtf-dtnrg-bundle-metadata-block
> draft-irtf-dtnrg-cbhe
> draft-irtf-dtnrg-bundle-security
>
> Once updates are posted I hope to be able to
> do the same for the last two:
>
> draft-irtf-dtnrg-prophet
> draft-irtf-dtnrg-bundle-retrans-block
>
> Stephen.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 20 Nov 2009 07:48:13 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTNRG docs that are....done?

Clarification:  ION currently used CBHE when "ipn" naming is used.  ION currently does not operate without using CBHE for "ipn" naming.  Thus for DTN2 and ION to interoperate using "ipn" naming, DTN2 must use CBHE.

=====
My colleague, Alan Hylton is working on CBHE for DTN2 as we need this for interoperability between ION and DTN2.  The current ION implementation defaults to CBHE.  Anyway, this should provide an independent implementation of CBHE so long as we do not try and lift the ION code.  Any ambiguities in the specification hopefully will be indentified during this process.

--Will

>-----Original Message-----
>From: .. Stephen Farrell
>Sent: Friday, November 20, 2009 8:26 AM
>To: [email-masked]
>Subject: Re: [dtn-interest] DTNRG docs that are....done?
>
>
>So I've started the IRSG review for the 5 drafts
>named below. 
.....
>draft-irtf-dtnrg-cbhe

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 20 Nov 2009 07:45:40 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Recall:  DTNRG docs that are....done?

Ivancic, William D. (GRC-RHN0) would like to recall the message, "[dtn-interest] DTNRG docs that are....done?".

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 20 Nov 2009 07:44:03 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] DTNRG docs that are....done?

My colleague, Alan Hylton is working on CBHE for DTN2 as we need this for interoperability between ION and DTN2.  The current ION implementation defaults to CBHE.  Anyway, this should provide an independent implementation of CBHE so long as we do not try and lift the ION code.  Any ambiguities in the specification hopefully will be indentified during this process.

--Will

>-----Original Message-----
>From: .. Stephen Farrell
>Sent: Friday, November 20, 2009 8:26 AM
>To: [email-masked]
>Subject: Re: [dtn-interest] DTNRG docs that are....done?
>
>
>So I've started the IRSG review for the 5 drafts
>named below. 
.....
>draft-irtf-dtnrg-cbhe

Date: Fri, 20 Nov 2009 13:25:45 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

So I've started the IRSG review for the 5 drafts
named below. Premature congratulations to all the
authors involved:-)

draft-irtf-dtnrg-sdnv
draft-irtf-dtnrg-bundle-previous-hop-block
draft-irtf-dtnrg-bundle-metadata-block
draft-irtf-dtnrg-cbhe
draft-irtf-dtnrg-bundle-security

Once updates are posted I hope to be able to
do the same for the last two:

draft-irtf-dtnrg-prophet
draft-irtf-dtnrg-bundle-retrans-block

Stephen.

From: F L <[email-masked]>
To: [email-masked]
Date: Thu, 19 Nov 2009 14:18:25 +0100
Subject: [dtn-interest] MobiOpp'10 -- Call for Demos

--Apple-Mail-49--990851976
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

[Our apologies for possible duplicates]
--------------------------------------------------------------------------------------------

CALL FOR DEMOS (PDF version: http://cnd.iit.cnr.it/mobiopp2010/CfDemo.pdf)
Second International Workshop on Mobile Opportunistic Networking ACM/ 
SIGMOBILE MobiOpp 2010
http://cnd.iit.cnr.it/mobiopp2010/

Sponsored by ACM and Sigmobile

February 22-23, 2010, Pisa, Italy

MobiOpp 2010 will provide a high profile, leading edge forum for  
researchers and engineers to present their latest research in the  
field of mobile opportunistic networking.
Real experimentation has proven to be a fundamental methodology to  
evaluate opportunistic networking.
Early prototyping is an outstanding way to understand real user  
requirements and help adoption of opportunistic networking paradigm by  
the mass market.

The demo session showing real-systems prototypes at work will  
naturally complement the technical session, thus stimulating  
discussions among attendees.

Demonstration proposals from both academia and industry are sought.

********************* HIGHLIGHTS  
****************************************
- Authors of all accepted demos will be invited to provide a SHORT  
DEMO PAPER (3 pages) describing the demo features. Short demo papers  
will be included in the MobiOpp proceedings.

- MobiOpp 2010 will grant a "Best Demo Award" based on both the  
technical contribution and the innovation. The "Best Demo Award" is  
sponsored by EU FP6 ANA Project (http://ana-project.org/).

- At least one author of each accepted demo is required to register  
and present their demo at the conference.
*************************************************************************

Demo proposals must show a significant relevance to opportunistic  
networking. Submissions should adhere to the ACM conference  
proceedings format and be no more than three pages in length  
(including references, figures and tables, at least 10pt font). For  
the format, please refer to  the ACM conference proceedings guidelines  
available at http://www.acm.org/sigs/publications/proceedings- 
templates. All submitted papers will undergo a rigorous review process.

Demo proposals must describe the demo research framework, and what  
MobiOpp attendees will be able to enjoy and experiment.
The proposal MUST also include the technical requirements for the  
demo. These pieces of information will be taken into consideration,
together with the technical value of the proposed demo, in the review  
process, to ensure the demo feasibility within the MobiOpp program and  
the potential impact on the attendees.
Demo proposals must be submitted as a SINGLE PDF FILE via e-mail to  
the demo co-chairs ([email-masked] and  
[email-masked]), with Subject: MobiOpp 2010 Demo Submission.

Authors will be encouraged to prepare a poster to illustrate their demo.

Topics of interest include, but are not limited to:

- Advanced technologies for enabling opportunistic communication
- Middleware services and agent technologies
- Mobile/wireless computing systems & services in opportunistic  
scenarios
- Novel/innovative opportunistic networking applications
- Opportunistic networking architectures
- Smart devices and intelligent environments
- Trust, security and privacy issues in opportunistic networking
- User interfaces and interaction models
- Immersive opportunistic communications
- Wearable computers
- Application scenarios for opportunistic networks
- Middleware services in opportunistic networks
- Dissemination and replication techniques for opportunistic networking
- Resource management techniques for opportunistic networks
- Opportunistic Networking in Wireless Sensor Networks
- Security issues in opportunistic networks
- Cooperation in opportunistic networks
- Biological and social models for opportunistic communication

Important Dates:

Submission deadline:      	 December 10, 2009
Acceptance notification:   	January 15, 2010
Camera-ready deadline:    January 22, 2010
Conference date:          	February 22-23, 2010

--
Laura Galluccio, University of Catania, Italy
Franck Legendre, ETH Zurich, Switzerland
IEEE MobiOpp 2010 Demo Co-Chairs
--Apple-Mail-49--990851976
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div>[Our apologies for =
possible =
duplicates]</div><div>----------------------------------------------------=
----------------------------------------</div><div><br></div><div>CALL =
FOR DEMOS (PDF version:&nbsp;<a =
href=3D"http://cnd.iit.cnr.it/mobiopp2010/CfDemo.pdf">http://cnd.iit.cnr.i=
t/mobiopp2010/CfDemo.pdf</a>)</div><div>Second International Workshop on =
Mobile Opportunistic Networking ACM/SIGMOBILE MobiOpp 2010</div><div><a =
href=3D"http://cnd.iit.cnr.it/mobiopp2010/">http://cnd.iit.cnr.it/mobiopp2=
010/</a></div><div><br></div><div>Sponsored by ACM and =
Sigmobile</div><div><br></div><div>February 22-23, 2010, Pisa, =
Italy</div><div><br></div><div>MobiOpp 2010 will provide a high profile, =
leading edge forum for researchers and engineers to present their latest =
research in the field of mobile opportunistic networking.</div><div>Real =
experimentation has proven to be a fundamental methodology to evaluate =
opportunistic networking.</div><div>Early prototyping is an outstanding =
way to understand real user requirements and help adoption of =
opportunistic networking paradigm by the mass =
market.</div><div><br></div><div>The demo session showing real-systems =
prototypes at work will naturally complement the technical session, thus =
stimulating discussions among =
attendees.</div><div><br></div><div>Demonstration proposals from both =
academia and industry are =
sought.</div><div><br></div><div>********************* HIGHLIGHTS =
****************************************</div><div>- Authors of all =
accepted demos will be invited to provide a SHORT DEMO PAPER (3 pages) =
describing the demo features. Short demo papers will be included in the =
MobiOpp proceedings.</div><div><br></div><div>- MobiOpp 2010 will grant =
a "Best Demo Award" based on both the technical contribution and the =
innovation. The "Best Demo Award" is sponsored by EU FP6 ANA Project (<a =
href=3D"http://ana-project.org/">http://ana-project.org/</a>).</div><div><=
br></div><div>- At least one author of each accepted demo is required to =
register and present their demo at the =
conference.</div><div>****************************************************=
*********************</div><div><br></div><div>Demo proposals must show =
a significant relevance to opportunistic networking. Submissions should =
adhere to the ACM conference proceedings format and be no more than =
three pages in length (including references, figures and tables, at =
least 10pt font). For the format, please refer to &nbsp;the ACM =
conference proceedings guidelines available at&nbsp;<a =
href=3D"http://www.acm.org/sigs/publications/proceedings-templates">http:/=
/www.acm.org/sigs/publications/proceedings-templates</a>. All submitted =
papers will undergo a rigorous review =
process.</div><div><br></div><div><div>Demo proposals must describe the =
demo research framework, and what MobiOpp attendees will be able to =
enjoy and experiment.</div><div>The proposal MUST also include the =
technical requirements for the demo. These pieces of information will be =
taken into consideration,&nbsp;</div><div>together with the technical =
value of the proposed demo, in the review process, to ensure the demo =
feasibility within the MobiOpp&nbsp;program and the potential impact on =
the attendees.</div><div>Demo proposals must be submitted as a SINGLE =
PDF FILE via e-mail to the demo co-chairs (<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&nbsp=
;and&nbsp;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>), =
with Subject: MobiOpp 2010 Demo =
Submission.</div><div><br></div><div>Authors will be encouraged to =
prepare a poster to illustrate their =
demo.</div><div><br></div><div>Topics of interest include, but are not =
limited to:</div><div><br></div><div>- Advanced technologies for =
enabling opportunistic communication</div><div>- Middleware services and =
agent technologies</div><div>- Mobile/wireless computing systems &amp; =
services in opportunistic scenarios</div><div>- Novel/innovative =
opportunistic networking applications</div><div>- Opportunistic =
networking architectures</div><div>- Smart devices and intelligent =
environments</div><div>- Trust, security and privacy issues in =
opportunistic networking</div><div>- User interfaces and interaction =
models</div><div>- Immersive opportunistic communications</div><div>- =
Wearable computers</div><div>- Application scenarios for opportunistic =
networks</div><div>- Middleware services in opportunistic =
networks</div><div>- Dissemination and replication techniques for =
opportunistic networking</div><div>- Resource management techniques for =
opportunistic networks</div><div>- Opportunistic Networking in Wireless =
Sensor Networks</div><div>- Security issues in opportunistic =
networks</div><div>- Cooperation in opportunistic networks</div><div>- =
Biological and social models for opportunistic =
communication</div><div><br></div><div><br></div><div>Important =
Dates:</div><div><br></div><div>Submission deadline: &nbsp; &nbsp; =
&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
</span>&nbsp;December 10, 2009</div><div>Acceptance notification: =
&nbsp;&nbsp;<span class=3D"Apple-tab-span" style=3D"white-space: pre; ">	=
</span>January 15, 2010</div><div>Camera-ready deadline: &nbsp; =
&nbsp;January 22, 2010</div><div>Conference date: &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;<span class=3D"Apple-tab-span" style=3D"white-space: pre; =
">	</span>February 22-23, =
2010</div><div><br></div><div>--</div><div>Laura Galluccio, University =
of Catania, Italy</div><div>Franck Legendre, ETH Zurich, =
Switzerland</div><div>IEEE MobiOpp 2010 Demo =
Co-Chairs</div></div></body></html>=

--Apple-Mail-49--990851976--

Date: Wed, 18 Nov 2009 10:02:34 +0200
From: Joerg Ott <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

I suppose you would need to know the size once you start creating the
payload block.  So, you cannot really wait that long.  For most (if
not all) practical terms, I'd say the size be known when you start
shoving a bundle down to the convergence layer.  (Even in the rare
case of an ultra-efficient cut-through router for bundles, you
would this information fairly early in the process, but this may
be a bit of grey-ish area).

Joerg

Kevin Fall wrote:
> that would work ok assuming you know the size of the bundle ahead of 
> time.  If you are creating it on the fly and doing streaming [something 
> we've discussed from time to time], this would present a bit difficult.
> 
> - K
> 
> 
> On Nov 17, 2009, at Nov 176:57 AMPST, Scott, Keith L. wrote:
> 
>> The 'old' (DTN1) TCPCL included the bundle length in the CL header 
>> that was part of the bundle.  I haven't checked the current code to 
>> see if the TCPCL knows the whole length at the beginning of the 
>> bundle, but presumably it could, and could carry that length as an 
>> SDNV in the CL protocol at the beginning of bundle transfer.
>>
>>         --keith
>>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf 
>> Of Joerg Ott
>> Sent: Tuesday, November 17, 2009 2:46 AM
>> To: Peter Lovell
>> Cc: dtn interest
>> Subject: Re: [dtn-interest] TCPCL issue
>>
>> Hi Peter,
>>
>>>> You can figure it out by peeking into the bundle header, but this
>>>> does not appear very clean.
>>>
>>> Hi J�rg,
>>>
>>> I'm puzzled. By "bundle header" I assume you mean the primary block. But
>>> that doesn't contain a field for the payload size.
>>>
>>> Perhaps you mean to peek at the block header of the payload, which will
>>> typically be "not too far" from the start of the bundle?
>>
>> I guess I was somehwat imprecise here.  Yes, you are right.
>> The problem is that you need to peek at something contained
>> in the bundle blocks which requires knowledge of this very
>> structure at the convergence layer.
>>
>> I am not arguing purity of layering here; it's just that you
>> may need to replicate some knowledge and code.
>>
>> Since we do have a mechanism at the convergence layer already
>> to reject an incoming bundle, we might as well add a mechanism
>> to identify one important reason for rejection.
>>
>> Since quite a bit of the thread is about DoS attacks: even if
>> you are not under a DoS attack, an incoming bundle might just
>> suck up more resources than you have.  So, why not provide
>> some mechanism to deal with it?
>>
>> Cheers,
>> Joerg
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Wed, 18 Nov 2009 05:14:10 +0000
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] naming a security source/destination?

Kevin Fall wrote:
> Hello list--
> 
> Regarding the "security source" and "security destination" concepts in  
> the security draft.... how exactly are these set up?  

Up to coders to choose that IMO.

> As EIDs, we have
> this issue once again as to which EID(s) a node is participating in,  

Not quite. In this case, I only care who has relevant keys and that
routing can somehow get the relevant bundles to visit nodes
participating (horrible term) in those EIDs.

> and in this context with respect to a particular block.  Is there a  
> current vision for how the EID  for a security source/destination  
> should be expressed?  Said another way, if I wanted to tell you I was  
> the security-destination for block B1, what EID (or other identifier)  
> would I use to convey this info?

Depends on how the sec-dest locally manages keys. If the different
EIDs for that host were e.g. in different processes or VMs then
you'd need to care. If OTOH, all sec-dest EIDs were in one process
that had access to all relevant keys, then it only matters for
logging purposes as far as I can see.

So, I think this case differs from e.g. the phb case.

S.

> 
> thx,
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Kevin Fall <[email-masked]>
Date: Tue, 17 Nov 2009 19:19:53 -0800
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

you can't really send large files over UDP/IP, at least not directly  
without doing anything else.

- K

On Nov 17, 2009, at Nov 177:22 AMPST, Ivancic, William D. (GRC-RHN0)  
wrote:

>
>> We actually already have a method for fragment authentication:  
>> since a
>> fragment is a bundle, the BAB authenticates it.  And this wouldn't  
>> help
>> much anyway, because there's no requirement that fragments be small.
>>
>> My inclination (as usual) is to try to keep the bundle protocol  
>> simple
>> by offloading this responsibility onto the convergence-layer  
>> adapters.
>> For some CLs, such as the current UDP CL, there is no problem: it's
>> impossible to send extremely large bundles.
>
> Could this be  considered a problem with the current UPD CL rather  
> than a feature?
>
> I can send large files over UDP/IP.  Why shouldn't one be able to  
> send large bundles?
>
>
> --Will
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
Date: Tue, 17 Nov 2009 19:18:18 -0800
To: Stephen Farrell <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

I guess this sort of brings up a question we have asked in the past--  
whether the CLA is really expected to provide more than a finite  
packet-type interface.  If we think the answer is 'no', then LTP/UDP  
or LTP/Ethernet or similar might be one approach.  However, I would  
expect (at least for Internet or Internet-like uses) that DCCP would  
be the more obvious choice.

I (at least at the moment) think I'd be ok dropping UDP CL in favor of  
a DCCP CL that supports large bundles.

- K

On Nov 17, 2009, at Nov 178:28 AMPST, Stephen Farrell wrote:

>
>
> Ivancic, William D. (GRC-RHN0) wrote:
>>> We actually already have a method for fragment authentication:  
>>> since a
>>> fragment is a bundle, the BAB authenticates it.  And this wouldn't  
>>> help
>>> much anyway, because there's no requirement that fragments be small.
>>>
>>> My inclination (as usual) is to try to keep the bundle protocol  
>>> simple
>>> by offloading this responsibility onto the convergence-layer  
>>> adapters.
>>> For some CLs, such as the current UDP CL, there is no problem: it's
>>> impossible to send extremely large bundles.
>>
>> Could this be  considered a problem with the current UPD CL rather  
>> than a feature?
>>
>> I can send large files over UDP/IP.  Why shouldn't one be able to  
>> send large bundles?
>
> So that's just an issue with the current UDPCL code, not really
> of broader interest. I hacked it to send large files when I
> needed that. Took about 10 minutes:-)
>
> Properly changing the UDPCL to handle larger bundles mightn't
> be that interesting though, one could just use LTP/UDP as a CL
> which'd be more or less the same.
>
> S.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
Date: Tue, 17 Nov 2009 19:07:58 -0800
To: "Scott, Keith L." <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

that would work ok assuming you know the size of the bundle ahead of  
time.  If you are creating it on the fly and doing streaming  
[something we've discussed from time to time], this would present a  
bit difficult.

- K

On Nov 17, 2009, at Nov 176:57 AMPST, Scott, Keith L. wrote:

> The 'old' (DTN1) TCPCL included the bundle length in the CL header  
> that was part of the bundle.  I haven't checked the current code to  
> see if the TCPCL knows the whole length at the beginning of the  
> bundle, but presumably it could, and could carry that length as an  
> SDNV in the CL protocol at the beginning of bundle transfer.
>
> 		--keith
>
> -----Original Message-----
> From: [email-masked] [mailto:dtn- 
> [email-masked]] On Behalf Of Joerg Ott
> Sent: Tuesday, November 17, 2009 2:46 AM
> To: Peter Lovell
> Cc: dtn interest
> Subject: Re: [dtn-interest] TCPCL issue
>
> Hi Peter,
>
>>> You can figure it out by peeking into the bundle header, but this
>>> does not appear very clean.
>>
>> Hi J�rg,
>>
>> I'm puzzled. By "bundle header" I assume you mean the primary  
>> block. But
>> that doesn't contain a field for the payload size.
>>
>> Perhaps you mean to peek at the block header of the payload, which  
>> will
>> typically be "not too far" from the start of the bundle?
>
> I guess I was somehwat imprecise here.  Yes, you are right.
> The problem is that you need to peek at something contained
> in the bundle blocks which requires knowledge of this very
> structure at the convergence layer.
>
> I am not arguing purity of layering here; it's just that you
> may need to replicate some knowledge and code.
>
> Since we do have a mechanism at the convergence layer already
> to reject an incoming bundle, we might as well add a mechanism
> to identify one important reason for rejection.
>
> Since quite a bit of the thread is about DoS attacks: even if
> you are not under a DoS attack, an incoming bundle might just
> suck up more resources than you have.  So, why not provide
> some mechanism to deal with it?
>
> Cheers,
> Joerg
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 17 Nov 2009 16:28:45 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "Burleigh, Scott C. \(JPL-313B\)\[Caltech-JPL\]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

Ivancic, William D. (GRC-RHN0) wrote:
>> We actually already have a method for fragment authentication: since a
>> fragment is a bundle, the BAB authenticates it.  And this wouldn't help
>> much anyway, because there's no requirement that fragments be small.
>>
>> My inclination (as usual) is to try to keep the bundle protocol simple
>> by offloading this responsibility onto the convergence-layer adapters.
>> For some CLs, such as the current UDP CL, there is no problem: it's
>> impossible to send extremely large bundles.  
> 
> Could this be  considered a problem with the current UPD CL rather than a feature?  
> 
> I can send large files over UDP/IP.  Why shouldn't one be able to send large bundles?  

So that's just an issue with the current UDPCL code, not really
of broader interest. I hacked it to send large files when I
needed that. Took about 10 minutes:-)

Properly changing the UDPCL to handle larger bundles mightn't
be that interesting though, one could just use LTP/UDP as a CL
which'd be more or less the same.

S.

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>,  Stephen Farrell <[email-masked]>, Joerg Ott <[email-masked]>
Date: Tue, 17 Nov 2009 09:22:40 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

>We actually already have a method for fragment authentication: since a
>fragment is a bundle, the BAB authenticates it.  And this wouldn't help
>much anyway, because there's no requirement that fragments be small.
>
>My inclination (as usual) is to try to keep the bundle protocol simple
>by offloading this responsibility onto the convergence-layer adapters.
>For some CLs, such as the current UDP CL, there is no problem: it's
>impossible to send extremely large bundles.  

Could this be  considered a problem with the current UPD CL rather than a feature?  

I can send large files over UDP/IP.  Why shouldn't one be able to send large bundles?  

--Will

From: "Scott, Keith L." <[email-masked]>
To: Joerg Ott <[email-masked]>, Peter Lovell <[email-masked]>
Date: Tue, 17 Nov 2009 09:57:11 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

The 'old' (DTN1) TCPCL included the bundle length in the CL header that was part of the bundle.  I haven't checked the current code to see if the TCPCL knows the whole length at the beginning of the bundle, but presumably it could, and could carry that length as an SDNV in the CL protocol at the beginning of bundle transfer.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joerg Ott
Sent: Tuesday, November 17, 2009 2:46 AM
To: Peter Lovell
Cc: dtn interest
Subject: Re: [dtn-interest] TCPCL issue

Hi Peter,

>> You can figure it out by peeking into the bundle header, but this
>> does not appear very clean.
> 
> Hi J�rg,
> 
> I'm puzzled. By "bundle header" I assume you mean the primary block. But
> that doesn't contain a field for the payload size.
> 
> Perhaps you mean to peek at the block header of the payload, which will
> typically be "not too far" from the start of the bundle?

I guess I was somehwat imprecise here.  Yes, you are right.
The problem is that you need to peek at something contained
in the bundle blocks which requires knowledge of this very
structure at the convergence layer.

I am not arguing purity of layering here; it's just that you
may need to replicate some knowledge and code.

Since we do have a mechanism at the convergence layer already
to reject an incoming bundle, we might as well add a mechanism
to identify one important reason for rejection.

Since quite a bit of the thread is about DoS attacks: even if
you are not under a DoS attack, an incoming bundle might just
suck up more resources than you have.  So, why not provide
some mechanism to deal with it?

Cheers,
Joerg
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>
Date: Tue, 17 Nov 2009 08:50:37 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

>> if you're using CFDP, for example, then CFDP becomes responsible for
>reassembling the original image file from CFDP file data segments in
>bundles.
>
>Of course, CFDP works directly with TCP and UDP, and doesn't require
>bundling. (Does CFDP have a 64K limit?)

The file for CFDP does not have a 64Kbyte limit, but the segments that get put into the datalink have a 64Kbyte limit.  Thus, if CFDP runs over DTN, DTN only sees a maximum bundle size of 64Kbytes.

So, CFDP over DTN looks like this (I'll use TCPCL as most understand that)

CFDP    File Transfer Application
DTN     Bundle Container (but CFDP view this a datalink)
TCPCL   Reliable Transport Convergence Layer
IP      Addressing and Routing
TBD	  Can be any datalink.  For CFDP, this is what CFDP usually interfaces too.

For those unfamiliar with Space Communication Protocols
CFDP CCSDS File Delivery Protocol
Is sort of a mix of file delivery and bundling all in one (think BP and LTP in one protocol)
http://public.ccsds.org/publications/archive/727x0b4.pdf

Page 5.1  PDU Data field length = 16  

Will

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Lloyd Wood <[email-masked]>, "Burleigh, Scott C. (JPL-313B)[Caltech-JPL]" <[email-masked]>
Date: Tue, 17 Nov 2009 08:50:37 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

>> if you're using CFDP, for example, then CFDP becomes responsible for
>reassembling the original image file from CFDP file data segments in
>bundles.
>
>Of course, CFDP works directly with TCP and UDP, and doesn't require
>bundling. (Does CFDP have a 64K limit?)

The file for CFDP does not have a 64Kbyte limit, but the segments that get put into the datalink have a 64Kbyte limit.  Thus, if CFDP runs over DTN, DTN only sees a maximum bundle size of 64Kbytes.

So, CFDP over DTN looks like this (I'll use TCPCL as most understand that)

CFDP    File Transfer Application
DTN     Bundle Container (but CFDP view this a datalink)
TCPCL   Reliable Transport Convergence Layer
IP      Addressing and Routing
TBD	  Can be any datalink.  For CFDP, this is what CFDP usually interfaces too.

For those unfamiliar with Space Communication Protocols
CFDP CCSDS File Delivery Protocol
Is sort of a mix of file delivery and bundling all in one (think BP and LTP in one protocol)
http://public.ccsds.org/publications/archive/727x0b4.pdf

Page 5.1  PDU Data field length = 16  

Will

Date: Tue, 17 Nov 2009 09:46:24 +0200
From: Joerg Ott <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

Hi Peter,

>> You can figure it out by peeking into the bundle header, but this
>> does not appear very clean.
> 
> Hi J�rg,
> 
> I'm puzzled. By "bundle header" I assume you mean the primary block. But
> that doesn't contain a field for the payload size.
> 
> Perhaps you mean to peek at the block header of the payload, which will
> typically be "not too far" from the start of the bundle?

I guess I was somehwat imprecise here.  Yes, you are right.
The problem is that you need to peek at something contained
in the bundle blocks which requires knowledge of this very
structure at the convergence layer.

I am not arguing purity of layering here; it's just that you
may need to replicate some knowledge and code.

Since we do have a mechanism at the convergence layer already
to reject an incoming bundle, we might as well add a mechanism
to identify one important reason for rejection.

Since quite a bit of the thread is about DoS attacks: even if
you are not under a DoS attack, an incoming bundle might just
suck up more resources than you have.  So, why not provide
some mechanism to deal with it?

Cheers,
Joerg

From: Kevin Fall <[email-masked]>
Date: Mon, 16 Nov 2009 16:12:10 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] naming a security source/destination?

Hello list--

Regarding the "security source" and "security destination" concepts in  
the security draft.... how exactly are these set up?  As EIDs, we have  
this issue once again as to which EID(s) a node is participating in,  
and in this context with respect to a particular block.  Is there a  
current vision for how the EID  for a security source/destination  
should be expressed?  Said another way, if I wanted to tell you I was  
the security-destination for block B1, what EID (or other identifier)  
would I use to convey this info?

thx,
- K

Date: Mon, 16 Nov 2009 22:13:12 +0000
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

I think this thread is going a bit off base. If there's
a threat to consider maybe someone can be specific?

If we want to discuss optimal fragmentation strategies,
that's fine, but a different topic.

Ivancic, William D. (GRC-RHN0) wrote:
> IPsec only works for IP!  What about CCSDS datalinks or direct datalink like BBN is working.  

I dunno. The subject line referred to TCP, which I guess generally
can run over IPsec. I don't know enough about CCSDS lower layers to
know what DoS problems and mitigations are relevant.

S.

From: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 21:36:11 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

inline...

On 16 Nov 2009, at 20:15, Burleigh, Scott C (313B) wrote:

>> -----Original Message-----
>> From: Lloyd Wood [mailto:[email-masked]]
>> Sent: Monday, November 16, 2009 11:34 AM
>> To: Burleigh, Scott C (313B)
>> Cc: Lloyd Wood; Joseph Ishac; [email-masked];
>> Delay Tolerant Networking Interest List
>> Subject: Re: [dtn-interest] TCPCL issue
>> 
>> On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:
>> 
>>> Let's quantify "overhead nightmare".  Do we call it an overhead nightmare
>> when we send a GB image over the Internet?  In IPv4 packets that are
>> limited to 64KB each?  You've got an "overhead nightmare" if there is so
>> much metadata accompanying your data that your ability to move all
>> significant application data through the network is deeply impaired.  If
>> you've got bandwidth to burn, "overhead" is irrelevant.
>> 
>> No.
> 
> Yes.

No. The scenarios bundling was envisaged for do not have bandwidth to burn. They're often running at capacity transferring large quantities of data over slow and unreliable links.

>> If you're moving a GB image in a large series of sequential 64KB bundles,
>> then the application, rather than the convergence layer, becomes
>> responsible for ordering, sending, resending and reassembly of the bundles
>> to create the delivered image.
> 
> No, if you're using bundle fragmentation then bundle protocol becomes responsible for reassembling the original bundle (containing the entire image) from fragmentary bundles;

But you're in favour of sending bundles not larger than 64K. Any bundle fragments handled by the bundle layer will be even less than 64K.

If the application has to consider how to break a large file into 64K bundles, the bundle layer is offloading functionality to the application.

Fragmenting (better, segmenting, since bundle fragments are not produced) the file into multiple bundles can be avoided. 

> if you're using CFDP, for example, then CFDP becomes responsible for reassembling the original image file from CFDP file data segments in bundles.  

Of course, CFDP works directly with TCP and UDP, and doesn't require bundling. (Does CFDP have a 64K limit?)

> BP is always responsible for sending the bundles.  Resending bundles is a BP responsibility in the event that you're doing custody transfer,

How so? There's no resend mechanism implemented with custody transfer.

> and retransmission at the convergence layer can (and I believe should) minimize custodial retransmission.  "Ordering" bundles isn't necessary.

retransmission at the convergence layer can and should minimize application-level retransmission.

If 64KB bundles are being sent to carry a 1GB file, instead of sending that as a 1GB bundle, ordering in the buffer becomes necessary at the application layer.

> 
>> In other words, the application takes on a number of things that the
>> convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP
>> segmentation and ordered delivery with yet another series of buffers that
>> deal in bundles rather than in segments.
> 
> No, the application may or may not take on one thing that applications sometimes do: reassembly of the application data unit from portions of that application data unit, e.g., by reading from a TCP socket multiple times.

...and re-requesting missing bundles that haven't arrived... there's more than one thing here.

L.

> 
> Scott

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 21:36:11 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

inline...

On 16 Nov 2009, at 20:15, Burleigh, Scott C (313B) wrote:

>> -----Original Message-----
>> From: Lloyd Wood [mailto:[email-masked]]
>> Sent: Monday, November 16, 2009 11:34 AM
>> To: Burleigh, Scott C (313B)
>> Cc: Lloyd Wood; Joseph Ishac; [email-masked];
>> Delay Tolerant Networking Interest List
>> Subject: Re: [dtn-interest] TCPCL issue
>> 
>> On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:
>> 
>>> Let's quantify "overhead nightmare".  Do we call it an overhead nightmare
>> when we send a GB image over the Internet?  In IPv4 packets that are
>> limited to 64KB each?  You've got an "overhead nightmare" if there is so
>> much metadata accompanying your data that your ability to move all
>> significant application data through the network is deeply impaired.  If
>> you've got bandwidth to burn, "overhead" is irrelevant.
>> 
>> No.
> 
> Yes.

No. The scenarios bundling was envisaged for do not have bandwidth to burn. They're often running at capacity transferring large quantities of data over slow and unreliable links.

>> If you're moving a GB image in a large series of sequential 64KB bundles,
>> then the application, rather than the convergence layer, becomes
>> responsible for ordering, sending, resending and reassembly of the bundles
>> to create the delivered image.
> 
> No, if you're using bundle fragmentation then bundle protocol becomes responsible for reassembling the original bundle (containing the entire image) from fragmentary bundles;

But you're in favour of sending bundles not larger than 64K. Any bundle fragments handled by the bundle layer will be even less than 64K.

If the application has to consider how to break a large file into 64K bundles, the bundle layer is offloading functionality to the application.

Fragmenting (better, segmenting, since bundle fragments are not produced) the file into multiple bundles can be avoided. 

> if you're using CFDP, for example, then CFDP becomes responsible for reassembling the original image file from CFDP file data segments in bundles.  

Of course, CFDP works directly with TCP and UDP, and doesn't require bundling. (Does CFDP have a 64K limit?)

> BP is always responsible for sending the bundles.  Resending bundles is a BP responsibility in the event that you're doing custody transfer,

How so? There's no resend mechanism implemented with custody transfer.

> and retransmission at the convergence layer can (and I believe should) minimize custodial retransmission.  "Ordering" bundles isn't necessary.

retransmission at the convergence layer can and should minimize application-level retransmission.

If 64KB bundles are being sent to carry a 1GB file, instead of sending that as a 1GB bundle, ordering in the buffer becomes necessary at the application layer.

> 
>> In other words, the application takes on a number of things that the
>> convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP
>> segmentation and ordered delivery with yet another series of buffers that
>> deal in bundles rather than in segments.
> 
> No, the application may or may not take on one thing that applications sometimes do: reassembly of the application data unit from portions of that application data unit, e.g., by reading from a TCP socket multiple times.

...and re-requesting missing bundles that haven't arrived... there's more than one thing here.

L.

> 
> Scott

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Peter Lovell <[email-masked]>
To: Joerg Ott <[email-masked]>, dtn interest <[email-masked]>
Date: Mon, 16 Nov 2009 15:35:25 -0500
Subject: Re: [dtn-interest] TCPCL issue

On Fri, Nov 13, 2009, Joerg Ott <[email-masked]> wrote:

>You can figure it out by peeking into the bundle header, but this
>does not appear very clean.

Hi J�rg,

I'm puzzled. By "bundle header" I assume you mean the primary block. But
that doesn't contain a field for the payload size.

Perhaps you mean to peek at the block header of the payload, which will
typically be "not too far" from the start of the bundle?

Cheers.....Peter

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 12:15:44 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay, Interest List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Monday, November 16, 2009 11:34 AM
> To: Burleigh, Scott C (313B)
> Cc: Lloyd Wood; Joseph Ishac; [email-masked];
> Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] TCPCL issue
> 
> On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:
> 
> > Let's quantify "overhead nightmare".  Do we call it an overhead nightmare
> when we send a GB image over the Internet?  In IPv4 packets that are
> limited to 64KB each?  You've got an "overhead nightmare" if there is so
> much metadata accompanying your data that your ability to move all
> significant application data through the network is deeply impaired.  If
> you've got bandwidth to burn, "overhead" is irrelevant.
> 
> No.

Yes.

> If you're moving a GB image in a large series of sequential 64KB bundles,
> then the application, rather than the convergence layer, becomes
> responsible for ordering, sending, resending and reassembly of the bundles
> to create the delivered image.

No, if you're using bundle fragmentation then bundle protocol becomes responsible for reassembling the original bundle (containing the entire image) from fragmentary bundles; if you're using CFDP, for example, then CFDP becomes responsible for reassembling the original image file from CFDP file data segments in bundles.  BP is always responsible for sending the bundles.  Resending bundles is a BP responsibility in the event that you're doing custody transfer, and retransmission at the convergence layer can (and I believe should) minimize custodial retransmission.  "Ordering" bundles isn't necessary.

> In other words, the application takes on a number of things that the
> convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP
> segmentation and ordered delivery with yet another series of buffers that
> deal in bundles rather than in segments.

No, the application may or may not take on one thing that applications sometimes do: reassembly of the application data unit from portions of that application data unit, e.g., by reading from a TCP socket multiple times.

Scott

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 12:15:44 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay, Interest List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Monday, November 16, 2009 11:34 AM
> To: Burleigh, Scott C (313B)
> Cc: Lloyd Wood; Joseph Ishac; [email-masked];
> Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] TCPCL issue
> 
> On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:
> 
> > Let's quantify "overhead nightmare".  Do we call it an overhead nightmare
> when we send a GB image over the Internet?  In IPv4 packets that are
> limited to 64KB each?  You've got an "overhead nightmare" if there is so
> much metadata accompanying your data that your ability to move all
> significant application data through the network is deeply impaired.  If
> you've got bandwidth to burn, "overhead" is irrelevant.
> 
> No.

Yes.

> If you're moving a GB image in a large series of sequential 64KB bundles,
> then the application, rather than the convergence layer, becomes
> responsible for ordering, sending, resending and reassembly of the bundles
> to create the delivered image.

No, if you're using bundle fragmentation then bundle protocol becomes responsible for reassembling the original bundle (containing the entire image) from fragmentary bundles; if you're using CFDP, for example, then CFDP becomes responsible for reassembling the original image file from CFDP file data segments in bundles.  BP is always responsible for sending the bundles.  Resending bundles is a BP responsibility in the event that you're doing custody transfer, and retransmission at the convergence layer can (and I believe should) minimize custodial retransmission.  "Ordering" bundles isn't necessary.

> In other words, the application takes on a number of things that the
> convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP
> segmentation and ordered delivery with yet another series of buffers that
> deal in bundles rather than in segments.

No, the application may or may not take on one thing that applications sometimes do: reassembly of the application data unit from portions of that application data unit, e.g., by reading from a TCP socket multiple times.

Scott

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Joerg Ott <[email-masked]>
Date: Mon, 16 Nov 2009 13:53:57 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

>Joerg Ott wrote:
>> Ivancic, William D. (GRC-RHN0) wrote:
>>>> It would be extremely useful for a receiving node to know how
>>>> large the next incoming bundle is going to be in total, since the
>>>> TCPCL reassembly has to be done "below" the bundle layer.
>>>>
>>>> You can figure it out by peeking into the bundle header, but this
>>>> does not appear very clean.
>>>>
>>> I suspect you need this for any convergence layer.  I have thought
>that a nice DOS attack is to simply send extremely large bundles.  You
>cannot even do the security check until you have the entire bundle.  So,
>one can probably bring a system to its knees very easily by sending
>extremely large bundles.
>>
>> So, it would be nice to have an indicator up front.
>> We will think about how to get this into TCLCL.
>>
>> Your other point is also quite interesting: it seems
>> we should really define methods for partial bundle
>> authentication (fragment auth) at some point to counter
>> this kind of an attack.
>
>Which kind of attack? Are we discussing vulnerabilities
>in CLs or in the BP? 

YES. Sort of in between both.  No matter what CL, conceivably one may be able to push a super large bundle out and crash DTN at the convergence layer prior to the Bundle Agent ever seeing the bundle.  Hence, security at the bundle layer will not help.

>If the former, then probably some
>kind of CL-specific mechanism would be the appropriate
>countermeasure, e.g. running over IPsec. 

IPsec only works for IP!  What about CCSDS datalinks or direct datalink like BBN is working.  

>If the latter,
>then we have some ciphersuites defined in the BSP and
>can add more if we see the need later. At this point,
>I'm not sure we know enough to decide.
>

-- Will

Date: Mon, 16 Nov 2009 14:46:30 -0500
From: Joseph Ishac <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Mail-Followup-To: Delay Tolerant Networking Interest List  <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue
Reply-To: Joseph Ishac <[email-masked]>

Well, I think I didn't quite get my full point across - or at least the
problem I was envisioning when I wrote the original note.  I wasn't
really thinking overhead in terms of bits, but more in terms of
management of the fragmented data.

Stepping back, I guess I'm not quite clear how to impose the restriction
of size as a solution.  In other words, how do I stop an attacker from
sending me something larger than 64KB?  Do I as a node just chuck things
that come out to be more than 64KB as I'm receiving them?  Assuming I
don't already know about all of my peers and these restrictions ahead of
time, do I have to convey that info to potential peers?  Do they then
have to fragment the bundle just so they can send it to that host?  How
does an intermediary do that and still retain proper security
information?

I guess I'm just not sure I understand how a size restriction would work
in the wild.

-Joseph

On Mon, Nov 16, 2009 at 11:40:34AM -0600, Burleigh, Scott C (313B) wrote:
> Let's quantify "overhead nightmare".  Do we call it an overhead
> nightmare when we send a GB image over the Internet?  In IPv4 packets
> that are limited to 64KB each?  You've got an "overhead nightmare" if
> there is so much metadata accompanying your data that your ability to
> move all significant application data through the network is deeply
> impaired.  If you've got bandwidth to burn, "overhead" is irrelevant.
> If having a lot of "overhead" is the only way you can get data through
> at all (as in the case of heavily coded deep space links), "overhead"
> is irrelevant.  If adding "overhead" is the most economical way to
> secure data (as in ipsec) or to defend against DOS attack, the fact
> that these extra transmitted bits are "overhead" really doesn't
> matter.
> 
> This is an optimization issue.  Let's approach it as one.
> 
> I don't think anybody is saying that there's any DTN magic wand that
> prevents a direct DOS attack on a perimeter node.  If the attack bytes
> are occupying the link, well, there they are; your link-layer
> interface device is going to receive them and you have to get them out
> of the way somehow before you can receive non-attack traffic.  You can
> do that at the link layer or at the convergence layer or at the bundle
> layer.  I believe the thinking behind the design of the BABs is that
> it's historically been difficult to detect (and thereby immediately
> discard) DOS-attack bytes at the link or convergence layer, so a
> standard mechanism at the bundle layer would be a good idea.  That
> mechanism relies on authentication by hashing the received bundle, so
> -- as Will points out -- an onslaught of very large attack bundles
> would mean that the attacked node has got to fully receive each one in
> order to hash and discard it.  Receiving a large bundle imposes some
> stress on storage at the receiver.  I suspect that the total amount of
> computation you have to do to hash traffic is a function of the number
> of bytes to hash rather than the number of times you have to compute
> hashes -- i.e., not much hash computation difference between 1000
> bundles of 1,000,000,000 bytes each and 1,000,000,000 bundles of 1000
> bytes each -- but maybe I'm wrong there.  Reception of smaller bundles
> definitely imposes less stress on storage, though.  And in any case we
> know that the perimeter node is going to get hammered no matter what
> we do; the BABs are really defending the interior nodes, by ensuring
> that the perimeter node doesn't help propagate the attack.
> 
> Scott
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-
> > [email-masked]] On Behalf Of Joseph Ishac
> > Sent: Monday, November 16, 2009 8:54 AM
> > To: [email-masked]; Delay Tolerant Networking
> > Interest List
> > Subject: Re: [dtn-interest] TCPCL issue
> > 
> > Seems like an overhead nightmare if you have a GB image or other data to
> > send and need to fragment that into 64K chunks.  Especially since each
> > fragment is a bundle.  So it might not be a practical solution for all
> > environments.  I also don't see how smaller bundles alleviates you from
> > DOS attacks as the node simply take more of a hit on processing instead
> > of a direct attack on storage.
> > 
> > -Joseph

From: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 19:33:48 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:

> Let's quantify "overhead nightmare".  Do we call it an overhead nightmare when we send a GB image over the Internet?  In IPv4 packets that are limited to 64KB each?  You've got an "overhead nightmare" if there is so much metadata accompanying your data that your ability to move all significant application data through the network is deeply impaired.  If you've got bandwidth to burn, "overhead" is irrelevant.

No.

If you're moving a GB image in a large series of sequential 64KB bundles, then the application, rather than the convergence layer, becomes responsible for ordering, sending, resending and reassembly of the bundles to create the delivered image.

In other words, the application takes on a number of things that the convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP segmentation and ordered delivery with yet another series of buffers that deal in bundles rather than in segments.

The bundle layer has offloaded responsibility for the details of delivery to the application, which complicates application development, testing, size, etc. This is the direct opposite of the 'offload responsibility onto the convergence layer adapters' argued for below by, er, Scott Burleigh, if I read the quoting right.

If you want to reimplement TCP-like segmentation/resend functionality in the application over bundling over TCP (which would be rather like reimplementing CFDP for its APIs over bundling over LTP over CFDP), well, I suppose that's fine for your needs, systems and customers. It's rather less good for everyone else's. We've moved GB images from space, and that's not how we did it; by treating the large image file as one bundle with metadata, we could offload functionality to the convergence layer.

(If the bundle protocol keeps offloading its functionality, what is the bundle layer _for_?)

>  If having a lot of "overhead" is the only way you can get data through at all (as in the case of heavily coded deep space links), "overhead" is irrelevant.  If adding "overhead" is the most economical way to secure data (as in ipsec) or to defend against DOS attack, the fact that these extra transmitted bits are "overhead" really doesn't matter.
> 
> This is an optimization issue.  Let's approach it as one.

It's an engineering design issue.

> Reception of smaller bundles definitely imposes less stress on storage, though.

Not when the bundles have to be reassembled into a larger file... Is it desirable to have more application-space buffers replicating kernel buffers?

The DoS attack thing's a red herring, if you ask me; there are problems here that are not security problems.

L.

[*] well, except for the do-not-use-this straight-to-UDP convergence layer. Described as 'no problem' below.

> 
> I don't think anybody is saying that there's any DTN magic wand that prevents a direct DOS attack on a perimeter node.  If the attack bytes are occupying the link, well, there they are; your link-layer interface device is going to receive them and you have to get them out of the way somehow before you can receive non-attack traffic.  You can do that at the link layer or at the convergence layer or at the bundle layer.  I believe the thinking behind the design of the BABs is that it's historically been difficult to detect (and thereby immediately discard) DOS-attack bytes at the link or convergence layer, so a standard mechanism at the bundle layer would be a good idea.  That mechanism relies on authentication by hashing the received bundle, so -- as Will points out -- an onslaught of very large attack bundles would mean that the attacked node has got to fully receive each one in order to hash and discard it.  Receiving a large bundle imposes some stress on storage at the rec!
> eiver.  I suspect that the total amount of computation you have to do to hash traffic is a function of the number of bytes to hash rather than the number of times you have to compute hashes -- i.e., not much hash computation difference between 1000 bundles of 1,000,000,000 bytes each and 1,000,000,000 bundles of 1000 bytes each -- but maybe I'm wrong there.  Reception of smaller bundles definitely imposes less stress on storage, though.  And in any case we know that the perimeter node is going to get hammered no matter what we do; the BABs are really defending the interior nodes, by ensuring that the perimeter node doesn't help propagate the attack.
> 
> Scott
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Joseph Ishac
>> Sent: Monday, November 16, 2009 8:54 AM
>> To: [email-masked]; Delay Tolerant Networking
>> Interest List
>> Subject: Re: [dtn-interest] TCPCL issue
>> 
>> Seems like an overhead nightmare if you have a GB image or other data to
>> send and need to fragment that into 64K chunks.  Especially since each
>> fragment is a bundle.  So it might not be a practical solution for all
>> environments.  I also don't see how smaller bundles alleviates you from
>> DOS attacks as the node simply take more of a hit on processing instead
>> of a direct attack on storage.
>> 
>> -Joseph
>> 
>> On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
>>> We actually already have a method for fragment authentication: since a
>> fragment is a bundle, the BAB authenticates it.  And this wouldn't help
>> much anyway, because there's no requirement that fragments be small.
>>> 
>>> My inclination (as usual) is to try to keep the bundle protocol simple by
>> offloading this responsibility onto the convergence-layer adapters.  For
>> some CLs, such as the current UDP CL, there is no problem: it's impossible
>> to send extremely large bundles.  (You could fragment a large bundle and
>> send all fragments in UDP datagrams, but in that case there's no problem:
>> you're doing BAB authentication on small bundles, so there's no
>> extraordinary DOS attack opportunity.)  For CLs that will accommodate
>> larger bundles, you can either set a maximum inbound bundle size as a
>> configuration parameter or do something at the convergence layer to ensure
>> authenticity, or both.
>>> 
>>> I personally favor never sending bundles that are larger than 64K in any
>> case, which makes the whole issue go away.  If you have to fragment in
>> order to make this happen, okay, you fragment.
>>> 
>>> Scott
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: Lloyd Wood <[email-masked]>
Date: Mon, 16 Nov 2009 19:33:48 +0000
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

On 16 Nov 2009, at 17:40, Burleigh, Scott C (313B) wrote:

> Let's quantify "overhead nightmare".  Do we call it an overhead nightmare when we send a GB image over the Internet?  In IPv4 packets that are limited to 64KB each?  You've got an "overhead nightmare" if there is so much metadata accompanying your data that your ability to move all significant application data through the network is deeply impaired.  If you've got bandwidth to burn, "overhead" is irrelevant.

No.

If you're moving a GB image in a large series of sequential 64KB bundles, then the application, rather than the convergence layer, becomes responsible for ordering, sending, resending and reassembly of the bundles to create the delivered image.

In other words, the application takes on a number of things that the convergence layer[*] was expected to do, i.e. reimplementing e.g. the TCP segmentation and ordered delivery with yet another series of buffers that deal in bundles rather than in segments.

The bundle layer has offloaded responsibility for the details of delivery to the application, which complicates application development, testing, size, etc. This is the direct opposite of the 'offload responsibility onto the convergence layer adapters' argued for below by, er, Scott Burleigh, if I read the quoting right.

If you want to reimplement TCP-like segmentation/resend functionality in the application over bundling over TCP (which would be rather like reimplementing CFDP for its APIs over bundling over LTP over CFDP), well, I suppose that's fine for your needs, systems and customers. It's rather less good for everyone else's. We've moved GB images from space, and that's not how we did it; by treating the large image file as one bundle with metadata, we could offload functionality to the convergence layer.

(If the bundle protocol keeps offloading its functionality, what is the bundle layer _for_?)

>  If having a lot of "overhead" is the only way you can get data through at all (as in the case of heavily coded deep space links), "overhead" is irrelevant.  If adding "overhead" is the most economical way to secure data (as in ipsec) or to defend against DOS attack, the fact that these extra transmitted bits are "overhead" really doesn't matter.
> 
> This is an optimization issue.  Let's approach it as one.

It's an engineering design issue.

> Reception of smaller bundles definitely imposes less stress on storage, though.

Not when the bundles have to be reassembled into a larger file... Is it desirable to have more application-space buffers replicating kernel buffers?

The DoS attack thing's a red herring, if you ask me; there are problems here that are not security problems.

L.

[*] well, except for the do-not-use-this straight-to-UDP convergence layer. Described as 'no problem' below.

> 
> I don't think anybody is saying that there's any DTN magic wand that prevents a direct DOS attack on a perimeter node.  If the attack bytes are occupying the link, well, there they are; your link-layer interface device is going to receive them and you have to get them out of the way somehow before you can receive non-attack traffic.  You can do that at the link layer or at the convergence layer or at the bundle layer.  I believe the thinking behind the design of the BABs is that it's historically been difficult to detect (and thereby immediately discard) DOS-attack bytes at the link or convergence layer, so a standard mechanism at the bundle layer would be a good idea.  That mechanism relies on authentication by hashing the received bundle, so -- as Will points out -- an onslaught of very large attack bundles would mean that the attacked node has got to fully receive each one in order to hash and discard it.  Receiving a large bundle imposes some stress on storage at the rec!
> eiver.  I suspect that the total amount of computation you have to do to hash traffic is a function of the number of bytes to hash rather than the number of times you have to compute hashes -- i.e., not much hash computation difference between 1000 bundles of 1,000,000,000 bytes each and 1,000,000,000 bundles of 1000 bytes each -- but maybe I'm wrong there.  Reception of smaller bundles definitely imposes less stress on storage, though.  And in any case we know that the perimeter node is going to get hammered no matter what we do; the BABs are really defending the interior nodes, by ensuring that the perimeter node doesn't help propagate the attack.
> 
> Scott
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Joseph Ishac
>> Sent: Monday, November 16, 2009 8:54 AM
>> To: [email-masked]; Delay Tolerant Networking
>> Interest List
>> Subject: Re: [dtn-interest] TCPCL issue
>> 
>> Seems like an overhead nightmare if you have a GB image or other data to
>> send and need to fragment that into 64K chunks.  Especially since each
>> fragment is a bundle.  So it might not be a practical solution for all
>> environments.  I also don't see how smaller bundles alleviates you from
>> DOS attacks as the node simply take more of a hit on processing instead
>> of a direct attack on storage.
>> 
>> -Joseph
>> 
>> On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
>>> We actually already have a method for fragment authentication: since a
>> fragment is a bundle, the BAB authenticates it.  And this wouldn't help
>> much anyway, because there's no requirement that fragments be small.
>>> 
>>> My inclination (as usual) is to try to keep the bundle protocol simple by
>> offloading this responsibility onto the convergence-layer adapters.  For
>> some CLs, such as the current UDP CL, there is no problem: it's impossible
>> to send extremely large bundles.  (You could fragment a large bundle and
>> send all fragments in UDP datagrams, but in that case there's no problem:
>> you're doing BAB authentication on small bundles, so there's no
>> extraordinary DOS attack opportunity.)  For CLs that will accommodate
>> larger bundles, you can either set a maximum inbound bundle size as a
>> configuration parameter or do something at the convergence layer to ensure
>> authenticity, or both.
>>> 
>>> I personally favor never sending bundles that are larger than 64K in any
>> case, which makes the whole issue go away.  If you have to fragment in
>> order to make this happen, okay, you fragment.
>>> 
>>> Scott
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Joseph Ishac <[email-masked]>, "[email-masked]" <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Date: Mon, 16 Nov 2009 09:40:34 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] TCPCL issue

Let's quantify "overhead nightmare".  Do we call it an overhead nightmare when we send a GB image over the Internet?  In IPv4 packets that are limited to 64KB each?  You've got an "overhead nightmare" if there is so much metadata accompanying your data that your ability to move all significant application data through the network is deeply impaired.  If you've got bandwidth to burn, "overhead" is irrelevant.  If having a lot of "overhead" is the only way you can get data through at all (as in the case of heavily coded deep space links), "overhead" is irrelevant.  If adding "overhead" is the most economical way to secure data (as in ipsec) or to defend against DOS attack, the fact that these extra transmitted bits are "overhead" really doesn't matter.

This is an optimization issue.  Let's approach it as one.

I don't think anybody is saying that there's any DTN magic wand that prevents a direct DOS attack on a perimeter node.  If the attack bytes are occupying the link, well, there they are; your link-layer interface device is going to receive them and you have to get them out of the way somehow before you can receive non-attack traffic.  You can do that at the link layer or at the convergence layer or at the bundle layer.  I believe the thinking behind the design of the BABs is that it's historically been difficult to detect (and thereby immediately discard) DOS-attack bytes at the link or convergence layer, so a standard mechanism at the bundle layer would be a good idea.  That mechanism relies on authentication by hashing the received bundle, so -- as Will points out -- an onslaught of very large attack bundles would mean that the attacked node has got to fully receive each one in order to hash and discard it.  Receiving a large bundle imposes some stress on storage at the receiver.  I suspect that the total amount of computation you have to do to hash traffic is a function of the number of bytes to hash rather than the number of times you have to compute hashes -- i.e., not much hash computation difference between 1000 bundles of 1,000,000,000 bytes each and 1,000,000,000 bundles of 1000 bytes each -- but maybe I'm wrong there.  Reception of smaller bundles definitely imposes less stress on storage, though.  And in any case we know that the perimeter node is going to get hammered no matter what we do; the BABs are really defending the interior nodes, by ensuring that the perimeter node doesn't help propagate the attack.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Joseph Ishac
> Sent: Monday, November 16, 2009 8:54 AM
> To: [email-masked]; Delay Tolerant Networking
> Interest List
> Subject: Re: [dtn-interest] TCPCL issue
> 
> Seems like an overhead nightmare if you have a GB image or other data to
> send and need to fragment that into 64K chunks.  Especially since each
> fragment is a bundle.  So it might not be a practical solution for all
> environments.  I also don't see how smaller bundles alleviates you from
> DOS attacks as the node simply take more of a hit on processing instead
> of a direct attack on storage.
> 
> -Joseph
> 
> On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
> > We actually already have a method for fragment authentication: since a
> fragment is a bundle, the BAB authenticates it.  And this wouldn't help
> much anyway, because there's no requirement that fragments be small.
> >
> > My inclination (as usual) is to try to keep the bundle protocol simple by
> offloading this responsibility onto the convergence-layer adapters.  For
> some CLs, such as the current UDP CL, there is no problem: it's impossible
> to send extremely large bundles.  (You could fragment a large bundle and
> send all fragments in UDP datagrams, but in that case there's no problem:
> you're doing BAB authentication on small bundles, so there's no
> extraordinary DOS attack opportunity.)  For CLs that will accommodate
> larger bundles, you can either set a maximum inbound bundle size as a
> configuration parameter or do something at the convergence layer to ensure
> authenticity, or both.
> >
> > I personally favor never sending bundles that are larger than 64K in any
> case, which makes the whole issue go away.  If you have to fragment in
> order to make this happen, okay, you fragment.
> >
> > Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Joseph Ishac <[email-masked]>, "[email-masked]" <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Date: Mon, 16 Nov 2009 09:40:34 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] TCPCL issue

Let's quantify "overhead nightmare".  Do we call it an overhead nightmare when we send a GB image over the Internet?  In IPv4 packets that are limited to 64KB each?  You've got an "overhead nightmare" if there is so much metadata accompanying your data that your ability to move all significant application data through the network is deeply impaired.  If you've got bandwidth to burn, "overhead" is irrelevant.  If having a lot of "overhead" is the only way you can get data through at all (as in the case of heavily coded deep space links), "overhead" is irrelevant.  If adding "overhead" is the most economical way to secure data (as in ipsec) or to defend against DOS attack, the fact that these extra transmitted bits are "overhead" really doesn't matter.

This is an optimization issue.  Let's approach it as one.

I don't think anybody is saying that there's any DTN magic wand that prevents a direct DOS attack on a perimeter node.  If the attack bytes are occupying the link, well, there they are; your link-layer interface device is going to receive them and you have to get them out of the way somehow before you can receive non-attack traffic.  You can do that at the link layer or at the convergence layer or at the bundle layer.  I believe the thinking behind the design of the BABs is that it's historically been difficult to detect (and thereby immediately discard) DOS-attack bytes at the link or convergence layer, so a standard mechanism at the bundle layer would be a good idea.  That mechanism relies on authentication by hashing the received bundle, so -- as Will points out -- an onslaught of very large attack bundles would mean that the attacked node has got to fully receive each one in order to hash and discard it.  Receiving a large bundle imposes some stress on storage at the receiver.  I suspect that the total amount of computation you have to do to hash traffic is a function of the number of bytes to hash rather than the number of times you have to compute hashes -- i.e., not much hash computation difference between 1000 bundles of 1,000,000,000 bytes each and 1,000,000,000 bundles of 1000 bytes each -- but maybe I'm wrong there.  Reception of smaller bundles definitely imposes less stress on storage, though.  And in any case we know that the perimeter node is going to get hammered no matter what we do; the BABs are really defending the interior nodes, by ensuring that the perimeter node doesn't help propagate the attack.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Joseph Ishac
> Sent: Monday, November 16, 2009 8:54 AM
> To: [email-masked]; Delay Tolerant Networking
> Interest List
> Subject: Re: [dtn-interest] TCPCL issue
> 
> Seems like an overhead nightmare if you have a GB image or other data to
> send and need to fragment that into 64K chunks.  Especially since each
> fragment is a bundle.  So it might not be a practical solution for all
> environments.  I also don't see how smaller bundles alleviates you from
> DOS attacks as the node simply take more of a hit on processing instead
> of a direct attack on storage.
> 
> -Joseph
> 
> On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
> > We actually already have a method for fragment authentication: since a
> fragment is a bundle, the BAB authenticates it.  And this wouldn't help
> much anyway, because there's no requirement that fragments be small.
> >
> > My inclination (as usual) is to try to keep the bundle protocol simple by
> offloading this responsibility onto the convergence-layer adapters.  For
> some CLs, such as the current UDP CL, there is no problem: it's impossible
> to send extremely large bundles.  (You could fragment a large bundle and
> send all fragments in UDP datagrams, but in that case there's no problem:
> you're doing BAB authentication on small bundles, so there's no
> extraordinary DOS attack opportunity.)  For CLs that will accommodate
> larger bundles, you can either set a maximum inbound bundle size as a
> configuration parameter or do something at the convergence layer to ensure
> authenticity, or both.
> >
> > I personally favor never sending bundles that are larger than 64K in any
> case, which makes the whole issue go away.  If you have to fragment in
> order to make this happen, okay, you fragment.
> >
> > Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 16 Nov 2009 11:53:33 -0500
From: Joseph Ishac <[email-masked]>
To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>
Mail-Followup-To: [email-masked],Delay Tolerant  Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue
Reply-To: Joseph Ishac <[email-masked]>

Seems like an overhead nightmare if you have a GB image or other data to
send and need to fragment that into 64K chunks.  Especially since each
fragment is a bundle.  So it might not be a practical solution for all
environments.  I also don't see how smaller bundles alleviates you from
DOS attacks as the node simply take more of a hit on processing instead
of a direct attack on storage.

-Joseph

On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
> We actually already have a method for fragment authentication: since a fragment is a bundle, the BAB authenticates it.  And this wouldn't help much anyway, because there's no requirement that fragments be small.
> 
> My inclination (as usual) is to try to keep the bundle protocol simple by offloading this responsibility onto the convergence-layer adapters.  For some CLs, such as the current UDP CL, there is no problem: it's impossible to send extremely large bundles.  (You could fragment a large bundle and send all fragments in UDP datagrams, but in that case there's no problem: you're doing BAB authentication on small bundles, so there's no extraordinary DOS attack opportunity.)  For CLs that will accommodate larger bundles, you can either set a maximum inbound bundle size as a configuration parameter or do something at the convergence layer to ensure authenticity, or both.
> 
> I personally favor never sending bundles that are larger than 64K in any case, which makes the whole issue go away.  If you have to fragment in order to make this happen, okay, you fragment.
> 
> Scott

Date: Mon, 16 Nov 2009 11:53:33 -0500
From: Joseph Ishac <[email-masked]>
To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>
Mail-Followup-To: [email-masked],Delay Tolerant  Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue
Reply-To: Joseph Ishac <[email-masked]>

Seems like an overhead nightmare if you have a GB image or other data to
send and need to fragment that into 64K chunks.  Especially since each
fragment is a bundle.  So it might not be a practical solution for all
environments.  I also don't see how smaller bundles alleviates you from
DOS attacks as the node simply take more of a hit on processing instead
of a direct attack on storage.

-Joseph

On Mon, Nov 16, 2009 at 10:07:11AM -0600, Burleigh, Scott C (313B) wrote:
> We actually already have a method for fragment authentication: since a fragment is a bundle, the BAB authenticates it.  And this wouldn't help much anyway, because there's no requirement that fragments be small.
> 
> My inclination (as usual) is to try to keep the bundle protocol simple by offloading this responsibility onto the convergence-layer adapters.  For some CLs, such as the current UDP CL, there is no problem: it's impossible to send extremely large bundles.  (You could fragment a large bundle and send all fragments in UDP datagrams, but in that case there's no problem: you're doing BAB authentication on small bundles, so there's no extraordinary DOS attack opportunity.)  For CLs that will accommodate larger bundles, you can either set a maximum inbound bundle size as a configuration parameter or do something at the convergence layer to ensure authenticity, or both.
> 
> I personally favor never sending bundles that are larger than 64K in any case, which makes the whole issue go away.  If you have to fragment in order to make this happen, okay, you fragment.
> 
> Scott

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, Joerg Ott <[email-masked]>
Date: Mon, 16 Nov 2009 08:07:11 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

We actually already have a method for fragment authentication: since a fragment is a bundle, the BAB authenticates it.  And this wouldn't help much anyway, because there's no requirement that fragments be small.

My inclination (as usual) is to try to keep the bundle protocol simple by offloading this responsibility onto the convergence-layer adapters.  For some CLs, such as the current UDP CL, there is no problem: it's impossible to send extremely large bundles.  (You could fragment a large bundle and send all fragments in UDP datagrams, but in that case there's no problem: you're doing BAB authentication on small bundles, so there's no extraordinary DOS attack opportunity.)  For CLs that will accommodate larger bundles, you can either set a maximum inbound bundle size as a configuration parameter or do something at the convergence layer to ensure authenticity, or both.

I personally favor never sending bundles that are larger than 64K in any case, which makes the whole issue go away.  If you have to fragment in order to make this happen, okay, you fragment.

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, November 16, 2009 7:33 AM
> To: Joerg Ott
> Cc: Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] TCPCL issue
> 
> 
> 
> Joerg Ott wrote:
> > Ivancic, William D. (GRC-RHN0) wrote:
> >>> It would be extremely useful for a receiving node to know how
> >>> large the next incoming bundle is going to be in total, since the
> >>> TCPCL reassembly has to be done "below" the bundle layer.
> >>>
> >>> You can figure it out by peeking into the bundle header, but this
> >>> does not appear very clean.
> >>>
> >> I suspect you need this for any convergence layer.  I have thought that
> a nice DOS attack is to simply send extremely large bundles.  You cannot
> even do the security check until you have the entire bundle.  So, one can
> probably bring a system to its knees very easily by sending extremely large
> bundles.
> >
> > So, it would be nice to have an indicator up front.
> > We will think about how to get this into TCLCL.
> >
> > Your other point is also quite interesting: it seems
> > we should really define methods for partial bundle
> > authentication (fragment auth) at some point to counter
> > this kind of an attack.
> 
> Which kind of attack? Are we discussing vulnerabilities
> in CLs or in the BP? If the former, then probably some
> kind of CL-specific mechanism would be the appropriate
> countermeasure, e.g. running over IPsec. If the latter,
> then we have some ciphersuites defined in the BSP and
> can add more if we see the need later. At this point,
> I'm not sure we know enough to decide.
> 
> S.
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 16 Nov 2009 15:33:11 +0000
From: Stephen Farrell <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

Joerg Ott wrote:
> Ivancic, William D. (GRC-RHN0) wrote:
>>> It would be extremely useful for a receiving node to know how
>>> large the next incoming bundle is going to be in total, since the
>>> TCPCL reassembly has to be done "below" the bundle layer.
>>>
>>> You can figure it out by peeking into the bundle header, but this
>>> does not appear very clean.
>>>
>> I suspect you need this for any convergence layer.  I have thought that a nice DOS attack is to simply send extremely large bundles.  You cannot even do the security check until you have the entire bundle.  So, one can probably bring a system to its knees very easily by sending extremely large bundles.
> 
> So, it would be nice to have an indicator up front.
> We will think about how to get this into TCLCL.
> 
> Your other point is also quite interesting: it seems
> we should really define methods for partial bundle
> authentication (fragment auth) at some point to counter
> this kind of an attack.

Which kind of attack? Are we discussing vulnerabilities
in CLs or in the BP? If the former, then probably some
kind of CL-specific mechanism would be the appropriate
countermeasure, e.g. running over IPsec. If the latter,
then we have some ciphersuites defined in the BSP and
can add more if we see the need later. At this point,
I'm not sure we know enough to decide.

S.

Date: Mon, 16 Nov 2009 16:34:22 +0200
From: Joerg Ott <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] TCPCL issue

Ivancic, William D. (GRC-RHN0) wrote:
>> It would be extremely useful for a receiving node to know how
>> large the next incoming bundle is going to be in total, since the
>> TCPCL reassembly has to be done "below" the bundle layer.
>>
>> You can figure it out by peeking into the bundle header, but this
>> does not appear very clean.
>>
> 
> I suspect you need this for any convergence layer.  I have thought that a nice DOS attack is to simply send extremely large bundles.  You cannot even do the security check until you have the entire bundle.  So, one can probably bring a system to its knees very easily by sending extremely large bundles.

So, it would be nice to have an indicator up front.
We will think about how to get this into TCLCL.

Your other point is also quite interesting: it seems
we should really define methods for partial bundle
authentication (fragment auth) at some point to counter
this kind of an attack.

Joerg

Date: Fri, 13 Nov 2009 03:06:57 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Meeting materials for DTNRG session

Apologies for not including Elwyn's slides. They're up there now.

Stephen.

Stephen Farrell wrote:
> Hi all,
> 
> I've uploaded the slides [1] for the session tomorrow. Search
> down the page for DTNRG,
> 
> Regards,
> Stephen.
> 
> [1] https://datatracker.ietf.org/meeting/76/materials.html
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 12 Nov 2009 19:38:09 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] DTNRG meeting question

This is for Elwyn:  Elwyn, while at the microphone, you asked if NICT was using ad hoc mode and indicated there is a problem with ad hoc mode.  Where you referring to ad hoc mode in the 802.11 radios versus client/server or parent/child settings?

I have yet to identify a good radio that is built for ad hoc networking at layer-3.  Does anyone know of such radios.  

--Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic 

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Joerg Ott <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 12 Nov 2009 18:47:42 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] TCPCL issue

>
>It would be extremely useful for a receiving node to know how
>large the next incoming bundle is going to be in total, since the
>TCPCL reassembly has to be done "below" the bundle layer.
>
>You can figure it out by peeking into the bundle header, but this
>does not appear very clean.
>

I suspect you need this for any convergence layer.  I have thought that a nice DOS attack is to simply send extremely large bundles.  You cannot even do the security check until you have the entire bundle.  So, one can probably bring a system to its knees very easily by sending extremely large bundles.

--Will

Date: Fri, 13 Nov 2009 02:18:01 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] TCPCL issue

Hi,

besides the EID question, Teemu came up with one more issue when
implementing it for the iPhone (the issue is non-iPhone-specific).

It would be extremely useful for a receiving node to know how
large the next incoming bundle is going to be in total, since the
TCPCL reassembly has to be done "below" the bundle layer.

You can figure it out by peeking into the bundle header, but this
does not appear very clean.

We suggest that the TCPCL have a field to indicate this length.
(Maybe it also makes sense to discuss this problem during the
  meeting).

Joerg

From: Peter Lovell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, DTN <[email-masked]>
Date: Fri, 13 Nov 2009 07:09:50 +0900
Subject: [dtn-interest] Re(2):  Meeting materials for DTNRG session

On Thu, Nov 12, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>Actually, if I have it correctly, the time difference is 14 hours for
>EST.

Correct. Japan is GMT + 9, and never uses summer time

>I think Hiroshima and Osaka are in the same time zone.

Also correct. Japan has a single time zone.

Cheers.....Peter

From: Peter Lovell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Fri, 13 Nov 2009 07:06:27 +0900
Subject: [dtn-interest] Re(2):  Meeting materials for DTNRG session

On Thu, Nov 12, 2009, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>DTN2 update:
>Is there a Bundle Security Protocol implementation available for DTN2.
>I think something was done way back with BSP.00 or BSP.01, but a lot has
>changed since then.  I ask because I am suppose to start looking at
>interoperability between ION and DTN2, at least for the Bundle
>Authentication Block.

Hi Will,

yes - BSP in part of RI.

I'm presently working to add the key-transport things now in the spec.
At present that's a stub. If you write code to replace that then you're
good to go.

Cheers.....Peter

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: DTN <[email-masked]>
Date: Thu, 12 Nov 2009 10:58:09 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Meeting materials for DTNRG session

>I am not in Hiroshima and probably will not be on the jabber or
>listening to MP3 in real time due to the time difference of roughly 10 -
>12 hours.
>

Actually, if I have it correctly, the time difference is 14 hours for EST.  I think Hiroshima and Osaka are in the same time zone.  Thus, those in the US can actually participate remotely with reasonable hours.   TONIGHT TONIGHT TONIGHT (November 12)!

DTNRG meets Friday, November 13 from 9:00 am to 11:00 am Local time.

That is 7:00 pm to 9:00 pm November 12 (tonight) EST.

Location	Local time	Time zone
Osaka (Japan)	Friday, November 13, 2009 at 09:00:00	UTC+9 hours
Cleveland (U.S.A. - Ohio)	Thursday, November 12, 2009 at 19:00:00	UTC-5 hours EST
Corresponding UTC (GMT)	Friday, November 13, 2009 at 00:00:00

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Date: Thu, 12 Nov 2009 10:06:01 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Meeting materials for DTNRG session

I am not in Hiroshima and probably will not be on the jabber or listening to MP3 in real time due to the time difference of roughly 10 - 12 hours.

I looked at the slides (thanks for getting these out early).  I have a few questions for the presenters.  They may want to address them during their presentations.  Regardless, addressing them here would be useful for those of us not in Hiroshima.

DTN Time Synch: 
Does this method use bundle protocol to sync or some other communications?  
If bundles, what is the lifetime of the bundle set to?  
If I understand correctly, the proposed method achieves "relative time" synchronization.  How does that map to Absolute Time (UTC synchronization)?

PEAR:  
Very interesting analysis.  I liked the use of Entropy to help determine what routing methodology to use.
Was there discovery of nodes or where something the equivalent of a "host table" established in each node prior to deployment?

DTN as enabler:

N4C @ extremecom:
Was there discovery of nodes or where something the equivalent of a "host table" established in each node prior to deployment?
How was network UTC synchronization obtained and maintained?
For applications, what were the bundle lifetimes set to and did they vary depending on the application?
Under "Findings", Note: still some oddities I don't understand: "Clock issues"  Are these system synchronization issues or drift issues?

DTN2 update:
Is there a Bundle Security Protocol implementation available for DTN2.  I think something was done way back with BSP.00 or BSP.01, but a lot has changed since then.  I ask because I am suppose to start looking at interoperability between ION and DTN2, at least for the Bundle Authentication Block.

DTN Usability Project:
I looks like Brenton Walker is asking the right questions regarding discovery, API, absoluter versus relative time.  What is the DTN Usability Project?  Is there a URL or some other documentation?  

--Will

Date: Thu, 12 Nov 2009 14:06:07 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Meeting materials for DTNRG session

Hi all,

I've uploaded the slides [1] for the session tomorrow. Search
down the page for DTNRG,

Regards,
Stephen.

[1] https://datatracker.ietf.org/meeting/76/materials.html

Date: Thu, 12 Nov 2009 08:55:14 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Slides please...

[email-masked] wrote:
> 
>> If you're presenting tomorrow, can you please send me slides
>> for the DTNRG session before 6pm (Japan time) today so I can
>> upload them to the meeting materials site.
> 
> A plea: do remember that printing to pdf (via e.g. CutePDF from
> www.cutepdf.com, or  built into a Mac...) is usually preferable;
> the conversion from ppt to html and on-web archival of the
> resulting files is hit-and-miss.

Which reminds me, I assume that we'll have some remote participants
listening in tomorrow if the time differences aren't too awful. If
you plan to do that, just drop me a note, or join the jabber session
so we know you're there, and if you want a jabber comment read out,
just preface it with "mic:" and we'll get someone to say it.

There is a webex thing being tried out at this meeting, but I don't
plan to ask for that (not even sure its available in our room) because
it's been a bit flakey and disruptive in the meetings I've been in
where it was used.

Thanks,
S.

> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 

Content-class: urn:content-classes:message
Date: Thu, 12 Nov 2009 07:53:46 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Slides please...

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA636D.4343D365
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> If you're presenting tomorrow, can you please send me slides
> for the DTNRG session before 6pm (Japan time) today so I can
> upload them to the meeting materials site.

A plea: do remember that printing to pdf (via e.g. CutePDF from
www.cutepdf.com, or  built into a Mac...) is usually preferable;
the conversion from ppt to html and on-web archival of the
resulting files is hit-and-miss.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

------_=_NextPart_001_01CA636D.4343D365
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Slides please...</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>&gt; If you're presenting tomorrow, can you please =
send me slides<BR>
&gt; for the DTNRG session before 6pm (Japan time) today so I can<BR>
&gt; upload them to the meeting materials site.<BR>
<BR>
A plea: do remember that printing to pdf (via e.g. CutePDF from<BR>
www.cutepdf.com, or&nbsp; built into a Mac...) is usually =
preferable;<BR>
the conversion from ppt to html and on-web archival of the<BR>
resulting files is hit-and-miss.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA636D.4343D365--

From: Peter Lovell <[email-masked]>
To: Kevin Fall <[email-masked]>, [email-masked], Stephen Farrell <[email-masked]>
Date: Thu, 12 Nov 2009 12:55:27 +0900
Subject: [dtn-interest] Fwd: New Version Notification for draft-irtf-dtnrg-bundle-security-10

Hello all,

I have just posted a revised BSP specification that addresses concerns
raised by Kevin and others.

In particular I have revised the section that described "security zones"
as this made them seem like an administrator-controlled network
configuration thing, which they are not. It clarifies this now by
defining the "security region" (I'd like a better term but we don't have
one) for a security block such as PCB as the path followed by a bundle
as it travels from the block's security-source to its security-dest.

This isn't determined by the administrator (if there is one) but by the
security policies at the various nodes that handle the bundle.

I'll be available for discussion on this during our session tomorrow.

Cheers.....Peter

---------------- Begin Forwarded Message ----------------
Subject: New Version Notification for draft-irtf-dtnrg-bundle-security-10
Date Sent: Wednesday, November 11, 2009 7:42 PM
Date Rec.: Thursday, November 12, 2009 12:42 PM
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]
, [email-masked]
, [email-masked]

A new version of I-D, draft-irtf-dtnrg-bundle-security-10.txt has been
successfuly submitted by Peter Lovell and posted to the IETF repository.

Filename:	 draft-irtf-dtnrg-bundle-security
Revision:	 10
Title:		 Bundle Security Protocol Specification
Creation_date:	 2009-11-11
WG ID:		 Independent Submission
Number_of_pages: 59

Abstract:
This document defines the bundle security protocol, which provides
data integrity and confidentiality services for the bundle protocol.
Separate capabilities are provided to protect the bundle payload and
additional data that may be included within the bundle.  We also
describe various bundle security considerations including policy
options.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 15, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

The IETF Secretariat.

----------------- End Forwarded Message -----------------

Date: Thu, 12 Nov 2009 00:14:47 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Slides please...

Hi All,

If you're presenting tomorrow, can you please send me slides
for the DTNRG session before 6pm (Japan time) today so I can
upload them to the meeting materials site.

Thanks,
Stephen.

Date: Wed, 11 Nov 2009 09:15:48 +0000
From: Stephen Farrell <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

Hi All,

So taking into account the comments received and
based on chatting with DTN folks at the IETF meeting,
we hope that we can proceed with all of the documents
if the various changes needed are done in time.

There are of course nits and some less minor issues
with some of them, so we defined the following new
statuses just for this:

- "yes, if" - there are only minor issues and
the authors are in the process of handling those

- "no, until" - there are less trivial issues
where we want to check the next version again
before going ahead

Authors also need to add a bit of boilerplate
to the *abstract* if its not already there. (Yes,
I know putting it there is silly.) The text to
use is below.

"yes, if" draft-irtf-dtnrg-sdnv
"yes, if" draft-irtf-dtnrg-bundle-previous-hop-block
"yes, if" draft-irtf-dtnrg-bundle-metadata-block
"no, until" draft-irtf-dtnrg-bundle-retrans-block
"yes, if" draft-irtf-dtnrg-cbhe
"yes, if" draft-irtf-dtnrg-bundle-security
"no, until" draft-irtf-dtnrg-prophet

Regards,
Stephen.

Boilerplate:

  "This document is a product of the Delay Tolerant Networking Research
   Group and has been reviewed by that group.  No objections to its
   publication as an RFC were raised."

Stephen Farrell wrote:
> Hi All,
> 
> First, thanks for the feedback sent so far, do keep
> it coming.
> 
> Here's how Kevin and I propose to process the feedback
> from this "yet another last call":
> 
> Based on the feedback sent to the list, we'll decide
> (probably on Monday) which are ready to go forward.
> 
> We may decide that draft-foo should go ahead only
> if the authors address comment-bar. But, we won't be
> requiring unanimous "yes" opinions, essentially this
> will be a judgment call, based on the comments to
> the list, and not just a simple accounting exercise.
> 
> So if you've opinions to express, please mail them
> to the list now.
> 
> We will start the IRSG review process for the drafts
> that are ready on November 20. So, authors, please ensure
> that any changes that are needed are done before then.
> You can submit new drafts from Monday.
> 
> If, based on the list feedback, we decide that some of
> these drafts aren't quite ready yet, the authors of
> those still have a chance to take the list feedback into
> account and if they turn enough (decided by the chairs)
> "no" opinions into "yes" opinions by Nov 20 then we'll
> include those drafts in the batch submitted for IRSG
> review.
> 
> Remaining drafts (if any) won't go forward at this time.
> The next time we'll do this will most likely be early
> in the new year, if more documents look like they're
> ready by then.
> 
> And, of course, we'll be in "chair" mode while doing
> this, so our own personal comments only count as much
> those from anyone else that contributes to DTNRG.
> 
> Regards,
> Stephen & Kevin.
> 
> 
> 
> [email-masked] wrote:
>> ...or at least I hope they're done. (And my apologies
>> for being so slow getting this done.)
>>
>> I think we should finally declare victory on these before
>> we meet in Hiroshima and shoot them over to the IRSG for
>> review.
>>
>> But we need some messages to the list saying "yes" for that
>> to happen.
>>
>> Please respond to this mail saying yes/no/dunno for each
>> of these before Friday November 6th.
>>
>> [yes|no|dunno] draft-irtf-dtnrg-sdnv
>> [yes|no|dunno] draft-irtf-dtnrg-bundle-previous-hop-block
>> [yes|no|dunno] draft-irtf-dtnrg-bundle-metadata-block
>> [yes|no|dunno] draft-irtf-dtnrg-bundle-retrans-block
>> [yes|no|dunno] draft-irtf-dtnrg-cbhe
>> [yes|no|dunno] draft-irtf-dtnrg-bundle-security
>> [yes|no|dunno] draft-irtf-dtnrg-prophet
>>
>> - "yes" means "I think this is ready to be an RFC" and
>>   can be accompanied by editorial or minor comments/suggestions
>> - "no" requires substantive accompanying comments, i.e. you
>>   need to say why not, or we'll treat that as "dunno"
>> - dunno means you've not read it or don't care
>>
>> I'm giving them a read over now, and will send my own
>> response when that's done.
>>
>> Thanks,
>> Stephen.
>>
>> PS: I'm going to post a draft agenda for our session (on
>> Friday Nov 13th) in a hour or two, so yet another chance
>> to ask for a slot, if you've not already.
>>
>>
>> _______________________________________________

Date: Tue, 10 Nov 2009 02:58:43 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Errata on RFCs 5050 & 5326

Hi all,

Alfred Hoenes has posted some errata for RFCs 5050 & 5326.

Alfred's usually correct with these things, so I plan to take
a look and then most likely accept them tomorrow. If you care,
take a look and let me know what you think.

To see the errata, click the "errata" link on the top right of
the HTML version of the RFCs on the IETF tools site [1,2]

If I accept them, they just get listed as "accepted," and we
can fix them in future if we rev. the RFCs. We don't need to
do anything else.

Regards,
Stephen.

[1] http://tools.ietf.org/html/rfc5050
[2] http://tools.ietf.org/html/rfc5326

From: Lloyd Wood <[email-masked]>
To: "[email-masked] interest" <[email-masked]>
Date: Mon, 9 Nov 2009 18:24:11 +0000
Cc: "[email-masked] interest" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Hot Dead Birds

Marilyn Monroe!

Date: Mon, 9 Nov 2009 10:59:40 -0500
From: David Young <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Hot Dead Birds

Do we have any resources/details on the android DTN stack?  Did
someone port ION, the RI? I recall Andrew worked on something like
this a while back...

On Fri, Nov 6, 2009 at 10:34 AM, Stephen Farrell
<[email-masked]> wrote:
>
>
> [email-masked] wrote:
>> Actually, the acronym often gets
>> considerable time devoted to it by engineers.
>>
>> Something like
>> the Colonel's Hot Edible Expired Poultry (CHEEP).
>
> Duck That's Nuked?
>
>> I guess that from now on it'll be Hot Dead Birds (HDB) protocol.
>>
>> Vint Cerf mods Android for interplanetary interwebs
>> <http://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/>
>
> Anyone know if there's a build for Android?
>
> S.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
David Young

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]	ilman.dtnrg.org" <[email-masked]>
Date: Fri, 6 Nov 2009 16:47:27 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments	on draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

--_000_FD514C8A5155C64C9B145B48D674EF544A00FD3447ALTPHYEMBEVSP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For what it's worth, I did implement the previous hop block in ION a few mo=
nths ago to support processing of the Bundle Authentication Block.  The pro=
blem, though, is that the PH block necessarily appears *after* the pre-payl=
oad BAB, so it can't announce the EID of the sender at BAB acquisition time=
, when the entire serialized bundle is nicely accessible for easy hash comp=
utation.  So it ends up being more convenient to rely on the CL adapter rep=
orting on the sender EID after all, and that's what we've dropped back to i=
n ION.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Symington, Susan F.
Sent: Friday, November 06, 2009 11:59 AM
To: Kevin Fall; [email-masked] ilman.dtnrg.org
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-ho=
p-block-07.txt

Kevin,

I will respond to your comments inline below.

>-----Original Message-----

>From: [email-masked] [mailto:dtn-

>[email-masked]] On Behalf Of Kevin Fall

>Sent: Wednesday, November 04, 2009 4:35 PM

>To: [email-masked] ilman.dtnrg.org

>Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-

>hop-block-07.txt

>

>

>I vote no on this draft in its current form based on the following

>concerns

>

>1. there is not an andequate description of the intended use of

>    this mechanism.  There is mention of the notion that flood routing

>    might find this mechanism useful, but no details that explain how

>    or why.  Furthermore, there is no reference to any other material

>    that details why identification of the previous hop needs to

>    be carried in a PDU (as opposed to somewhere else-- e.g., in DTN

>    could be via a CL protocol).  Now there may be some

>    reasons [putting bundles on usb drive maybe?], but they aren't

>    in the doc as written.

The previous hop EID block could be helpful when implementing flood routing=
 because the receiving node would know to exclude the previous hop EID from=
 the list of adjacent nodes to which it sends the bundle as it does its par=
t in flooding the bundle to all of its adjacent neighbors. The node will fl=
ood the bundle to all neighboring nodes except for the node from which it r=
eceived the bundle, as identified in the previous hop EID.

Does this explanation suffice or are you looking for something more? If mor=
e, has anyone on the list used the previous hop block for flood routing or =
for some other purpose that I can mention here in this I-D?

As to why it may be useful to have the previous hop block to carry the prev=
ious hop EID rather than rely on being able to figure out the previous hop =
EID from the CL protocol, the point is that it may not always be possible t=
o figure out the previous hop EID from the CL protocol. Would adding these =
examples to the I-D satisfy your concern, Kevin?:

1) (Thanks to Mike Demmer) If there is a NAT in the network, then all the s=
enders inside the NAT will appear to have the same IP address to an outside=
 recipient. Some other information other than just the CL addressing is req=
uired to distinguish them from one another.

2) If tunneling DTN bundles across some portion of the DTN network, it is n=
ot possible for the node at the receiving end of the tunnel to determine fr=
om the convergence layer the EID of the node at the sending end of the tunn=
el. The node at the receiving end of the tunnel will receive an encapsulati=
ng bundle from one of its adjacent nodes and it may be able to tell the EID=
 of this adjacent node using the convergence layer protocol. However, the n=
ode at the sending end of the tunnel is most likely not adjacent to the nod=
e at the receiving end of the tunnel, and so in order for the node at the r=
eceiving end of the tunnel to be able to learn the EID of the node at the s=
ending end of the tunnel, which is the previous hop node of the tunneled bu=
ndle, the EID must be provided within the tunneled bundle. The PHIB would b=
e the vehicle for enabling the node at the sending end of the tunnel to pro=
vide its EID to the node at the receiving end of the tunnel.

>

>2. there is no description of which EID should be used if the

>    inserting node is a member of multiple EIDs, and I think this

>    could be a significant problem when used in the type of

>    routing context suggested (but see #1).  One might imagine

>    a set of preferences such as -- if incoming bundle already has

>    a PHIB and the forwarding node is member of an EID with the same

>    scheme, that is preferred..  Or, if that doesn't work, maybe

>    prefer an EID that has a scheme matching either the src or dest

>    (or another) primary block EID scheme part.  Or, failing that,

>    the local policy should be able to specify the order of preference

>    for this capability.

>

As Stephen points out, living with and documenting the ambiguity may be the=
 best we can do.

I can see a couple of different ways of looking at this that we should cons=
ider as we determine how best to word the draft with respect to this issue:

0. Document the ambiguity and live with it.

1. Perhaps the previous hop block is not the right place to specify which E=
ID should be included in the PHIB.  The purpose of the PHIB I-D is to defin=
e the block in which an EID of the previous hop should be carried, but not =
necessarily to specify which EID must or should be chosen for inclusion. If=
 a node is configured to include a PHIB in bundles that it forwards (perhap=
s because the bundles have destination URIs of a certain type, because the =
bundle is participating in a routing algorithm that uses the PHIB informati=
on, or for whatever reason, then the node should also be configured to incl=
ude the appropriate EID. In other words, whatever is causing that node to i=
nclude a PHIB in bundles that it forwards better also be causing it to incl=
ude the correct EID.  If you accept this way of thinking then a way of addr=
essing the issue is to say nothing about which of its EIDs the node should =
put in the PHIB because that is not the purview of the PHIB I-D.

2. The BP says that every bundle node must be a member of at least one sing=
leton endpoint. If a bundle node is a member of exactly one singleton endpo=
int, the EID of this endpoint is what must be inserted into the PHIB. If a =
bundle node is a member of more than one singleton endpoint, the EID of the=
 singleton endpoint that is expressed in the same URI scheme as the destina=
tion of the bundle being forwarded is what must be inserted into the PHIB. =
If a bundle is a member of more than one singleton endpoint in the URI sche=
me used by the destination of the bundle that is being forwarded, the node =
must insert one of these singleton EIDs into the PHIB and it may insert add=
itional PHIBs into the bundle, each of which may contain a unique one of th=
e node's additional singleton EIDs as expressed in this scheme.

3. A long time ago we had the notion of each node having and "administrativ=
e endpoint".  The EID for this is what we probably would want to have inser=
ted into the PHIB.  Unfortunately, unless I am mistaken, there is no such c=
oncept in the BP anymore.

Which, if any, of the above ways of dealing with this issue best addresses =
your concerns so that we can remove your objection?

>Other more detailed comments-

I don't have any problem with your suggested revisions.

>

>(references should be fixed to be using the format as other RFCs)

>(normalize upper and lower case usage of Previous Hop Insertion Block)

>(maybe define 'PHIB'; I will assume so in my further comments)

>

>Is the insertion of a PHIB controlled via the API, or as a bundle

>agent configuration option?

PHIB insertion is controlled via a bundle agent configuration option.

-susan

>

>Abstract

>

>s/The PHIB/Each PHIB/

>s/duration with the bundle/presence within a bundle/

>s/lasts for exactly one hop/is limited to exactly one hop/

>

>(no justification this mechanism is "required" for flood routing which

>is given as an example)

>

>Section 1

>

>s/Previous Hop Block/PHIB/

>

>Section 2

>

>(SDNV encoding might want to reference new RFC/draft describing SDNVs)

>

>Section 3

>if its received at the final destination, is it made

>"available" to receiving applications as well?  Is this a requirement?

>

>Section 4

>s/duration/extent/

>

>Section 5

>(re)mention that the value 0x05 is being suggested for this block

>

>_______________________________________________

>dtn-interest mailing list

>[email-masked]

>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_FD514C8A5155C64C9B145B48D674EF544A00FD3447ALTPHYEMBEVSP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 58.6pt 1.0in 58.55pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>For what it&#8217;s wort=
h, I did
implement the previous hop block in ION a few months ago to support process=
ing
of the Bundle Authentication Block.&nbsp; The problem, though, is that the =
PH
block necessarily appears *<b>after</b>* the pre-payload BAB, so it can&#82=
17;t
announce the EID of the sender at BAB acquisition time, when the entire
serialized bundle is nicely accessible for easy hash computation.&nbsp; So =
it
ends up being more convenient to rely on the CL adapter reporting on the se=
nder
EID after all, and that&#8217;s what we&#8217;ve dropped back to in ION.<o:=
p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Scott<o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Symington,
Susan F.<br>
<b>Sent:</b> Friday, November 06, 2009 11:59 AM<br>
<b>To:</b> Kevin Fall; [email-masked] ilman.dtnrg.org<br>
<b>Subject:</b> Re: [dtn-interest] comments on
draft-irtf-dtnrg-bundle-previous-hop-block-07.txt<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Kevin,<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>I will respond to your comments inline below.<o:p><=
/o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;-----Original Message-----<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;From:
[email-masked] [mailto:dtn-<o:p></o:p></=
p>

<p class=3DMsoPlainText>&gt;[email-masked]] =
On
Behalf Of Kevin Fall<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;Sent: Wednesday, November 04, 2009 4:35 PM<o:p>=
</o:p></p>

<p class=3DMsoPlainText>&gt;To: [email-masked] ilman.dtnrg.=
org<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;Subject: [dtn-interest] comments on
draft-irtf-dtnrg-bundle-previous-<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;hop-block-07.txt<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;I vote no on this draft in its current form bas=
ed on
the following<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;concerns<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;1. there is not an andequate description of the
intended use of<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; this mechanism.&nbsp; There =
is
mention of the notion that flood routing<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; might find this mechanism us=
eful,
but no details that explain how<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; or why.&nbsp; Furthermore, t=
here
is no reference to any other material<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; that details why identificat=
ion of
the previous hop needs to<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; be carried in a PDU (as oppo=
sed to
somewhere else-- e.g., in DTN<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; could be via a CL protocol).=
&nbsp;
Now there may be some<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; reasons [putting bundles on =
usb
drive maybe?], but they aren't<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; in the doc as written.<o:p><=
/o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>The previous hop EID bl=
ock
could be helpful when implementing flood routing because the receiving node
would know to exclude the previous hop EID from the list of adjacent nodes =
to
which it sends the bundle as it does its part in flooding the bundle to all=
 of its
adjacent neighbors. The node will flood the bundle to all neighboring nodes
except for the node from which it received the bundle, as identified in the
previous hop EID.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>Does this explanation s=
uffice
or are you looking for something more? If more, has anyone on the list used=
 the
previous hop block for flood routing or for some other purpose that I can
mention here in this I-D?<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>As to why it may be use=
ful to
have the previous hop block to carry the previous hop EID rather than rely =
on
being able to figure out the previous hop EID from the CL protocol, the poi=
nt
is that it may not always be possible to figure out the previous hop EID fr=
om
the CL protocol. Would adding these examples to the I-D satisfy your concer=
n,
Kevin?: <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>1) (Thanks to Mike Demm=
er) If
there is a NAT in the network, then all the senders inside the NAT will app=
ear
to have the same IP address to an outside recipient. Some other information
other than just the CL addressing is required to distinguish them from one
another. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>2) If tunneling DTN bun=
dles
across some portion of the DTN network, it is not possible for the node at =
the
receiving end of the tunnel to determine from the convergence layer the EID=
 of
the node at the sending end of the tunnel. The node at the receiving end of=
 the
tunnel will receive an encapsulating bundle from one of its adjacent nodes =
and
it may be able to tell the EID of this adjacent node using the convergence
layer protocol. However, the node at the sending end of the tunnel is most
likely not adjacent to the node at the receiving end of the tunnel, and so =
in
order for the node at the receiving end of the tunnel to be able to learn t=
he
EID of the node at the sending end of the tunnel, which is the previous hop
node of the tunneled bundle, the EID must be provided within the tunneled
bundle. The PHIB would be the vehicle for enabling the node at the sending =
end
of the tunnel to provide its EID to the node at the receiving end of the
tunnel.<o:p></o:p></span></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;2. there is no description of which EID should =
be
used if the<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; inserting node is a member o=
f
multiple EIDs, and I think this<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; could be a significant probl=
em
when used in the type of<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; routing context suggested (b=
ut see
#1).&nbsp; One might imagine<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; a set of preferences such as=
 -- if
incoming bundle already has<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; a PHIB and the forwarding no=
de is
member of an EID with the same<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; scheme, that is preferred..&=
nbsp;
Or, if that doesn't work, maybe<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; prefer an EID that has a sch=
eme
matching either the src or dest<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; (or another) primary block E=
ID
scheme part.&nbsp; Or, failing that,<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; the local policy should be a=
ble to
specify the order of preference<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; for this capability.<o:p></o=
:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>As Stephen points out, =
living
with and documenting the ambiguity may be the best we can do.<o:p></o:p></s=
pan></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I can see a couple of d=
ifferent
ways of looking at this that we should consider as we determine how best to
word the draft with respect to this issue:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>0. Document the ambigui=
ty and
live with it.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>1. Perhaps the previous=
 hop
block is not the right place to specify which EID should be included in the
PHIB.&nbsp; The purpose of the PHIB I-D is to define the block in which an =
EID
of the previous hop should be carried, but not necessarily to specify which=
 EID
must or should be chosen for inclusion. If a node is configured to include =
a
PHIB in bundles that it forwards (perhaps because the bundles have destinat=
ion
URIs of a certain type, because the bundle is participating in a routing
algorithm that uses the PHIB information, or for whatever reason, then the =
node
should also be configured to include the appropriate EID. In other words,
whatever is causing that node to include a PHIB in bundles that it forwards
better also be causing it to include the correct EID.&nbsp; If you accept t=
his
way of thinking then a way of addressing the issue is to say nothing about
which of its EIDs the node should put in the PHIB because that is not the
purview of the PHIB I-D.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>2. The BP says that eve=
ry
bundle node must be a member of at least one singleton endpoint. If a bundl=
e
node is a member of exactly one singleton endpoint, the EID of this endpoin=
t is
what must be inserted into the PHIB. If a bundle node is a member of more t=
han
one singleton endpoint, the EID of the singleton endpoint that is expressed=
 in
the same URI scheme as the destination of the bundle being forwarded is wha=
t
must be inserted into the PHIB. If a bundle is a member of more than one
singleton endpoint in the URI scheme used by the destination of the bundle =
that
is being forwarded, the node must insert one of these singleton EIDs into t=
he
PHIB and it may insert additional PHIBs into the bundle, each of which may
contain a unique one of the node's additional singleton EIDs as expressed i=
n
this scheme.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>3. A long time ago we h=
ad the
notion of each node having and &quot;administrative endpoint&quot;.&nbsp; T=
he
EID for this is what we probably would want to have inserted into the
PHIB.&nbsp; Unfortunately, unless I am mistaken, there is no such concept i=
n
the BP anymore. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>Which, if any, of the a=
bove
ways of dealing with this issue best addresses your concerns so that we can=
 remove
your objection? <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;Other more detailed comments-<o:p></o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I don't have any proble=
m with
your suggested revisions. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(references should be fixed to be using the for=
mat as
other RFCs)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(normalize upper and lower case usage of Previo=
us Hop
Insertion Block)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(maybe define 'PHIB'; I will assume so in my fu=
rther
comments)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Is the insertion of a PHIB controlled via the A=
PI, or
as a bundle<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;agent configuration option?<o:p></o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'>PHIB insertion is controlled via a bundle agent configuration
option.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'>-susan<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Abstract<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;s/The PHIB/Each PHIB/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/duration with the bundle/presence within a bu=
ndle/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/lasts for exactly one hop/is limited to exact=
ly one
hop/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(no justification this mechanism is
&quot;required&quot; for flood routing which<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;is given as an example)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 1<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;s/Previous Hop Block/PHIB/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 2<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(SDNV encoding might want to reference new RFC/=
draft
describing SDNVs)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 3<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;if its received at the final destination, is it=
 made<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&quot;available&quot; to receiving applications=
 as
well?&nbsp; Is this a requirement?<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 4<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/duration/extent/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 5<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(re)mention that the value 0x05 is being sugges=
ted
for this block<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;_______________________________________________=
<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;dtn-interest mailing list<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;[email-masked]<o:p><=
/o:p></p>

<p class=3DMsoPlainText>&gt;http://maillists.intel-research.net/mailman/lis=
tinfo/dtn-interest<o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF544A00FD3447ALTPHYEMBEVSP_--

From: "Symington, Susan F." <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Fri, 6 Nov 2009 16:40:50 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC035258200EIMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Okay then I'll make the changes as discussed below and will submit this PHI=
B I-D and the Metadata Block I-D into the system when it opens back up.

-susan

From: Kevin Fall [mailto:[email-masked]]
Sent: Friday, November 06, 2009 3:32 PM
To: Symington, Susan F.
Cc: [email-masked] ilman.dtnrg.org
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-ho=
p-block-07.txt

inline..

On Nov 6, 2009, at Nov 611:59 AMPST, Symington, Susan F. wrote:

Kevin,

I will respond to your comments inline below.

>-----Original Message-----
>From: [email-masked]<mailto:dtn-interes=
[email-masked]> [mailto:dtn-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Wednesday, November 04, 2009 4:35 PM
>To: [email-masked]<mailto:[email-masked]> =
ilman.dtnrg.org<http://ilman.dtnrg.org>
>Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-
>hop-block-07.txt
>
>
>I vote no on this draft in its current form based on the following
>concerns
>
>1. there is not an andequate description of the intended use of
>    this mechanism.  There is mention of the notion that flood routing
>    might find this mechanism useful, but no details that explain how
>    or why.  Furthermore, there is no reference to any other material
>    that details why identification of the previous hop needs to
>    be carried in a PDU (as opposed to somewhere else-- e.g., in DTN
>    could be via a CL protocol).  Now there may be some
>    reasons [putting bundles on usb drive maybe?], but they aren't
>    in the doc as written.

The previous hop EID block could be helpful when implementing flood routing=
 because the receiving node would know to exclude the previous hop EID from=
 the list of adjacent nodes to which it sends the bundle as it does its par=
t in flooding the bundle to all of its adjacent neighbors. The node will fl=
ood the bundle to all neighboring nodes except for the node from which it r=
eceived the bundle, as identified in the previous hop EID.

Does this explanation suffice or are you looking for something more? If mor=
e, has anyone on the list used the previous hop block for flood routing or =
for some other purpose that I can mention here in this I-D?

Well.. hmm.  I do not believe this is the best way to go, but yes it is con=
ceivable to me that somebody might take this approach, and yes I think it w=
ould work for that.  RPF checks (like in IP multicast and even in basic epi=
demic routing) does not in general require the PDU to be modified to includ=
e this info.

As to why it may be useful to have the previous hop block to carry the prev=
ious hop EID rather than rely on being able to figure out the previous hop =
EID from the CL protocol, the point is that it may not always be possible t=
o figure out the previous hop EID from the CL protocol. Would adding these =
examples to the I-D satisfy your concern, Kevin?:

1) (Thanks to Mike Demmer) If there is a NAT in the network, then all the s=
enders inside the NAT will appear to have the same IP address to an outside=
 recipient. Some other information other than just the CL addressing is req=
uired to distinguish them from one another.

Well, yes and no.  The IP address would appear to be the same but port numb=
ers won't be.  Further, and related to above, it would seem logical to me t=
hat any CL protocol (or at least neighbor discovery protocol used prior to =
CL establishment) includes exchanges of EIDs.   So, I don't really buy this=
 argument.  [would be nice if we had some ND protocol agreed upon]

2) If tunneling DTN bundles across some portion of the DTN network, it is n=
ot possible for the node at the receiving end of the tunnel to determine fr=
om the convergence layer the EID of the node at the sending end of the tunn=
el. The node at the receiving end of the tunnel will receive an encapsulati=
ng bundle from one of its adjacent nodes and it may be able to tell the EID=
 of this adjacent node using the convergence layer protocol. However, the n=
ode at the sending end of the tunnel is most likely not adjacent to the nod=
e at the receiving end of the tunnel, and so in order for the node at the r=
eceiving end of the tunnel to be able to learn the EID of the node at the s=
ending end of the tunnel, which is the previous hop node of the tunneled bu=
ndle, the EID must be provided within the tunneled bundle. The PHIB would b=
e the vehicle for enabling the node at the sending end of the tunnel to pro=
vide its EID to the node at the receiving end of the tunnel.

And this would be used for what?  For flood routing through tunnels?  I don=
't feel this has been shown as necessary.   It would seem likely to me that=
 if you are a tunnel endpoint, you have already had some state regarding th=
e other end of the tunnel.  [I'm also not an inherent fan of tunneling for =
DTN, but that's probably a separate discussion].

>
>2. there is no description of which EID should be used if the
>    inserting node is a member of multiple EIDs, and I think this
>    could be a significant problem when used in the type of
>    routing context suggested (but see #1).  One might imagine
>    a set of preferences such as -- if incoming bundle already has
>    a PHIB and the forwarding node is member of an EID with the same
>    scheme, that is preferred..  Or, if that doesn't work, maybe
>    prefer an EID that has a scheme matching either the src or dest
>    (or another) primary block EID scheme part.  Or, failing that,
>    the local policy should be able to specify the order of preference
>    for this capability.
>

As Stephen points out, living with and documenting the ambiguity may be the=
 best we can do.

I don't think so.  I think your suggestions below would argue that we can d=
o something.

I can see a couple of different ways of looking at this that we should cons=
ider as we determine how best to word the draft with respect to this issue:

0. Document the ambiguity and live with it.

1. Perhaps the previous hop block is not the right place to specify which E=
ID should be included in the PHIB.  The purpose of the PHIB I-D is to defin=
e the block in which an EID of the previous hop should be carried, but not =
necessarily to specify which EID must or should be chosen for inclusion. If=
 a node is configured to include a PHIB in bundles that it forwards (perhap=
s because the bundles have destination URIs of a certain type, because the =
bundle is participating in a routing algorithm that uses the PHIB informati=
on, or for whatever reason, then the node should also be configured to incl=
ude the appropriate EID. In other words, whatever is causing that node to i=
nclude a PHIB in bundles that it forwards better also be causing it to incl=
ude the correct EID.  If you accept this way of thinking then a way of addr=
essing the issue is to say nothing about which of its EIDs the node should =
put in the PHIB because that is not the purview of the PHIB I-D.

Well, this might be ok, but instead of not saying anything, I'd refer the s=
election to some other document that discusses what to do when an BP agent =
has to insert its own identity but is a member of multiple endpoints.  I ag=
ree this issue comes up in various circumstances, but I do not know if the =
rules should be different in the different cases.

2. The BP says that every bundle node must be a member of at least one sing=
leton endpoint. If a bundle node is a member of exactly one singleton endpo=
int, the EID of this endpoint is what must be inserted into the PHIB. If a =
bundle node is a member of more than one singleton endpoint, the EID of the=
 singleton endpoint that is expressed in the same URI scheme as the destina=
tion of the bundle being forwarded is what must be inserted into the PHIB. =
If a bundle is a member of more than one singleton endpoint in the URI sche=
me used by the destination of the bundle that is being forwarded, the node =
must insert one of these singleton EIDs into the PHIB and it may insert add=
itional PHIBs into the bundle, each of which may contain a unique one of th=
e node's additional singleton EIDs as expressed in this scheme.

This is really more along the lines of what I was looking for.  The issues =
was that it wasn't clear to me the exact best policy, because I couldn't co=
nvince myself the facility was really that useful in the first place (due t=
o above reasons).

All that said, with the variant of #1 or the inclusion of #2 for the second=
 issue, plus something along the lines of what you said above for the first=
 issue, I'd switch from 'no' to 'no objection.'

thx,
- Kevin

3. A long time ago we had the notion of each node having and "administrativ=
e endpoint".  The EID for this is what we probably would want to have inser=
ted into the PHIB.  Unfortunately, unless I am mistaken, there is no such c=
oncept in the BP anymore.

Which, if any, of the above ways of dealing with this issue best addresses =
your concerns so that we can remove your objection?

>Other more detailed comments-

I don't have any problem with your suggested revisions.

>
>(references should be fixed to be using the format as other RFCs)
>(normalize upper and lower case usage of Previous Hop Insertion Block)
>(maybe define 'PHIB'; I will assume so in my further comments)
>
>Is the insertion of a PHIB controlled via the API, or as a bundle
>agent configuration option?

PHIB insertion is controlled via a bundle agent configuration option.

-susan

>
>Abstract
>
>s/The PHIB/Each PHIB/
>s/duration with the bundle/presence within a bundle/
>s/lasts for exactly one hop/is limited to exactly one hop/
>
>(no justification this mechanism is "required" for flood routing which
>is given as an example)
>
>Section 1
>
>s/Previous Hop Block/PHIB/
>
>Section 2
>
>(SDNV encoding might want to reference new RFC/draft describing SDNVs)
>
>Section 3
>if its received at the final destination, is it made
>"available" to receiving applications as well?  Is this a requirement?
>
>Section 4
>s/duration/extent/
>
>Section 5
>(re)mention that the value 0x05 is being suggested for this block
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC035258200EIMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<base href=3D"x-msg://86/">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Okay then I&#8217;ll make the changes as discussed below and
will submit this PHIB I-D and the Metadata Block I-D into the system when i=
t
opens back up.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>-susan<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:14.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Kevin Fall
[mailto:[email-masked]] <br>
<b>Sent:</b> Friday, November 06, 2009 3:32 PM<br>
<b>To:</b> Symington, Susan F.<br>
<b>Cc:</b> [email-masked] ilman.dtnrg.org<br>
<b>Subject:</b> Re: [dtn-interest] comments on
draft-irtf-dtnrg-bundle-previous-hop-block-07.txt<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>inline..<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=3DMsoNormal>On Nov 6, 2009, at Nov 611:59 AMPST, Symington, Susan =
F.
wrote:<o:p></o:p></p>

</div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>Kevin,<o:p></o:p>=
</span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&nbsp;<o:p></o:p>=
</span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>I will respond to=
 your
comments inline below.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&nbsp;<o:p></o:p>=
</span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;-----Original
Message-----<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;From:<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">dtn-inter=
[email-masked]</a><span
class=3Dapple-converted-space>&nbsp;</span>[mailto:dtn-<o:p></o:p></span></=
p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;interest-boun=
[email-masked]]
On Behalf Of Kevin Fall<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Sent: Wednesd=
ay,
November 04, 2009 4:35 PM<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;To:<span
class=3Dapple-converted-space>&nbsp;</span><a
href=3D"mailto:[email-masked]">[email-masked]=
rg</a><span
class=3Dapple-converted-space>&nbsp;</span><a href=3D"http://ilman.dtnrg.or=
g">ilman.dtnrg.org</a><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Subject:
[dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-<o:p></o:p></sp=
an></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;hop-block-07.=
txt<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;I vote no on =
this
draft in its current form based on the following<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;concerns<o:p>=
</o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;1. there is n=
ot an
andequate description of the intended use of<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
this mechanism.&nbsp; There is mention of the notion that flood routing<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
might find this mechanism useful, but no details that explain how<o:p></o:p=
></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp; or
why.&nbsp; Furthermore, there is no reference to any other material<o:p></o=
:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
that details why identification of the previous hop needs to<o:p></o:p></sp=
an></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp; be
carried in a PDU (as opposed to somewhere else-- e.g., in DTN<o:p></o:p></s=
pan></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
could be via a CL protocol).&nbsp; Now there may be some<o:p></o:p></span><=
/p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
reasons [putting bundles on usb drive maybe?], but they aren't<o:p></o:p></=
span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp; in
the doc as written.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>The p=
revious
hop EID block could be helpful when implementing flood routing because the
receiving node would know to exclude the previous hop EID from the list of
adjacent nodes to which it sends the bundle as it does its part in flooding=
 the
bundle to all of its adjacent neighbors. The node will flood the bundle to =
all
neighboring nodes except for the node from which it received the bundle, as
identified in the previous hop EID.</span><span style=3D'font-family:Consol=
as'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>Does =
this
explanation suffice or are you looking for something more? If more, has any=
one
on the list used the previous hop block for flood routing or for some other
purpose that I can mention here in this I-D?</span><span style=3D'font-fami=
ly:
Consolas'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>Well.. hmm. &nbsp;I do not believe this is the best wa=
y to
go, but yes it is conceivable to me that somebody might take this approach,=
 and
yes I think it would work for that. &nbsp;RPF checks (like in IP multicast =
and
even in basic epidemic routing) does not in general require the PDU to be
modified to include this info.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>As to=
 why it
may be useful to have the previous hop block to carry the previous hop EID
rather than rely on being able to figure out the previous hop EID from the =
CL
protocol, the point is that it may not always be possible to figure out the
previous hop EID from the CL protocol. Would adding these examples to the I=
-D
satisfy your concern, Kevin?:</span><span style=3D'font-family:Consolas'><o=
:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>1) (T=
hanks to
Mike Demmer) If there is a NAT in the network, then all the senders inside =
the
NAT will appear to have the same IP address to an outside recipient. Some o=
ther
information other than just the CL addressing is required to distinguish th=
em
from one another.</span><span style=3D'font-family:Consolas'><o:p></o:p></s=
pan></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>Well, yes and no. &nbsp;The IP address would appear to=
 be
the same but port numbers won't be. &nbsp;Further, and related to above, it
would seem logical to me that any CL protocol (or at least neighbor discove=
ry
protocol used prior to CL establishment) includes exchanges of EIDs. &nbsp;=
 So,
I don't really buy this argument. &nbsp;[would be nice if we had some ND
protocol agreed upon]<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>2) If
tunneling DTN bundles across some portion of the DTN network, it is not
possible for the node at the receiving end of the tunnel to determine from =
the
convergence layer the EID of the node at the sending end of the tunnel. The
node at the receiving end of the tunnel will receive an encapsulating bundl=
e
from one of its adjacent nodes and it may be able to tell the EID of this
adjacent node using the convergence layer protocol. However, the node at th=
e
sending end of the tunnel is most likely not adjacent to the node at the
receiving end of the tunnel, and so in order for the node at the receiving =
end
of the tunnel to be able to learn the EID of the node at the sending end of=
 the
tunnel, which is the previous hop node of the tunneled bundle, the EID must=
 be
provided within the tunneled bundle. The PHIB would be the vehicle for enab=
ling
the node at the sending end of the tunnel to provide its EID to the node at=
 the
receiving end of the tunnel.</span><span style=3D'font-family:Consolas'><o:=
p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>And this would be used for what? &nbsp;For flood routi=
ng
through tunnels? &nbsp;I don't feel this has been shown as necessary. &nbsp=
; It
would seem likely to me that if you are a tunnel endpoint, you have already=
 had
some state regarding the other end of the tunnel. &nbsp;[I'm also not an
inherent fan of tunneling for DTN, but that's probably a separate discussio=
n].<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;2. there is n=
o
description of which EID should be used if the<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
inserting node is a member of multiple EIDs, and I think this<o:p></o:p></s=
pan></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
could be a significant problem when used in the type of<o:p></o:p></span></=
p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
routing context suggested (but see #1).&nbsp; One might imagine<o:p></o:p><=
/span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp; a
set of preferences such as -- if incoming bundle already has<o:p></o:p></sp=
an></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp; a
PHIB and the forwarding node is member of an EID with the same<o:p></o:p></=
span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
scheme, that is preferred..&nbsp; Or, if that doesn't work, maybe<o:p></o:p=
></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
prefer an EID that has a scheme matching either the src or dest<o:p></o:p><=
/span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
(or another) primary block EID scheme part.&nbsp; Or, failing that,<o:p></o=
:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
the local policy should be able to specify the order of preference<o:p></o:=
p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;&nbsp;&=
nbsp;
for this capability.<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>As St=
ephen
points out, living with and documenting the ambiguity may be the best we ca=
n
do.</span><span style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>I don't think so. &nbsp;I think your suggestions below=
 would
argue that we can do something.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>I can=
 see a
couple of different ways of looking at this that we should consider as we
determine how best to word the draft with respect to this issue:</span><spa=
n
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>0. Do=
cument
the ambiguity and live with it.</span><span style=3D'font-family:Consolas'>=
<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>1. Pe=
rhaps
the previous hop block is not the right place to specify which EID should b=
e
included in the PHIB.&nbsp; The purpose of the PHIB I-D is to define the bl=
ock
in which an EID of the previous hop should be carried, but not necessarily =
to
specify which EID must or should be chosen for inclusion. If a node is
configured to include a PHIB in bundles that it forwards (perhaps because t=
he
bundles have destination URIs of a certain type, because the bundle is
participating in a routing algorithm that uses the PHIB information, or for
whatever reason, then the node should also be configured to include the
appropriate EID. In other words, whatever is causing that node to include a
PHIB in bundles that it forwards better also be causing it to include the
correct EID.&nbsp; If you accept this way of thinking then a way of address=
ing
the issue is to say nothing about which of its EIDs the node should put in =
the
PHIB because that is not the purview of the PHIB I-D.</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>Well, this might be ok, but instead of not saying anyt=
hing,
I'd refer the selection to some other document that discusses what to do wh=
en
an BP agent has to insert its own identity but is a member of multiple
endpoints. &nbsp;I agree this issue comes up in various circumstances, but =
I do
not know if the rules should be different in the different cases.<o:p></o:p=
></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>2. Th=
e BP
says that every bundle node must be a member of at least one singleton
endpoint. If a bundle node is a member of exactly one singleton endpoint, t=
he
EID of this endpoint is what must be inserted into the PHIB. If a bundle no=
de
is a member of more than one singleton endpoint, the EID of the singleton
endpoint that is expressed in the same URI scheme as the destination of the
bundle being forwarded is what must be inserted into the PHIB. If a bundle =
is a
member of more than one singleton endpoint in the URI scheme used by the
destination of the bundle that is being forwarded, the node must insert one=
 of
these singleton EIDs into the PHIB and it may insert additional PHIBs into =
the
bundle, each of which may contain a unique one of the node's additional
singleton EIDs as expressed in this scheme.</span><span style=3D'font-famil=
y:
Consolas'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal>This is really more along the lines of what I was look=
ing
for. &nbsp;The issues was that it wasn't clear to me the exact best policy,
because I couldn't convince myself the facility was really that useful in t=
he
first place (due to above reasons).<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>All that said, with the variant of #1 or the inclusion=
 of #2
for the second issue, plus something along the lines of what you said above=
 for
the first issue, I'd switch from 'no' to 'no objection.'<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>thx,<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>- Kevin<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>3. A =
long
time ago we had the notion of each node having and &quot;administrative
endpoint&quot;.&nbsp; The EID for this is what we probably would want to ha=
ve
inserted into the PHIB.&nbsp; Unfortunately, unless I am mistaken, there is=
 no
such concept in the BP anymore.</span><span style=3D'font-family:Consolas'>=
<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>Which=
, if
any, of the above ways of dealing with this issue best addresses your conce=
rns
so that we can remove your objection?</span><span style=3D'font-family:Cons=
olas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Other more de=
tailed
comments-<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>I don=
't have
any problem with your suggested revisions.</span><span style=3D'font-family=
:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(references s=
hould be
fixed to be using the format as other RFCs)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(normalize up=
per and
lower case usage of Previous Hop Insertion Block)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(maybe define=
 'PHIB';
I will assume so in my further comments)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Is the insert=
ion of a
PHIB controlled via the API, or as a bundle<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;agent configu=
ration
option?<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>PHIB
insertion is controlled via a bundle agent configuration option.</span><spa=
n
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></=
span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></=
span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>-susa=
n</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></=
span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas;color:black'>&nbsp=
;</span><span
style=3D'font-family:Consolas'><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Abstract<o:p>=
</o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;s/The PHIB/Ea=
ch PHIB/<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;s/duration wi=
th the
bundle/presence within a bundle/<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;s/lasts for e=
xactly
one hop/is limited to exactly one hop/<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(no justifica=
tion this
mechanism is &quot;required&quot; for flood routing which<o:p></o:p></span>=
</p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;is given as a=
n
example)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Section 1<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;s/Previous Ho=
p
Block/PHIB/<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Section 2<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(SDNV encodin=
g might
want to reference new RFC/draft describing SDNVs)<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Section 3<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;if its receiv=
ed at
the final destination, is it made<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&quot;availab=
le&quot;
to receiving applications as well?&nbsp; Is this a requirement?<o:p></o:p><=
/span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Section 4<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;s/duration/ex=
tent/<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;Section 5<o:p=
></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;(re)mention t=
hat the
value 0x05 is being suggested for this block<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;&nbsp;<o:p></=
o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;_____________=
__________________________________<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;dtn-interest =
mailing
list<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;dtn-interest@=
maillists.intel-research.net<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-family:Consolas'>&gt;http://mailli=
sts.intel-research.net/mailman/listinfo/dtn-interest<o:p></o:p></span></p>

</div>

</div>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC035258200EIMCMBX2MITREO_--

From: Kevin Fall <[email-masked]>
Date: Fri, 6 Nov 2009 12:31:54 -0800
To: "Symington, Susan F." <[email-masked]>
Cc: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

--Apple-Mail-2-59440875
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii;
	format=flowed;
	delsp=yes

inline..

On Nov 6, 2009, at Nov 611:59 AMPST, Symington, Susan F. wrote:

> Kevin,
>
> I will respond to your comments inline below.
>
> >-----Original Message-----
> >From: [email-masked] [mailto:dtn-
> >[email-masked]] On Behalf Of Kevin  
> Fall
> >Sent: Wednesday, November 04, 2009 4:35 PM
> >To: [email-masked] ilman.dtnrg.org
> >Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-
> >hop-block-07.txt
> >
> >
> >I vote no on this draft in its current form based on the following
> >concerns
> >
> >1. there is not an andequate description of the intended use of
> >    this mechanism.  There is mention of the notion that flood  
> routing
> >    might find this mechanism useful, but no details that explain how
> >    or why.  Furthermore, there is no reference to any other material
> >    that details why identification of the previous hop needs to
> >    be carried in a PDU (as opposed to somewhere else-- e.g., in DTN
> >    could be via a CL protocol).  Now there may be some
> >    reasons [putting bundles on usb drive maybe?], but they aren't
> >    in the doc as written.
>
> The previous hop EID block could be helpful when implementing flood  
> routing because the receiving node would know to exclude the  
> previous hop EID from the list of adjacent nodes to which it sends  
> the bundle as it does its part in flooding the bundle to all of its  
> adjacent neighbors. The node will flood the bundle to all  
> neighboring nodes except for the node from which it received the  
> bundle, as identified in the previous hop EID.
>
> Does this explanation suffice or are you looking for something more?  
> If more, has anyone on the list used the previous hop block for  
> flood routing or for some other purpose that I can mention here in  
> this I-D?

Well.. hmm.  I do not believe this is the best way to go, but yes it  
is conceivable to me that somebody might take this approach, and yes I  
think it would work for that.  RPF checks (like in IP multicast and  
even in basic epidemic routing) does not in general require the PDU to  
be modified to include this info.

>
> As to why it may be useful to have the previous hop block to carry  
> the previous hop EID rather than rely on being able to figure out  
> the previous hop EID from the CL protocol, the point is that it may  
> not always be possible to figure out the previous hop EID from the  
> CL protocol. Would adding these examples to the I-D satisfy your  
> concern, Kevin?:
>
> 1) (Thanks to Mike Demmer) If there is a NAT in the network, then  
> all the senders inside the NAT will appear to have the same IP  
> address to an outside recipient. Some other information other than  
> just the CL addressing is required to distinguish them from one  
> another.

Well, yes and no.  The IP address would appear to be the same but port  
numbers won't be.  Further, and related to above, it would seem  
logical to me that any CL protocol (or at least neighbor discovery  
protocol used prior to CL establishment) includes exchanges of EIDs.    
So, I don't really buy this argument.  [would be nice if we had some  
ND protocol agreed upon]

>
> 2) If tunneling DTN bundles across some portion of the DTN network,  
> it is not possible for the node at the receiving end of the tunnel  
> to determine from the convergence layer the EID of the node at the  
> sending end of the tunnel. The node at the receiving end of the  
> tunnel will receive an encapsulating bundle from one of its adjacent  
> nodes and it may be able to tell the EID of this adjacent node using  
> the convergence layer protocol. However, the node at the sending end  
> of the tunnel is most likely not adjacent to the node at the  
> receiving end of the tunnel, and so in order for the node at the  
> receiving end of the tunnel to be able to learn the EID of the node  
> at the sending end of the tunnel, which is the previous hop node of  
> the tunneled bundle, the EID must be provided within the tunneled  
> bundle. The PHIB would be the vehicle for enabling the node at the  
> sending end of the tunnel to provide its EID to the node at the  
> receiving end of the tunnel.

And this would be used for what?  For flood routing through tunnels?   
I don't feel this has been shown as necessary.   It would seem likely  
to me that if you are a tunnel endpoint, you have already had some  
state regarding the other end of the tunnel.  [I'm also not an  
inherent fan of tunneling for DTN, but that's probably a separate  
discussion].

> >
> >2. there is no description of which EID should be used if the
> >    inserting node is a member of multiple EIDs, and I think this
> >    could be a significant problem when used in the type of
> >    routing context suggested (but see #1).  One might imagine
> >    a set of preferences such as -- if incoming bundle already has
> >    a PHIB and the forwarding node is member of an EID with the same
> >    scheme, that is preferred..  Or, if that doesn't work, maybe
> >    prefer an EID that has a scheme matching either the src or dest
> >    (or another) primary block EID scheme part.  Or, failing that,
> >    the local policy should be able to specify the order of  
> preference
> >    for this capability.
> >
>
> As Stephen points out, living with and documenting the ambiguity may  
> be the best we can do.

I don't think so.  I think your suggestions below would argue that we  
can do something.

>
> I can see a couple of different ways of looking at this that we  
> should consider as we determine how best to word the draft with  
> respect to this issue:
>
> 0. Document the ambiguity and live with it.
>
> 1. Perhaps the previous hop block is not the right place to specify  
> which EID should be included in the PHIB.  The purpose of the PHIB I- 
> D is to define the block in which an EID of the previous hop should  
> be carried, but not necessarily to specify which EID must or should  
> be chosen for inclusion. If a node is configured to include a PHIB  
> in bundles that it forwards (perhaps because the bundles have  
> destination URIs of a certain type, because the bundle is  
> participating in a routing algorithm that uses the PHIB information,  
> or for whatever reason, then the node should also be configured to  
> include the appropriate EID. In other words, whatever is causing  
> that node to include a PHIB in bundles that it forwards better also  
> be causing it to include the correct EID.  If you accept this way of  
> thinking then a way of addressing the issue is to say nothing about  
> which of its EIDs the node should put in the PHIB because that is  
> not the purview of the PHIB I-D.

Well, this might be ok, but instead of not saying anything, I'd refer  
the selection to some other document that discusses what to do when an  
BP agent has to insert its own identity but is a member of multiple  
endpoints.  I agree this issue comes up in various circumstances, but  
I do not know if the rules should be different in the different cases.

>
> 2. The BP says that every bundle node must be a member of at least  
> one singleton endpoint. If a bundle node is a member of exactly one  
> singleton endpoint, the EID of this endpoint is what must be  
> inserted into the PHIB. If a bundle node is a member of more than  
> one singleton endpoint, the EID of the singleton endpoint that is  
> expressed in the same URI scheme as the destination of the bundle  
> being forwarded is what must be inserted into the PHIB. If a bundle  
> is a member of more than one singleton endpoint in the URI scheme  
> used by the destination of the bundle that is being forwarded, the  
> node must insert one of these singleton EIDs into the PHIB and it  
> may insert additional PHIBs into the bundle, each of which may  
> contain a unique one of the node's additional singleton EIDs as  
> expressed in this scheme.

This is really more along the lines of what I was looking for.  The  
issues was that it wasn't clear to me the exact best policy, because I  
couldn't convince myself the facility was really that useful in the  
first place (due to above reasons).

All that said, with the variant of #1 or the inclusion of #2 for the  
second issue, plus something along the lines of what you said above  
for the first issue, I'd switch from 'no' to 'no objection.'

thx,
- Kevin

>
> 3. A long time ago we had the notion of each node having and  
> "administrative endpoint".  The EID for this is what we probably  
> would want to have inserted into the PHIB.  Unfortunately, unless I  
> am mistaken, there is no such concept in the BP anymore.
>
> Which, if any, of the above ways of dealing with this issue best  
> addresses your concerns so that we can remove your objection?
>
> >Other more detailed comments-
>
> I don't have any problem with your suggested revisions.
>
> >
> >(references should be fixed to be using the format as other RFCs)
> >(normalize upper and lower case usage of Previous Hop Insertion  
> Block)
> >(maybe define 'PHIB'; I will assume so in my further comments)
> >
> >Is the insertion of a PHIB controlled via the API, or as a bundle
> >agent configuration option?
>
> PHIB insertion is controlled via a bundle agent configuration option.
>
> -susan
>
> >
> >Abstract
> >
> >s/The PHIB/Each PHIB/
> >s/duration with the bundle/presence within a bundle/
> >s/lasts for exactly one hop/is limited to exactly one hop/
> >
> >(no justification this mechanism is "required" for flood routing  
> which
> >is given as an example)
> >
> >Section 1
> >
> >s/Previous Hop Block/PHIB/
> >
> >Section 2
> >
> >(SDNV encoding might want to reference new RFC/draft describing  
> SDNVs)
> >
> >Section 3
> >if its received at the final destination, is it made
> >"available" to receiving applications as well?  Is this a  
> requirement?
> >
> >Section 4
> >s/duration/extent/
> >
> >Section 5
> >(re)mention that the value 0x05 is being suggested for this block
> >
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-2-59440875
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><base href=3D"x-msg://86/"></head><body style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">inline..<div><br><div><div>On Nov 6, 2009, at Nov =
611:59 AMPST, Symington, Susan F. wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">Kevin,<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
"><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; ">I will respond to your comments inline =
below.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; "><o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;-----Original =
Message-----<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;From:<span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" =
style=3D"color: blue; text-decoration: underline; =
">[email-masked]</a><span =
class=3D"Apple-converted-space">&nbsp;</span>[mailto:dtn-<o:p></o:p></div>=
<div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: =
0.0001pt; margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;[email-masked]] On Behalf Of Kevin =
Fall<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;Sent: Wednesday, November 04, 2009 4:35 =
PM<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;To:<span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; ">[email-masked]</a><span =
class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"http://ilman.dtnrg.org" style=3D"color: blue; text-decoration: =
underline; ">ilman.dtnrg.org</a><o:p></o:p></div><div style=3D"margin-top:=
 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;Subject: [dtn-interest] =
comments on draft-irtf-dtnrg-bundle-previous-<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;hop-block-07.txt<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;I vote no on this draft in its =
current form based on the following<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;concerns<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;1. there =
is not an andequate description of the intended use =
of<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;&nbsp;&nbsp;&nbsp; this mechanism.&nbsp; There is =
mention of the notion that flood routing<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;&nbsp;&nbsp;&nbsp; might find this mechanism useful, but no =
details that explain how<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; or why.&nbsp; =
Furthermore, there is no reference to any other =
material<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; that details why =
identification of the previous hop needs to<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;&nbsp;&nbsp;&nbsp; be carried in a PDU (as opposed to somewhere =
else-- e.g., in DTN<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; could be via a CL =
protocol).&nbsp; Now there may be some<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;&nbsp;&nbsp;&nbsp; reasons [putting bundles on usb drive maybe?], =
but they aren't<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; in the doc as =
written.<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">The =
previous hop EID block could be helpful when implementing flood routing =
because the receiving node would know to exclude the previous hop EID =
from the list of adjacent nodes to which it sends the bundle as it does =
its part in flooding the bundle to all of its adjacent neighbors. The =
node will flood the bundle to all neighboring nodes except for the node =
from which it received the bundle, as identified in the previous hop =
EID.<o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">Does this =
explanation suffice or are you looking for something more? If more, has =
anyone on the list used the previous hop block for flood routing or for =
some other purpose that I can mention here in this =
I-D?</span></div></div></div></span></blockquote><div><br></div>Well.. =
hmm. &nbsp;I do not believe this is the best way to go, but yes it is =
conceivable to me that somebody might take this approach, and yes I =
think it would work for that. &nbsp;RPF checks (like in IP multicast and =
even in basic epidemic routing) does not in general require the PDU to =
be modified to include this info.</div><div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">As to why =
it may be useful to have the previous hop block to carry the previous =
hop EID rather than rely on being able to figure out the previous hop =
EID from the CL protocol, the point is that it may not always be =
possible to figure out the previous hop EID from the CL protocol. Would =
adding these examples to the I-D satisfy your concern, =
Kevin?:<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">1) (Thanks =
to Mike Demmer) If there is a NAT in the network, then all the senders =
inside the NAT will appear to have the same IP address to an outside =
recipient. Some other information other than just the CL addressing is =
required to distinguish them from one =
another.</span></div></div></div></span></blockquote><div><br></div>Well, =
yes and no. &nbsp;The IP address would appear to be the same but port =
numbers won't be. &nbsp;Further, and related to above, it would seem =
logical to me that any CL protocol (or at least neighbor discovery =
protocol used prior to CL establishment) includes exchanges of EIDs. =
&nbsp; So, I don't really buy this argument. &nbsp;[would be nice if we =
had some ND protocol agreed upon]</div><div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">2) If =
tunneling DTN bundles across some portion of the DTN network, it is not =
possible for the node at the receiving end of the tunnel to determine =
from the convergence layer the EID of the node at the sending end of the =
tunnel. The node at the receiving end of the tunnel will receive an =
encapsulating bundle from one of its adjacent nodes and it may be able =
to tell the EID of this adjacent node using the convergence layer =
protocol. However, the node at the sending end of the tunnel is most =
likely not adjacent to the node at the receiving end of the tunnel, and =
so in order for the node at the receiving end of the tunnel to be able =
to learn the EID of the node at the sending end of the tunnel, which is =
the previous hop node of the tunneled bundle, the EID must be provided =
within the tunneled bundle. The PHIB would be the vehicle for enabling =
the node at the sending end of the tunnel to provide its EID to the node =
at the receiving end of the =
tunnel.</span></div></div></div></span></blockquote><div><br></div>And =
this would be used for what? &nbsp;For flood routing through tunnels? =
&nbsp;I don't feel this has been shown as necessary. &nbsp; It would =
seem likely to me that if you are a tunnel endpoint, you have already =
had some state regarding the other end of the tunnel. &nbsp;[I'm also =
not an inherent fan of tunneling for DTN, but that's probably a separate =
discussion].</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;2. there =
is no description of which EID should be used if =
the<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;&nbsp;&nbsp;&nbsp; inserting node is a member of =
multiple EIDs, and I think this<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; could =
be a significant problem when used in the type of<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;&nbsp;&nbsp;&nbsp; routing context suggested (but see #1).&nbsp; =
One might imagine<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; a set of =
preferences such as -- if incoming bundle already =
has<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;&nbsp;&nbsp;&nbsp; a PHIB and the forwarding node is =
member of an EID with the same<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; scheme, =
that is preferred..&nbsp; Or, if that doesn't work, =
maybe<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;&nbsp;&nbsp;&nbsp; prefer an EID that has a scheme =
matching either the src or dest<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; (or =
another) primary block EID scheme part.&nbsp; Or, failing =
that,<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;&nbsp;&nbsp;&nbsp; the local policy should be able to =
specify the order of preference<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;&nbsp;&nbsp;&nbsp; for =
this capability.<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; ">As Stephen points out, living with and =
documenting the ambiguity may be the best we can =
do.</span></div></div></div></span></blockquote><div><br></div>I don't =
think so. &nbsp;I think your suggestions below would argue that we can =
do something.</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">I can see =
a couple of different ways of looking at this that we should consider as =
we determine how best to word the draft with respect to this =
issue:<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">0. =
Document the ambiguity and live with it.<o:p></o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; ">1. Perhaps the previous hop block is not the =
right place to specify which EID should be included in the PHIB.&nbsp; =
The purpose of the PHIB I-D is to define the block in which an EID of =
the previous hop should be carried, but not necessarily to specify which =
EID must or should be chosen for inclusion. If a node is configured to =
include a PHIB in bundles that it forwards (perhaps because the bundles =
have destination URIs of a certain type, because the bundle is =
participating in a routing algorithm that uses the PHIB information, or =
for whatever reason, then the node should also be configured to include =
the appropriate EID. In other words, whatever is causing that node to =
include a PHIB in bundles that it forwards better also be causing it to =
include the correct EID.&nbsp; If you accept this way of thinking then a =
way of addressing the issue is to say nothing about which of its EIDs =
the node should put in the PHIB because that is not the purview of the =
PHIB =
I-D.</span></div></div></div></span></blockquote><div><br></div>Well, =
this might be ok, but instead of not saying anything, I'd refer the =
selection to some other document that discusses what to do when an BP =
agent has to insert its own identity but is a member of multiple =
endpoints. &nbsp;I agree this issue comes up in various circumstances, =
but I do not know if the rules should be different in the different =
cases.</div><div><br><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">2. The BP =
says that every bundle node must be a member of at least one singleton =
endpoint. If a bundle node is a member of exactly one singleton =
endpoint, the EID of this endpoint is what must be inserted into the =
PHIB. If a bundle node is a member of more than one singleton endpoint, =
the EID of the singleton endpoint that is expressed in the same URI =
scheme as the destination of the bundle being forwarded is what must be =
inserted into the PHIB. If a bundle is a member of more than one =
singleton endpoint in the URI scheme used by the destination of the =
bundle that is being forwarded, the node must insert one of these =
singleton EIDs into the PHIB and it may insert additional PHIBs into the =
bundle, each of which may contain a unique one of the node's additional =
singleton EIDs as expressed in this =
scheme.</span></div></div></div></span></blockquote><div><br></div>This =
is really more along the lines of what I was looking for. &nbsp;The =
issues was that it wasn't clear to me the exact best policy, because I =
couldn't convince myself the facility was really that useful in the =
first place (due to above reasons).</div><div><br></div><div>All that =
said, with the variant of #1 or the inclusion of #2 for the second =
issue, plus something along the lines of what you said above for the =
first issue, I'd switch from 'no' to 'no =
objection.'</div><div><br></div><div>thx,</div><div>- =
Kevin</div><div><br></div><div><br></div><div><br><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Helvetica; font-size: medium; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; =
white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">3. A long =
time ago we had the notion of each node having and "administrative =
endpoint".&nbsp; The EID for this is what we probably would want to have =
inserted into the PHIB.&nbsp; Unfortunately, unless I am mistaken, there =
is no such concept in the BP anymore.<o:p></o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; "><o:p>&nbsp;</o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; "><span =
style=3D"color: black; ">Which, if any, of the above ways of dealing =
with this issue best addresses your concerns so that we can remove your =
objection?<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;Other more detailed =
comments-<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; ">I don't =
have any problem with your suggested =
revisions.<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;(references should be fixed to be using the format as other =
RFCs)<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;(normalize upper and lower case usage of Previous Hop =
Insertion Block)<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;(maybe define 'PHIB'; I will assume =
so in my further comments)<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; =
">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;Is the insertion of a PHIB controlled =
via the API, or as a bundle<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; ">&gt;agent configuration =
option?</div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"font-size: =
12pt; font-family: Consolas; color: black; ">PHIB insertion is =
controlled via a bundle agent configuration =
option.<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"font-size: =
12pt; font-family: Consolas; color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
11pt; font-family: Calibri, sans-serif; "><span style=3D"font-size: =
12pt; font-family: Consolas; color: black; =
">-susan<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; "><span style=3D"color: black; =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;Abstract<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;s/The =
PHIB/Each PHIB/<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;s/duration with the bundle/presence =
within a bundle/<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;s/lasts for exactly one hop/is =
limited to exactly one hop/<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; =
">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;(no justification this mechanism is =
"required" for flood routing which<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;is given =
as an example)<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;Section =
1<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;s/Previous Hop =
Block/PHIB/<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; =
font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;Section =
2<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;(SDNV encoding might want to =
reference new RFC/draft describing SDNVs)<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;Section 3<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;if its =
received at the final destination, is it made<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;"available" to receiving applications as well?&nbsp; Is this a =
requirement?<o:p></o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; ">&gt;Section =
4<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;s/duration/extent/<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; ">&gt;Section 5<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;(re)mention that the value 0x05 is being suggested for this =
block<o:p></o:p></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: =
Consolas; ">&gt;<o:p>&nbsp;</o:p></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: =
12pt; font-family: Consolas; =
">&gt;_______________________________________________<o:p></o:p></div><div=
 style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;dtn-interest mailing list<o:p></o:p></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; =
font-size: 12pt; font-family: Consolas; =
">&gt;[email-masked]<o:p></o:p></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; =
margin-left: 0in; font-size: 12pt; font-family: Consolas; =
">&gt;http://maillists.intel-research.net/mailman/listinfo/dtn-interest<o:=
p></o:p></div></div></div></span></blockquote></div><br></div></body></htm=
l>=

--Apple-Mail-2-59440875--

From: "Symington, Susan F." <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked] ilman.dtnrg.org" <[email-masked]>
Date: Fri, 6 Nov 2009 14:59:23 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on	draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0352581F87IMCMBX2MITREO_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Kevin,

I will respond to your comments inline below.

>-----Original Message-----

>From: [email-masked] [mailto:dtn-

>[email-masked]] On Behalf Of Kevin Fall

>Sent: Wednesday, November 04, 2009 4:35 PM

>To: [email-masked] ilman.dtnrg.org

>Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-

>hop-block-07.txt

>

>

>I vote no on this draft in its current form based on the following

>concerns

>

>1. there is not an andequate description of the intended use of

>    this mechanism.  There is mention of the notion that flood routing

>    might find this mechanism useful, but no details that explain how

>    or why.  Furthermore, there is no reference to any other material

>    that details why identification of the previous hop needs to

>    be carried in a PDU (as opposed to somewhere else-- e.g., in DTN

>    could be via a CL protocol).  Now there may be some

>    reasons [putting bundles on usb drive maybe?], but they aren't

>    in the doc as written.

The previous hop EID block could be helpful when implementing flood routing=
 because the receiving node would know to exclude the previous hop EID from=
 the list of adjacent nodes to which it sends the bundle as it does its par=
t in flooding the bundle to all of its adjacent neighbors. The node will fl=
ood the bundle to all neighboring nodes except for the node from which it r=
eceived the bundle, as identified in the previous hop EID.

Does this explanation suffice or are you looking for something more? If mor=
e, has anyone on the list used the previous hop block for flood routing or =
for some other purpose that I can mention here in this I-D?

As to why it may be useful to have the previous hop block to carry the prev=
ious hop EID rather than rely on being able to figure out the previous hop =
EID from the CL protocol, the point is that it may not always be possible t=
o figure out the previous hop EID from the CL protocol. Would adding these =
examples to the I-D satisfy your concern, Kevin?:

1) (Thanks to Mike Demmer) If there is a NAT in the network, then all the s=
enders inside the NAT will appear to have the same IP address to an outside=
 recipient. Some other information other than just the CL addressing is req=
uired to distinguish them from one another.

2) If tunneling DTN bundles across some portion of the DTN network, it is n=
ot possible for the node at the receiving end of the tunnel to determine fr=
om the convergence layer the EID of the node at the sending end of the tunn=
el. The node at the receiving end of the tunnel will receive an encapsulati=
ng bundle from one of its adjacent nodes and it may be able to tell the EID=
 of this adjacent node using the convergence layer protocol. However, the n=
ode at the sending end of the tunnel is most likely not adjacent to the nod=
e at the receiving end of the tunnel, and so in order for the node at the r=
eceiving end of the tunnel to be able to learn the EID of the node at the s=
ending end of the tunnel, which is the previous hop node of the tunneled bu=
ndle, the EID must be provided within the tunneled bundle. The PHIB would b=
e the vehicle for enabling the node at the sending end of the tunnel to pro=
vide its EID to the node at the receiving end of the tunnel.

>

>2. there is no description of which EID should be used if the

>    inserting node is a member of multiple EIDs, and I think this

>    could be a significant problem when used in the type of

>    routing context suggested (but see #1).  One might imagine

>    a set of preferences such as -- if incoming bundle already has

>    a PHIB and the forwarding node is member of an EID with the same

>    scheme, that is preferred..  Or, if that doesn't work, maybe

>    prefer an EID that has a scheme matching either the src or dest

>    (or another) primary block EID scheme part.  Or, failing that,

>    the local policy should be able to specify the order of preference

>    for this capability.

>

As Stephen points out, living with and documenting the ambiguity may be the=
 best we can do.

I can see a couple of different ways of looking at this that we should cons=
ider as we determine how best to word the draft with respect to this issue:

0. Document the ambiguity and live with it.

1. Perhaps the previous hop block is not the right place to specify which E=
ID should be included in the PHIB.  The purpose of the PHIB I-D is to defin=
e the block in which an EID of the previous hop should be carried, but not =
necessarily to specify which EID must or should be chosen for inclusion. If=
 a node is configured to include a PHIB in bundles that it forwards (perhap=
s because the bundles have destination URIs of a certain type, because the =
bundle is participating in a routing algorithm that uses the PHIB informati=
on, or for whatever reason, then the node should also be configured to incl=
ude the appropriate EID. In other words, whatever is causing that node to i=
nclude a PHIB in bundles that it forwards better also be causing it to incl=
ude the correct EID.  If you accept this way of thinking then a way of addr=
essing the issue is to say nothing about which of its EIDs the node should =
put in the PHIB because that is not the purview of the PHIB I-D.

2. The BP says that every bundle node must be a member of at least one sing=
leton endpoint. If a bundle node is a member of exactly one singleton endpo=
int, the EID of this endpoint is what must be inserted into the PHIB. If a =
bundle node is a member of more than one singleton endpoint, the EID of the=
 singleton endpoint that is expressed in the same URI scheme as the destina=
tion of the bundle being forwarded is what must be inserted into the PHIB. =
If a bundle is a member of more than one singleton endpoint in the URI sche=
me used by the destination of the bundle that is being forwarded, the node =
must insert one of these singleton EIDs into the PHIB and it may insert add=
itional PHIBs into the bundle, each of which may contain a unique one of th=
e node's additional singleton EIDs as expressed in this scheme.

3. A long time ago we had the notion of each node having and "administrativ=
e endpoint".  The EID for this is what we probably would want to have inser=
ted into the PHIB.  Unfortunately, unless I am mistaken, there is no such c=
oncept in the BP anymore.

Which, if any, of the above ways of dealing with this issue best addresses =
your concerns so that we can remove your objection?

>Other more detailed comments-

I don't have any problem with your suggested revisions.

>

>(references should be fixed to be using the format as other RFCs)

>(normalize upper and lower case usage of Previous Hop Insertion Block)

>(maybe define 'PHIB'; I will assume so in my further comments)

>

>Is the insertion of a PHIB controlled via the API, or as a bundle

>agent configuration option?

PHIB insertion is controlled via a bundle agent configuration option.

-susan

>

>Abstract

>

>s/The PHIB/Each PHIB/

>s/duration with the bundle/presence within a bundle/

>s/lasts for exactly one hop/is limited to exactly one hop/

>

>(no justification this mechanism is "required" for flood routing which

>is given as an example)

>

>Section 1

>

>s/Previous Hop Block/PHIB/

>

>Section 2

>

>(SDNV encoding might want to reference new RFC/draft describing SDNVs)

>

>Section 3

>if its received at the final destination, is it made

>"available" to receiving applications as well?  Is this a requirement?

>

>Section 4

>s/duration/extent/

>

>Section 5

>(re)mention that the value 0x05 is being suggested for this block

>

>_______________________________________________

>dtn-interest mailing list

>[email-masked]

>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0352581F87IMCMBX2MITREO_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 58.6pt 1.0in 58.55pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText>Kevin,<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>I will respond to your comments inline below.<o:p><=
/o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;-----Original Message-----<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;From:
[email-masked] [mailto:dtn-<o:p></o:p></=
p>

<p class=3DMsoPlainText>&gt;[email-masked]] =
On
Behalf Of Kevin Fall<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;Sent: Wednesday, November 04, 2009 4:35 PM<o:p>=
</o:p></p>

<p class=3DMsoPlainText>&gt;To: [email-masked] ilman.dtnrg.=
org<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;Subject: [dtn-interest] comments on
draft-irtf-dtnrg-bundle-previous-<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;hop-block-07.txt<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;I vote no on this draft in its current form bas=
ed on
the following<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;concerns<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;1. there is not an andequate description of the
intended use of<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; this mechanism.&nbsp; There =
is
mention of the notion that flood routing<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; might find this mechanism us=
eful,
but no details that explain how<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; or why.&nbsp; Furthermore, t=
here
is no reference to any other material<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; that details why identificat=
ion of
the previous hop needs to<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; be carried in a PDU (as oppo=
sed to
somewhere else-- e.g., in DTN<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; could be via a CL protocol).=
&nbsp;
Now there may be some<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; reasons [putting bundles on =
usb
drive maybe?], but they aren't<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; in the doc as written.<o:p><=
/o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>The previous hop EID bl=
ock
could be helpful when implementing flood routing because the receiving node
would know to exclude the previous hop EID from the list of adjacent nodes =
to
which it sends the bundle as it does its part in flooding the bundle to all=
 of
its adjacent neighbors. The node will flood the bundle to all neighboring n=
odes
except for the node from which it received the bundle, as identified in the
previous hop EID.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>Does this explanation s=
uffice
or are you looking for something more? If more, has anyone on the list used=
 the
previous hop block for flood routing or for some other purpose that I can
mention here in this I-D?<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>As to why it may be use=
ful to
have the previous hop block to carry the previous hop EID rather than rely =
on
being able to figure out the previous hop EID from the CL protocol, the poi=
nt
is that it may not always be possible to figure out the previous hop EID fr=
om the
CL protocol. Would adding these examples to the I-D satisfy your concern, K=
evin?:
<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>1) (Thanks to Mike Demm=
er) If
there is a NAT in the network, then all the senders inside the NAT will app=
ear
to have the same IP address to an outside recipient. Some other information
other than just the CL addressing is required to distinguish them from one
another. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>2) If tunneling DTN bun=
dles
across some portion of the DTN network, it is not possible for the node at =
the
receiving end of the tunnel to determine from the convergence layer the EID=
 of
the node at the sending end of the tunnel. The node at the receiving end of=
 the
tunnel will receive an encapsulating bundle from one of its adjacent nodes =
and
it may be able to tell the EID of this adjacent node using the convergence
layer protocol. However, the node at the sending end of the tunnel is most
likely not adjacent to the node at the receiving end of the tunnel, and so =
in
order for the node at the receiving end of the tunnel to be able to learn t=
he
EID of the node at the sending end of the tunnel, which is the previous hop
node of the tunneled bundle, the EID must be provided within the tunneled b=
undle.
The PHIB would be the vehicle for enabling the node at the sending end of t=
he
tunnel to provide its EID to the node at the receiving end of the tunnel.<o=
:p></o:p></span></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;2. there is no description of which EID should =
be
used if the<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; inserting node is a member o=
f
multiple EIDs, and I think this<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; could be a significant probl=
em
when used in the type of<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; routing context suggested (b=
ut see
#1).&nbsp; One might imagine<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; a set of preferences such as=
 -- if
incoming bundle already has<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; a PHIB and the forwarding no=
de is
member of an EID with the same<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; scheme, that is preferred..&=
nbsp;
Or, if that doesn't work, maybe<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; prefer an EID that has a sch=
eme
matching either the src or dest<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; (or another) primary block E=
ID
scheme part.&nbsp; Or, failing that,<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; the local policy should be a=
ble to
specify the order of preference<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&nbsp;&nbsp;&nbsp; for this capability.<o:p></o=
:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>As Stephen points out, =
living
with and documenting the ambiguity may be the best we can do.<o:p></o:p></s=
pan></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I can see a couple of d=
ifferent
ways of looking at this that we should consider as we determine how best to
word the draft with respect to this issue:<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>0. Document the ambigui=
ty and
live with it.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>1. Perhaps the previous=
 hop
block is not the right place to specify which EID should be included in the=
 PHIB.&nbsp;
The purpose of the PHIB I-D is to define the block in which an EID of the
previous hop should be carried, but not necessarily to specify which EID mu=
st
or should be chosen for inclusion. If a node is configured to include a PHI=
B in
bundles that it forwards (perhaps because the bundles have destination URIs=
 of
a certain type, because the bundle is participating in a routing algorithm =
that
uses the PHIB information, or for whatever reason, then the node should als=
o be
configured to include the appropriate EID. In other words, whatever is caus=
ing
that node to include a PHIB in bundles that it forwards better also be caus=
ing
it to include the correct EID.&nbsp; If you accept this way of thinking the=
n a
way of addressing the issue is to say nothing about which of its EIDs the n=
ode should
put in the PHIB because that is not the purview of the PHIB I-D.<o:p></o:p>=
</span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>2. The BP says that eve=
ry
bundle node must be a member of at least one singleton endpoint. If a bundl=
e
node is a member of exactly one singleton endpoint, the EID of this endpoin=
t is
what must be inserted into the PHIB. If a bundle node is a member of more t=
han
one singleton endpoint, the EID of the singleton endpoint that is expressed=
 in
the same URI scheme as the destination of the bundle being forwarded is wha=
t
must be inserted into the PHIB. If a bundle is a member of more than one
singleton endpoint in the URI scheme used by the destination of the bundle =
that
is being forwarded, the node must insert one of these singleton EIDs into t=
he
PHIB and it may insert additional PHIBs into the bundle, each of which may
contain a unique one of the node's additional singleton EIDs as expressed i=
n
this scheme.<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>3. A long time ago we h=
ad the
notion of each node having and &quot;administrative endpoint&quot;.&nbsp; T=
he
EID for this is what we probably would want to have inserted into the
PHIB.&nbsp; Unfortunately, unless I am mistaken, there is no such concept i=
n
the BP anymore. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>Which, if any, of the a=
bove
ways of dealing with this issue best addresses your concerns so that we can
remove your objection? <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;Other more detailed comments-<o:p></o:p></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText><span style=3D'color:black'>I don't have any proble=
m with your
suggested revisions. <o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(references should be fixed to be using the for=
mat as
other RFCs)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(normalize upper and lower case usage of Previo=
us Hop
Insertion Block)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(maybe define 'PHIB'; I will assume so in my fu=
rther
comments)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Is the insertion of a PHIB controlled via the A=
PI, or
as a bundle<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;agent configuration option?</p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'>PHIB insertion is controlled via a bundle agent configuration
option.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:Consolas;
color:black'>-susan<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'color:black'><o:p>&nbsp;</o:p></span=
></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Abstract<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;s/The PHIB/Each PHIB/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/duration with the bundle/presence within a bu=
ndle/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/lasts for exactly one hop/is limited to exact=
ly one
hop/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(no justification this mechanism is
&quot;required&quot; for flood routing which<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;is given as an example)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 1<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;s/Previous Hop Block/PHIB/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 2<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;(SDNV encoding might want to reference new RFC/=
draft
describing SDNVs)<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 3<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;if its received at the final destination, is it=
 made<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;&quot;available&quot; to receiving applications=
 as
well?&nbsp; Is this a requirement?<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 4<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;s/duration/extent/<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;Section 5<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;(re)mention that the value 0x05 is being sugges=
ted
for this block<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>&gt;_______________________________________________=
<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;dtn-interest mailing list<o:p></o:p></p>

<p class=3DMsoPlainText>&gt;[email-masked]<o:p><=
/o:p></p>

<p class=3DMsoPlainText>&gt;http://maillists.intel-research.net/mailman/lis=
tinfo/dtn-interest<o:p></o:p></p>

</div>

</body>

</html>

--_000_F5830D8920D7BA4DB8BCFE1DC57164AC0352581F87IMCMBX2MITREO_--

From: "Symington, Susan F." <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked] ilman.dtnrg.org" <[email-masked]>
Date: Fri, 6 Nov 2009 13:38:28 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-metadata-block-04

Kevin and Stephen, 

I don't disagree with any of your suggested revisions. 

Regarding Kevin's question of whether "available for use" is inclusive of receiving applications, my response would be yes, it should be possible for the metadata to be made available to the receiving application, but whether or not it is an implementation matter.

The bundle protocol, on page 8, in its discussion of "Delivery" says,

"A bundle is considered to have been
      delivered at a node subject to a registration as soon as the
      application data unit that is the payload of the bundle, together
      with the value of the bundle's "Acknowledgement by application is
      requested" flag and any other relevant metadata (an implementation
      matter), has been presented to the node's application agent in a
      manner consistent with the state of that registration and, as
      applicable, the registration's delivery failure action."

In other words, what, if anything other than the payload (for example, an indication that the bundle was sent with certain flags set, or the content of any extension block such as the metadata extension block) is made available to the receiving application is, according to the bundle protocol, an implementation matter.

Also, to clarify what is meant in the draft regarding support for private metadata types, I'm just going to delete the sentence that says, "Support for private metadata types is OPTIONAL."  All I had meant was that implementations are not required to support any particular private metadata types; but this is obvious, so it's best to just omit mention of it altogether.

-susan

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Wednesday, November 04, 2009 5:05 PM
>To: [email-masked] ilman.dtnrg.org
>Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-metadata-
>block-04
>
>I vote "yes, but.." on this draft.  Please see comments below that are
>mostly editorial, but are a lightly substantive as well...
>
>
>Abstract
>
>s/designed to be used to/designed to/
>s/application-level/additional/
>s/DTN-level//
>s/actual//
>s/encoding metadata as URIs/carrying URIs as metadata/
>	[the draft doesn't really specify an encoding process]
>
>Section 1
>
>s/designed to be used to/designed to/
>delete rest of first para after "information,"
>
>s/actual//
>delete the sentence starting "So, although"
>is "available for use" inclusive of receiving applications?
>
>The presumption of:
>	"While the bundle payload is processed opaquely by DTN nodes"
>may not be correct.  I don't believe we have any document that
>currently requires a DTN node to *not* inspect the contents of
>a bundle to make decisions about what it wants to do.
>
>Section 4.2
>
>I'm not too clear on what it means to have support for private
>meta-data types be optional [?].  Do you mean that I could implement
>all the other bits of metadata but choose to not treat the
>speficied range as private/experimental?  Why would that be
>helpful?
>
>Section 6
>(re) mention the definition of value 0x01 for URI meta-data type
>(re) mention the value range for private use
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: [email-masked]
Organization: Trinity College Dublin
Date: Fri, 06 Nov 2009 10:21:59 -0800
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?
Reply-To: [email-masked]

[yes] draft-irtf-dtnrg-sdnv
[yes] draft-irtf-dtnrg-cbhe
[yes] draft-irtf-dtnrg-bundle-previous-hop-block
[yes] draft-irtf-dtnrg-bundle-security
[yes] draft-irtf-dtnrg-bundle-metadata-block

The terms 'DTN-level', 'application-level' and 'network-level' used in
the Abstract and Section one might be too ambiguous

[dunno] draft-irtf-dtnrg-bundle-retrans-block
[dunno] draft-irtf-dtnrg-prophet

Alex
On Fri, 2009-10-30 at 16:07 +0000, [email-masked] wrote:
> 
> [yes|no|dunno] draft-irtf-dtnrg-sdnv
> [yes|no|dunno] draft-irtf-dtnrg-bundle-previous-hop-block
> [yes|no|dunno] draft-irtf-dtnrg-bundle-metadata-block
> [yes|no|dunno] draft-irtf-dtnrg-bundle-retrans-block
> [yes|no|dunno] draft-irtf-dtnrg-cbhe
> [yes|no|dunno] draft-irtf-dtnrg-bundle-security
> [yes|no|dunno] draft-irtf-dtnrg-prophet

Date: Fri, 06 Nov 2009 16:16:29 +0000
From: Elwyn Davies <[email-masked]>
To: Abdullah Azfar <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Help in compiling Python API for DTN

Hi.

This is a piece of 'lore' that ought to be documented!

First of all ensure that your Python installation has the  'distutils' 
installed.

Assuming you have a build of DTN2 on the machine, make the 'applib' 
sub-directory of the DTN build directory your current directory.  Then do
make pythonapi
make pythonapi_install

For native builds this is straightforwards.  For cross compilations 
there are (or maybe) some complications because of the way that the 
Python extension building system works.
 
This process sorts out the requisite definitions of the variables you 
mention automatically.

Regards,
Elwyn

Abdullah Azfar wrote:
> Hi,
> I need to compile the Python API in DTN. I am new in Python and Swig 
> and facing difficulty to compile Python API and test whether it is 
> running by swig. I do not know what to set for the INCDIR, LIBDIR and 
> VERSION environment variables. Please help in this regard. Could 
> anyone please give a pointer for a particular documentation for this 
> setup?
>
> Regards,
>  
> Abdullah Azfar
> NordSecMob Masters Student in Security and Mobile Computing
> Department of Information and Communication Technology
> The Royal Institute of Technology - KTH
> Sweden
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>   

Date: Fri, 06 Nov 2009 15:34:16 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Hot Dead Birds

[email-masked] wrote:
> Actually, the acronym often gets
> considerable time devoted to it by engineers.
>
> Something like
> the Colonel's Hot Edible Expired Poultry (CHEEP).

Duck That's Nuked?

> I guess that from now on it'll be Hot Dead Birds (HDB) protocol.
> 
> Vint Cerf mods Android for interplanetary interwebs
> <http://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/>

Anyone know if there's a build for Android?

S.

Date: Fri, 6 Nov 2009 02:50:12 -0800 (PST)
From: Abdullah Azfar <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Help in compiling Python API for DTN

--0-324430137-1257504612=:31752
Content-Type: text/plain; charset=us-ascii

Hi,
I need to compile the Python API in DTN. I am new in Python and
Swig and facing difficulty to compile Python API and test whether it is
running by swig. I do not know what to set for the INCDIR, LIBDIR and
VERSION environment variables. Please help in this regard. Could anyone
please give a pointer for a particular documentation for this setup?

Regards, 

 Abdullah Azfar
NordSecMob Masters Student in Security and Mobile Computing
Department of Information and Communication Technology
The Royal Institute of Technology - KTH
Sweden

      
--0-324430137-1257504612=:31752
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt;color:#000000;"><font><font size="2"><font size="3">Hi,<br>
I need to compile the Python API in DTN. I am new in Python and
Swig and facing difficulty to compile Python API and test whether it is
running by swig. I do not know what to set for the INCDIR, LIBDIR and
VERSION environment variables. Please help in this regard. Could anyone
please give a pointer for a particular documentation for this setup?<br><br>
Regards,</font>
<br>
</font></font><div>&nbsp;</div><font style="font-family: times new roman,new york,times,serif;" size="3"><span style="color: rgb(33, 33, 67);"><span style="color: rgb(0, 64, 127);">Abdullah Azfar</span><br style="color: rgb(0, 64, 127);"><span style="color: rgb(0, 64, 127);">NordSecMob Masters Student in Security and Mobile Computing</span><br style="color: rgb(0, 64, 127);"><span style="color: rgb(0, 64, 127);">Department of Information and Communication Technology</span><br style="color: rgb(0, 64, 127);"><span style="color: rgb(0, 64, 127);">The Royal Institute of Technology - KTH</span><br style="color: rgb(0, 64, 127);"><span style="color: rgb(0, 64, 127);">Sweden</span><br><br></span></font><div><br></div>
<!-- cg3.c1.mail.mud.yahoo.com compressed/chunked Tue Nov  3 05:14:06 PST 2009 -->
</div><br>

      </body></html>
--0-324430137-1257504612=:31752--

Content-class: urn:content-classes:message
Date: Fri, 6 Nov 2009 07:19:50 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Hot Dead Birds

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA5EB2.1EF72E60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Actually, the acronym often gets
considerable time devoted to it by engineers.

Something like
the Colonel's Hot Edible Expired Poultry (CHEEP).

L.

how did the American chicken cross the road? In a bucket.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Peter Lovell
Sent: Thu 2009-11-05 21:04
To: dtn interest
Subject: [dtn-interest] Hot Dead Birds
=20
I guess that from now on it'll be Hot Dead Birds (HDB) protocol.

Vint Cerf mods Android for interplanetary interwebs
<http://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/>

ROFL

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

------_=_NextPart_001_01CA5EB2.1EF72E60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Hot Dead Birds</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Actually, the acronym often gets<BR>
considerable time devoted to it by engineers.<BR>
<BR>
Something like<BR>
the Colonel's Hot Edible Expired Poultry (CHEEP).<BR>
<BR>
L.<BR>
<BR>
how did the American chicken cross the road? In a bucket.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Peter Lovell<BR>
Sent: Thu 2009-11-05 21:04<BR>
To: dtn interest<BR>
Subject: [dtn-interest] Hot Dead Birds<BR>
<BR>
I guess that from now on it'll be Hot Dead Birds (HDB) protocol.<BR>
<BR>
Vint Cerf mods Android for interplanetary interwebs<BR>
&lt;<A =
HREF=3D"http://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/">htt=
p://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/</A>&gt;<BR>
<BR>
ROFL<BR>
<BR>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA5EB2.1EF72E60--

From: Kevin Fall <[email-masked]>
Date: Thu, 5 Nov 2009 21:41:50 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-security-09

I vote dunno on this draft, as I have a concern, but
am not yet clear if it can [ever, really] be addressed.

The 'security zone' as specified currently precludes overlapping
zones, yet I don't see how an "administrator" in a wireless network
comprised of nodes that have coalesced from different places can
say much about how things will be forwarded.  It appears to me
that the approach of using a stack (where blocks are added and
removed) may be part of the problem here.  What happens if
blocks are "pushed" but not "popped" (i.e. may be added, but aren't
ever removed).  Does that make it feasible to support overlapping
zones?

I may still have additional comments on this draft-- it is quite a
bit of detail to digest, as I'm sure the authors can attest to :).

Abstract

should say more, like what system this spec is providing data
confidentiality and integrity services for (i.e. the bundle protocol),
as the intro does.

Introduction

s/makes it important that the DTN be/makes it important for the DTN to  
be/
s/poses unique challenges on/poses unique challenges for/

the sentence starting "Separate security" is awkward, esp in its
use of pronouns.

fig 1 1st line of caption missing closing ")".
in fig 1, s/Internet/internet/

In para starting "As required in", the order of blocks
-within a bundle- must be preserved.. [right?]..   not necessarily
blocks in general [that may be across bundles]

Section 2.1

some issues wrt the spacing in the names of the defined values
for BAB, PIB, etc

Section 2.2

How can a receiving security-enabled node know, based on the
presence of only something like the PHIB, what the forwarder was?
(said another way perhaps, why does the presence of a PHIB, that
may come from an unsecured node, obviate the presence of the
forwarder info?)

Section 2.4

s/ket/key/
s/in PCB/in the PCB/
s/can be used also to/can also be used to/

please provide reference to AES-GCM
s/re-ecrypting/re-encrypting/
s/earlier encryption as failure to do do/earlier encryption.  Failure  
to do so/
s/(e.g. security destination etc.)/(e.g., security destination)/
s/dtnet/dtn/

Section 2.5
s/(encrypted etc)/(encrypted, etc.)/

the way it is written now, it sounds like if the security source  
(destination) is
not present, the bundle source (destination) is changed to match the  
[nonexistent]
security source (destination).  However, that's not what is really  
intended.

Section 2.7
s/However/However,/
s/etc/, etc.,/

Section 2.8
s/in order/designed/

What happens if security zones wind up overlapping partially?  It may  
be out of
an administrator's control.

Section 3.3

Some disquieting stuff here.
Hmm.  Is is really necessary to strip blocks once processed?

Figure 5
doesn't appear to use proper ascii art to depict variable length  
portions
(like in EIDs)

Section 3.4.2

seems like the value 0x0000 0000 003E 031F should get
some symbolic name like "PRIMCANONMASK"-- a thing that shows
up in the IANA section that we can easily mod later if
the structure of reserved bits changes
similar for 0x0000 0000 0000 0057 with some other symbolic nam.e

Figure 6/7
the ASCII art here seems incorrect.. a missing pair of "+" characters  
maybe?

Section 9
shoud summarize all the values being defined

Date: Fri, 06 Nov 2009 00:21:21 +0000
From: Elwyn Davies <[email-masked]>
To: [email-masked]
Cc: DTN <[email-masked]>
Subject: [dtn-interest] Comments on draft-irtf-dtnrg-sdnv-03

General comment:
Although the original intent was to provide a mechanism that would allow 
encoding of arbitrarily large/long numbers, the SDNV mechanism, as now 
defined, will allow encoding of any bit pattern of any arbitrary, 
variable length.  Some of the examples refer to things that aren't 
numbers,and some of the existing uses are for (e.g.) flag fields that 
aren't really numbers.

The algorithms are (mostly) specified so that the encoding is decoupled 
from the semantics of the value being encoded - the semantics are 
implied by the definition of the protocols that use the SDNV encoding.

The descriptive text, on the other hand, is inconsistent.  Some of the 
text implies that SDNVs are really for (non-negative) numbers.  The 
editorial suggestions below are designed to remove the inconsistency, 
making it clear that you can use SDNV encoding for any type of bit 
pattern, especially its major advantage that it doesn't  place any 
constraints on the  contents of the bit pattern (as compared with, say, 
NULL terminated strings).

Minor issue:
s5, para 2:

Editorial suggestions:
[I haven't duplicated Kevin's suggestions - I agree with them.]
Global: s/byte/octet/
Abstract: s/non-negative integer/bitstring/

s1.1, title: s/Fixed  Value/Values Stored in Fixed Width Fields/

s1.3:
Replace first sentence:
>    In short, an SDNV is simply a way of representing non-negative
>    integers (both positive integers of arbitrary magnitude and 0),
>    without expending too-much unneccessary space.
In short, an SDNV is a way of representing an arbitrarily long bit 
pattern in the bits transmitted on the wire without expending too much 
unnecessary space or constraining the bit pattern that can be 
represented.  The bit pattern could be a binary representation of an 
arbitrarily large integer or any other item that requires a 
representation that is variable in length.  The derivation and 
interpretation of the encoded bit pattern is left to the protocol that 
makes use of the SDNV representation of a field. The SDNV representation 
puts no requirements on the pattern to be encoded.

s2, para 1: s/bore resemblance/bore a resemblance/

s2,para 3: Replace second sentence, i.e.
> Before encoding, an
>    integer is represented as a left-to-right bitstring beginning with
>    its most significant bit, and ending with its least signifcant bit.
>   
Before encoding, the bit pattern to be transmitted is represented as a 
left-to-right bitstring derived from the external value of the field as 
specified by the protocol using the SDNV for the field.

s2, para 4: s/For example:/For example, if the value to be sent is an 
integer, the value to be sent is represented as a left-to-right 
bitstring with the most significant bit at the left (i.e., network bit 
order):

o  0 (decimal) is represented as the bitstring "00000000" and encoded as 
the single octet 0x00.
/

s3.1, para 1: s/non-negative integer/bitstring/

s4, para before Table 1: s/maximum values/maximum value of an integer/

Appendix A:
The encoding routine would indeed not work if the integer n is negative 
(on account of the loop never terminating as eventually all the bits 
left over will be 1's).  However, it appears that an SDNV could encode a 
signed number provided the protocol using the SDNV is clear what it is 
doing.  The piece about using unsigned values in the decoder noted in 
the Security section is valid, but the bit pattern is passed to the 
'higher levels' of the protocol processor  which seems to be at liberty 
to treat the bit pattern as a signed number. 

Regards,
Elwyn

From: Peter Lovell <[email-masked]>
To: dtn interest <[email-masked]>
Date: Thu, 05 Nov 2009 16:04:41 -0500
Subject: [dtn-interest] Hot Dead Birds

I guess that from now on it'll be Hot Dead Birds (HDB) protocol.

Vint Cerf mods Android for interplanetary interwebs
<http://www.theregister.co.uk/2009/11/05/vint_cerf_on_mobile/>

ROFL

Date: Thu, 05 Nov 2009 16:40:52 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

Hi All,

First, thanks for the feedback sent so far, do keep
it coming.

Here's how Kevin and I propose to process the feedback
from this "yet another last call":

Based on the feedback sent to the list, we'll decide
(probably on Monday) which are ready to go forward.

We may decide that draft-foo should go ahead only
if the authors address comment-bar. But, we won't be
requiring unanimous "yes" opinions, essentially this
will be a judgment call, based on the comments to
the list, and not just a simple accounting exercise.

So if you've opinions to express, please mail them
to the list now.

We will start the IRSG review process for the drafts
that are ready on November 20. So, authors, please ensure
that any changes that are needed are done before then.
You can submit new drafts from Monday.

If, based on the list feedback, we decide that some of
these drafts aren't quite ready yet, the authors of
those still have a chance to take the list feedback into
account and if they turn enough (decided by the chairs)
"no" opinions into "yes" opinions by Nov 20 then we'll
include those drafts in the batch submitted for IRSG
review.

Remaining drafts (if any) won't go forward at this time.
The next time we'll do this will most likely be early
in the new year, if more documents look like they're
ready by then.

And, of course, we'll be in "chair" mode while doing
this, so our own personal comments only count as much
those from anyone else that contributes to DTNRG.

Regards,
Stephen & Kevin.

[email-masked] wrote:
> ...or at least I hope they're done. (And my apologies
> for being so slow getting this done.)
> 
> I think we should finally declare victory on these before
> we meet in Hiroshima and shoot them over to the IRSG for
> review.
> 
> But we need some messages to the list saying "yes" for that
> to happen.
> 
> Please respond to this mail saying yes/no/dunno for each
> of these before Friday November 6th.
> 
> [yes|no|dunno] draft-irtf-dtnrg-sdnv
> [yes|no|dunno] draft-irtf-dtnrg-bundle-previous-hop-block
> [yes|no|dunno] draft-irtf-dtnrg-bundle-metadata-block
> [yes|no|dunno] draft-irtf-dtnrg-bundle-retrans-block
> [yes|no|dunno] draft-irtf-dtnrg-cbhe
> [yes|no|dunno] draft-irtf-dtnrg-bundle-security
> [yes|no|dunno] draft-irtf-dtnrg-prophet
> 
> - "yes" means "I think this is ready to be an RFC" and
>   can be accompanied by editorial or minor comments/suggestions
> - "no" requires substantive accompanying comments, i.e. you
>   need to say why not, or we'll treat that as "dunno"
> - dunno means you've not read it or don't care
> 
> I'm giving them a read over now, and will send my own
> response when that's done.
> 
> Thanks,
> Stephen.
> 
> PS: I'm going to post a draft agenda for our session (on
> Friday Nov 13th) in a hour or two, so yet another chance
> to ask for a slot, if you've not already.
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked] ilman.dtnrg.org" <[email-masked]>
Date: Thu, 5 Nov 2009 07:42:42 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-cbhe-02 (expired draft, needs refresh)

Thanks, Kevin.  I'll modify and re-post.  A couple of clarifications in-line below:

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Kevin Fall
> Sent: Wednesday, November 04, 2009 7:08 PM
> To: [email-masked] ilman.dtnrg.org
> Subject: [dtn-interest] comments on draft-irtf-dtnrg-cbhe-02 (expired
> draft, needs refresh)
> 
> 
> I vote yes on this draft, but have a couple of editorial comments
> including one typo....
> 
> section 2.1
> 
> s/configured to figured/configured/

This is weird; I can't find the erroneous text in the XML.  Hoping it will disappear when I re-post.

> s/spacecraft identifier/a spacecraft identifier/

Sure, except "spacecraft identifier" is not a generic term in CCSDS-based space flight ops, so it's not the case that you can choose one among a variety of spacecraft identifiers and use that as the node number; "a spacecraft identifier" isn't quite right.  So I'm changing the text as s/spacecraft identifier/spacecraft identifiers/ and s/node number/node numbers/.

> s/within BP/within the BP/

Sure.

> In the example, why "dtn::ipn..." instead of "dtn:ipn..."?

This is for compatibility with the general syntax we're trying to standardize on in the "DTN URI Scheme" I-D, as in section 3.3 of that draft.

> s/this constraint/these constraints/

Actually the sentence is referring to just a single constraint, the precondition "that the endpoint ID reference strings in the dictionary of the bundle to be compressed must be exactly as follows, in this order and without addition".  There's a long list of EID reference strings but only a single constraint.  So I think it's correct as written.

Scott

Date: Thu, 05 Nov 2009 13:53:23 +0000
From: Paulo Mendes <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] U-NET'09 workshop, co-located with ACM CoNext: Call for Participation

(Apologies if you get this twice)

ACM U-NET'09 � User-provided Networking: Challenges and Opportunities
Co-located with ACM CoNEXT 2009
Rome, Italy, December 1st, 2009
http://conferences.sigcomm.org/co-next/2009/workshops/unet/

The organizing committee of U-NET'09 is delighted to invite you to 
participate in this first edition.

This workshop is dedicated to the debate of concepts, challenges, and 
opportunities concerning user-provided networking, i.e., scenarios where 
users cooperate by sharing wireless resources as well as Internet 
services. U-NET'09 aims to be a forum to debate the technical challenges 
and impact of deploying user-provided networking technology.

The program covers the presentation of 7 papers which have been grouped 
into three different sections: cooperation incentives and security; 
social-aware UPNs; cooperative UPNs.

In addition to the paper sessions, we will have a discussion panel 
entitled: "Challenges and Impact of Deploying User-provided Networking 
Technology", for which four speakers both from academia and industry 
have been invited and which has the purpose to ignite discussion around 
the topic of user-provided networks.

You can check the program here: 
http://conferences.sigcomm.org/co-next/2009/workshops/unet/

In addition, registrations are open both for CoNext and for U-NET, by 
means of EDAS, and accessible here:
http://conferences.sigcomm.org/co-next/2009/workshops/unet/registration.php

Looking forward to seeing you in Rome,

The U-NET09 Organizing Committee.

Paulo Mendes
-----------------------------------------------------
Paulo Mendes, Ph.D
Area Leader, Internet Architectures and Networking
Telecommunication and Multimedia Unit
INESC Porto
Tel. +351 22 209 4264
Fax. +351 22 209 4050
http://ian.inescporto.pt

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 21:05:10 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-prophet-02 (expired draft, needs refresh)

I vote no on this draft, with the following concerns:

what can be expressed as destinations?
	For example, if a node has registrations for 5 EIDs, will
	all of them appear advertised in the routing system?
	[it appears the answer is no].  Also, the system uses
	16 bits for a string ID.  Does this limit the system, or
	advertisements, to 64k EIDs?

what is the encapsulation mechanism of prophet messages relative to  
bundles?
	are any of the BP bflags required to be set?
	it looks like Prophet has its own fragmentation?

there appear to be restrictions on the length of EIDs because there
are fixed length fields that are too small (8 bits) for holding the
length of an EID

More details---

(this draft has very many levels of depth... e.g., 2.1.1.1.2)

Introduction

"Real users" have become humans by paragraph 4,
yet there was no mention up to this point that the mobile
nodes are humans, or are attached to humans.  Why is
this a valid assumption?  I'd suggest either introducing
assumptions behind what the nodes are, or providing
a reference.

s/previously discussed/previously-discussed/

In the phrase "where it is applicable", what does "it" refer
to?  (Prophet?)

s/In this draft, we/We/

Section 1.1

s/intermittently connected/intermittently-connected/
s/protocoll/protocol/
s/on if/as to whether or not/
s/bundling protocol/bundle protocol/
s/reliability/acknowledgments/

Section 2.1.x...

"which bundles to request to be forwarded from the other node"
	Prophet has a way for a bundle to be 'requested to be forwarded'
	from another?  This might be something BP might want to have.
	Having it limited only to the routing protocol seems unfortunate.

what might be an appropriate value for alpha in the EWMA?

Section 2.1.1.1.2
s/investigate/investigated/

Section 2.1.2

s/made on/made/

Section 3.5

How does a node come to know it is the "destination" within the  
prophet zone?

Section 3.6

If nodes define their own forwarding strategies, how can it
be ensured (or argued with some probability) that bundles get to
where they are going?

Related, it would be nice if more guidance was given as to which
of the several forwarding strategies would be good under what
circumstances.

Section 3.7

s/need to be/needs to be/
Related, it would be nice if more guidance was given as to which
of the several queing strategies would good under what circumstances.

Section 4.2

why is a protocol identifier needed?  (relates to encapsulation
question above)

how and where is the pseudoheader used?  How does this work in the
context of the BP?

Section 4.4

It appears that the length of an EID is limited to 8 bits.  This
is a significant issue, given that EIDs can be more like 2K in length.

Also, "the sender's EID" isn't really well-defined.  Which one if
there are many?

Section 6

doesn't make reference to the terminology of the bundle
security protocol

Section 6.1.5

s/Nanipulation/Manipulation/

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 19:08:29 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-cbhe-02 (expired draft, needs refresh)

I vote yes on this draft, but have a couple of editorial comments
including one typo....

section 2.1

s/configured to figured/configured/
s/spacecraft identifier/a spacecraft identifier/
s/within BP/within the BP/

In the example, why "dtn::ipn..." instead of "dtn:ipn..."?
s/this constraint/these constraints/

Date: Wed, 04 Nov 2009 23:22:52 +0000
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] comments on	draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

Hmm, interesting point.

Kevin Fall wrote:
> 2. there is no description of which EID should be used if the
>     inserting node is a member of multiple EIDs, and I think this
>     could be a significant problem when used in the type of
>     routing context suggested (but see #1).  One might imagine
>     a set of preferences such as -- if incoming bundle already has
>     a PHIB and the forwarding node is member of an EID with the same
>     scheme, that is preferred..  Or, if that doesn't work, maybe
>     prefer an EID that has a scheme matching either the src or dest
>     (or another) primary block EID scheme part.  Or, failing that,
>     the local policy should be able to specify the order of preference
>     for this capability.

I agree that the current draft has an ambiguity there, and
that that ambiguity could cause unexpected, and possibly bad,
behaviour. However, I'm wondering if any unambiguous way of
saying which EID to use exists that might not cause similarly
unexpected behaviour. And clearly punting to "policy" or
configuration could also cause equivalent oddness.

So, would living with (but documenting) the ambiguity be
best for now, until we find out more by experimenting? (Not
sure myself but it could get the document done, which'd
be nice:-)

S.

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 14:50:30 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-retrans-block-06

I vote no on this draft.

As written this draft intertwines a broad capability and set of  
requirements for elimination of duplicates
with the relatively simple mechanism of the retransmission block.  It  
also ties these together so
closely that a node implementing RB must implement the rest of the all  
the other features, including
a checksum on payloads that doesn't appear to be defined.

I believe the retransmission block can (and should) be independently  
defined to simply say what it does:
indicate the retransmission sequence number of a custodian.  I also  
wouldn't be shocked if it turns
out to be useful to include the rtx seq# in custody acks somehow, but  
that may be another discussion.
(thinking along the lines of retransmission ambiguity in TCP).

Much of the rest of the draft should, I believe strongly,
be placed in a separate document that addresses what happens in a DTN  
that wishes to try and
protect itself against replays.  {this might make a decent research  
paper too maybe}.  Doing this
has major implications on what a DTN node (and network) has to do--  
avoid loops, keep track of
what bundles have been seen, etc.

I'm also think I'm confused about just how fragments are handled.  If  
a fragment is lost in transit
after going through node A (that records it in its record of 'seen'  
traffic), would a subsequent
retransmission of this same fragment going through A be suppressed  
[because the block is
not included in framents]?  (Maybe I missed something subtle there.)

- K

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 14:05:05 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-metadata-block-04

I vote "yes, but.." on this draft.  Please see comments below that are  
mostly editorial, but are a lightly substantive as well...

Abstract

s/designed to be used to/designed to/
s/application-level/additional/
s/DTN-level//
s/actual//
s/encoding metadata as URIs/carrying URIs as metadata/
	[the draft doesn't really specify an encoding process]

Section 1

s/designed to be used to/designed to/
delete rest of first para after "information,"

s/actual//
delete the sentence starting "So, although"
is "available for use" inclusive of receiving applications?

The presumption of:
	"While the bundle payload is processed opaquely by DTN nodes"
may not be correct.  I don't believe we have any document that
currently requires a DTN node to *not* inspect the contents of
a bundle to make decisions about what it wants to do.

Section 4.2

I'm not too clear on what it means to have support for private
meta-data types be optional [?].  Do you mean that I could implement
all the other bits of metadata but choose to not treat the
speficied range as private/experimental?  Why would that be
helpful?

Section 6
(re) mention the definition of value 0x01 for URI meta-data type
(re) mention the value range for private use

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 13:34:57 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-previous-hop-block-07.txt

I vote no on this draft in its current form based on the following  
concerns

1. there is not an andequate description of the intended use of
    this mechanism.  There is mention of the notion that flood routing
    might find this mechanism useful, but no details that explain how
    or why.  Furthermore, there is no reference to any other material
    that details why identification of the previous hop needs to
    be carried in a PDU (as opposed to somewhere else-- e.g., in DTN
    could be via a CL protocol).  Now there may be some
    reasons [putting bundles on usb drive maybe?], but they aren't
    in the doc as written.

2. there is no description of which EID should be used if the
    inserting node is a member of multiple EIDs, and I think this
    could be a significant problem when used in the type of
    routing context suggested (but see #1).  One might imagine
    a set of preferences such as -- if incoming bundle already has
    a PHIB and the forwarding node is member of an EID with the same
    scheme, that is preferred..  Or, if that doesn't work, maybe
    prefer an EID that has a scheme matching either the src or dest
    (or another) primary block EID scheme part.  Or, failing that,
    the local policy should be able to specify the order of preference
    for this capability.

Other more detailed comments-

(references should be fixed to be using the format as other RFCs)
(normalize upper and lower case usage of Previous Hop Insertion Block)
(maybe define 'PHIB'; I will assume so in my further comments)

Is the insertion of a PHIB controlled via the API, or as a bundle
agent configuration option?

Abstract

s/The PHIB/Each PHIB/
s/duration with the bundle/presence within a bundle/
s/lasts for exactly one hop/is limited to exactly one hop/

(no justification this mechanism is "required" for flood routing which
is given as an example)

Section 1

s/Previous Hop Block/PHIB/

Section 2

(SDNV encoding might want to reference new RFC/draft describing SDNVs)

Section 3
if its received at the final destination, is it made
"available" to receiving applications as well?  Is this a requirement?

Section 4
s/duration/extent/

Section 5
(re)mention that the value 0x05 is being suggested for this block

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked] ilman.dtnrg.org" <[email-masked]>
Date: Wed, 4 Nov 2009 13:53:08 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-sdnv-03

All look good to me; I'll submit a patched version when the system opens
up next week.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Wednesday, November 04, 2009 2:43 PM
>To: [email-masked] ilman.dtnrg.org
>Subject: [dtn-interest] comments on draft-irtf-dtnrg-sdnv-03
>
>
>
>I vote yes on this document but have some editorial suggestions
>described below.
>
>- Kevin
>
>
>
>
>Abstract
>
>s/wire-overhead/overhead/
>
>remove "nor is the problem too solution too radical for more mundane
>uses"
>	[sounds like we are positioning ourselves as 'way not mundane']
>
>section 1.1
>
>s/on the wire//
>s/high-rates/high throughput/
>s/bi-rectional support/support from each end of a TCP connection/
>s/side-issues/other issues/
>s/begun/just begun/
>s/total headers/headers/
>
>section 1.3
>
>s/too-much/much/
>s/somewhat circumvent/ameliorate the consequences of/
>s/since/as/
>s/use SDNVs however/use SDNVs; however,/
>s/too-small/too small/
>s/here of fields/here, of fields/
>s/Internet protocols/Internet protocols,/
>s/wire-format/format/
>
>section 2
>
>s/currently-used format/format used currently/
>s/On the wire/When transmitted/
>s/wire format//
>s/in-order/in order/
>s/leading-zeros/
>remove the sentence starting "Only SDNV's of the currently-...."
>	[it seems distracting]
>
>section 3.1
>s/(n/(value n/
>s/left in/of/
>s/Set n to itself shifted right 7 bits/Shift n right 7 bits/
>
>section 3.2
>s/in reality//
>
>section 4
>s/Type"/"Type"/
>s/Length/"Length"/
>(or get rid of all quotation marks)
>s/pick fixed-lengths/choose fixed field lengths/
>s/currently-used/current/
>s/one-bit/one bit/
>s/bit-errors/bit errors/
>
>section 7
>(will probably need to do a pass on this)
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
Date: Wed, 4 Nov 2009 11:43:03 -0800
To: "[email-masked] ilman.dtnrg.org" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-sdnv-03

I vote yes on this document but have some editorial suggestions  
described below.

- Kevin

Abstract

s/wire-overhead/overhead/

remove "nor is the problem too solution too radical for more mundane  
uses"
	[sounds like we are positioning ourselves as 'way not mundane']

section 1.1

s/on the wire//
s/high-rates/high throughput/
s/bi-rectional support/support from each end of a TCP connection/
s/side-issues/other issues/
s/begun/just begun/
s/total headers/headers/

section 1.3

s/too-much/much/
s/somewhat circumvent/ameliorate the consequences of/
s/since/as/
s/use SDNVs however/use SDNVs; however,/
s/too-small/too small/
s/here of fields/here, of fields/
s/Internet protocols/Internet protocols,/
s/wire-format/format/

section 2

s/currently-used format/format used currently/
s/On the wire/When transmitted/
s/wire format//
s/in-order/in order/
s/leading-zeros/
remove the sentence starting "Only SDNV's of the currently-...."
	[it seems distracting]

section 3.1
s/(n/(value n/
s/left in/of/
s/Set n to itself shifted right 7 bits/Shift n right 7 bits/

section 3.2
s/in reality//

section 4
s/Type"/"Type"/
s/Length/"Length"/
(or get rid of all quotation marks)
s/pick fixed-lengths/choose fixed field lengths/
s/currently-used/current/
s/one-bit/one bit/
s/bit-errors/bit errors/

section 7
(will probably need to do a pass on this)

From: Peter Lovell <[email-masked]>
To: Lloyd Wood <[email-masked]>, "William D. (GRC-RCN0) Ivancic" <[email-masked]>
Date: Wed, 04 Nov 2009 00:42:31 -0500
Cc: dtn interest <[email-masked]>, "Henry B. Hotz" <[email-masked]>
Subject: [dtn-interest] Re(2): Potential DTN/IP Security Vulnerability regarding firewalls

On Wed, Nov 4, 2009, Lloyd Wood <[email-masked]> wrote:

>
>On 4 Nov 2009, at 00:00, Ivancic, William D. (GRC-RHN0) wrote:
>>
>>
>> I am sure once DTN gets mature and is worthwhile to hack, it will
>> be.  Poor coding, buffer overflows, overlooking something, etcetera
>> etcetera...
>
>What about the potential for DoS attacks via custody transfer
>acknowledgements? Just say you'll accept the bundle, send a custody
>transfer ack, don't do anything else.
>
>(I suppose that the custody transfer ack could include the result of
>some computation across the bundle to prove that it had actually been
>received in full. At which point, DoS attacks become slightly more
>expensive.)
>
>That all presumes heterogeneous multi-actor multi-owner bundle
>networks with untrusted relays, which I believe to be unlikely; fewer
>attack scenarios in a single-owner single-purpose homogeneous network.
>
>L.

Well, that's no worse than truthfully saying you accept custody, with
every intent of fulfilling your agreement, and shortly thereafter being
vapo(u)rized by a malevolent meteor.

Or, in a more mundane world, just having your power supply fried by
overvoltage from your local supplier.

I think we deal already with the case of a single bad actor.

The scenario with an unknown number of untrustworthy relays is another
matter, and one that the custody transfer mechanism is not intending to
solve.

My initial thought is that it's more of a trusted-router problem, in
that you have to find some way to establish the level of trustworthiness
for a next-hop. Sounds like a research project for someone  :)

Cheers.....Peter

From: Lloyd Wood <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 4 Nov 2009 04:00:53 +0000
Cc: "[email-masked]" <[email-masked]>, "Henry B. Hotz" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

On 4 Nov 2009, at 00:00, Ivancic, William D. (GRC-RHN0) wrote:
>
>
> I am sure once DTN gets mature and is worthwhile to hack, it will  
> be.  Poor coding, buffer overflows, overlooking something, etcetera  
> etcetera...

What about the potential for DoS attacks via custody transfer  
acknowledgements? Just say you'll accept the bundle, send a custody  
transfer ack, don't do anything else.

(I suppose that the custody transfer ack could include the result of  
some computation across the bundle to prove that it had actually been  
received in full. At which point, DoS attacks become slightly more  
expensive.)

That all presumes heterogeneous multi-actor multi-owner bundle  
networks with untrusted relays, which I believe to be unlikely; fewer  
attack scenarios in a single-owner single-purpose homogeneous network.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Henry B. Hotz" <[email-masked]>
Date: Tue, 3 Nov 2009 18:00:21 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

I'm talking about serious hacking.  There are lots of ways to get into a system.  This has nothing to do with routing and nothing the bundle layer would ever see.  The informational email was to warn people that there is potential to  compromise a network inside a firewall  via IP because you have established a nearly continuous hole in your firewall.

I am sure once DTN gets mature and is worthwhile to hack, it will be.  Poor coding, buffer overflows, overlooking something, etcetera etcetera...

-- Will

>-----Original Message-----
>From: Henry B. Hotz [mailto:[email-masked]]
>Sent: Tuesday, November 03, 2009 6:17 PM
>To: Ivancic, William D. (GRC-RHN0)
>Cc: Greg Troxel; [email-masked]
>Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability
>regarding firewalls
>
>"All" is a bit strong.  If you're using IP for routing/delivery, then
>certainly an IP-layer flaw can mess up routing/delivery, and a DTN
>overlay takes on those issues.
>
>OTOH if the bundle is checksummed or encrypted then you need the
>relevant keys to alter that.
>
>On Nov 3, 2009, at 2:20 PM, Ivancic, William D. (GRC-RHN0) wrote:
>
>> Not at the IP Layer!  Note,  a network overlay (any network overlay)
>> take on all the vulnerabilities of the underlying networks they run
>> on plus whatever they introduce.
>>
>>
>> --Will
>>
>>> From: Henry B. Hotz [mailto:[email-masked]]
>>> Sent: Tuesday, November 03, 2009 4:06 PM
>>> To: Greg Troxel
>>> Cc: Ivancic, William D. (GRC-RHN0); [email-masked]
>>> Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability
>>> regarding firewalls
>>>
>>> Doesn't BSP offer you some solutions?  Ought to be able to filter out
>>> extraneous traffic as long as it doesn't flood the connection
>>> bandwidth.
>
>------------------------------------------------------
>The opinions expressed in this message are mine,
>not those of Caltech, JPL, NASA, or the US Government.
>[email-masked], or [email-masked]
>
>

From: Greg Troxel <[email-masked]>
To: "Henry B. Hotz" <[email-masked]>
Date: Tue, 03 Nov 2009 18:33:14 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

--=-=-=

"Henry B. Hotz" <[email-masked]> writes:

> "All" is a bit strong.  If you're using IP for routing/delivery, then
> certainly an IP-layer flaw can mess up routing/delivery, and a DTN
> overlay takes on those issues.
>
> OTOH if the bundle is checksummed or encrypted then you need the
> relevant keys to alter that.

Sure, but we started off talking about firewalls, and if a BP-level
exploit could compromise a network that has BP connectivity but is
somehow protected at IP.  That exploit could be delivered in a
BSP-protected package, which would be analagous to spam over TLS or
browser exploits delivered by a web server over SSL.

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Henry B. Hotz" <[email-masked]>, Greg Troxel <[email-masked]>
Date: Tue, 3 Nov 2009 16:20:07 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

Not at the IP Layer!  Note,  a network overlay (any network overlay) take on all the vulnerabilities of the underlying networks they run on plus whatever they introduce.  

--Will

>From: Henry B. Hotz [mailto:[email-masked]]
>Sent: Tuesday, November 03, 2009 4:06 PM
>To: Greg Troxel
>Cc: Ivancic, William D. (GRC-RHN0); [email-masked]
>Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability
>regarding firewalls
>
>Doesn't BSP offer you some solutions?  Ought to be able to filter out
>extraneous traffic as long as it doesn't flood the connection bandwidth.
>
>------------------------------------------------------
>The opinions expressed in this message are mine,
>not those of Caltech, JPL, NASA, or the US Government.
>[email-masked], or [email-masked]
>
>

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 3 Nov 2009 16:16:09 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

I'm sure there are a number of possible ways to improve the security through the firewall depending on what you are trying to do.  I haven't really thought about much.  The real purpose for the post was to inform others of something they may have overlooked or not considered.  I certainly didn't think about it before this little experiment where we just stumbled upon the potential vulnerability.

For the particular situation I was addressing, I could probably bring the links up and down when I need them.  This is a very specific situation.

--Will

>-----Original Message-----
>From: Kevin Fall [mailto:[email-masked]]
>Sent: Monday, November 02, 2009 4:53 PM
>To: Ivancic, William D. (GRC-RHN0)
>Cc: [email-masked]
>Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability
>regarding firewalls
>
>I guess my thought would be that depending on NAT for your security is
>probably not advisable.  Given that TCP is by design a bi-directional
>protocol, choosing it for the CL would, I think, naturally lead to
>behavior of this sort.  One could arrange an option to not receive
>incoming bundles, or to close down half the TCP connection.  Doing the
>later would certainly increase the challenge regarding e2e and custody
>ACKs.
>
>- K
>
>
>On Nov 2, 2009, at Nov 210:48 AMPST, Ivancic, William D. (GRC-RHN0)
>wrote:
>
>> At GRC we implemented a Bundle Agent behind a firewall hopping to a
>> bundle agent on the open network with TCP convergence layer using
>> NAT in the firewall.  The route on the closed network points to the
>> TCP endpoint of the node on the open network.  The route on the open
>> network points to the Firewall open network address (exposed
>> address).  We open the connection between closed-node and open-node
>> using link open and DTNping from closed-node to open-node.  We then
>> DTNping from open-node to closed node!  After thinking about this a
>> bit, we believe the DTN TCP convergence layer maintains state in the
>> NAT table once we do a link open command on the closed-node.  We now
>> have a TCP hole in the firewall on a specific port that might be a
>> place to exploit via TCP (and perhaps DTN).
>>
>> Thoughts?
>>
>> --Will
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Greg Troxel <[email-masked]>
To: "Ivancic\, William D. \(GRC-RHN0\)" <[email-masked]>
Date: Tue, 03 Nov 2009 07:41:22 -0500
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

--=-=-=

"Ivancic, William D. (GRC-RHN0)" <[email-masked]> writes:

> At GRC we implemented a Bundle Agent behind a firewall hopping to a
> bundle agent on the open network with TCP convergence layer using NAT
> in the firewall.  The route on the closed network points to the TCP
> endpoint of the node on the open network.  The route on the open
> network points to the Firewall open network address (exposed address).
> We open the connection between closed-node and open-node using link
> open and DTNping from closed-node to open-node.  We then DTNping from
> open-node to closed node!  After thinking about this a bit, we believe
> the DTN TCP convergence layer maintains state in the NAT table once we
> do a link open command on the closed-node.  We now have a TCP hole in
> the firewall on a specific port that might be a place to exploit via
> TCP (and perhaps DTN).
>
> Thoughts?

I think this is not really a "DTN/IP vulnerability" but more like
"people who think firewalls give them strong security properties are
confused".

There are plenty of other things (ssh reverse port forwarding, IPsec
tunnel mode via NAT traversal, IP over DNS
(http://www.daemon.be/maarten/dnstunnel.html), AYIYA v6 tunnels, etc.)
that can cause the hoped-for security properties of firewalls not to
hold.  Plus of course taking a machine to an outside net and bringing it
back infested.

I wouldn't worry too much about the "TCP hole" part; this is no
different than any other TCP connection from in to out, and I usually
see the word "hole" applied to configurations where connections
initiated from outside are allowed.  Outgoing TCP happens all the time,
and the TCP protocol aspects don't seem particularly worrying (although
there certainly could be exploitable bugs in TCP stacks).  The usual
worry is that data will flow in the reverse direction and hit buggy
code.  While there are almost certainly exploitable bugs in DTN code and
DTN applications, I would expect things like IE to be much more
troublesome in practice.

A natural question is what do firewalls mean in a DTN context, and what
properties does one want?  If you consider the roving machine, sometimes
in, sometimes out, and let it carry bundles, you have the same problem
of bundles from outside appearing inside.  Absent being willing to
question the entire notion of firewalls, this leads to wanting a
BP-level firewall that enforces some policy (bundles in response to
outgoing bundles are ok?), and then realizing that it needs to be a
distributed system, running on every machine that goes outside, and
sharing state of outgoing bundles among every machine that might handle
an ingress bundle.  The other option is to expect every endpoint to run
a firewall, which is arguably more sensible than enclave-level
firewalls, but less amenable to centralized control.

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From: Hans Kruse <[email-masked]>
To: Michael Demmer <[email-masked]>
Date: Mon, 2 Nov 2009 18:27:06 -0500
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

--Apple-Mail-26--275648076
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

ION does the same for tcpcl.  For the light-weight stcpcl each nodes  
opens a TCP connection to the other one; the connections are  
unidirectional from the perspective of the bundle layer in that case  
(and there is a special relay for the NAT case).

On Nov 2, 2009, at 6:15 PM, Michael Demmer wrote:

> On Mon, Nov 2, 2009 at 3:09 PM, Lloyd Wood <[email-masked]>  
> wrote:
>>
>> On 2 Nov 2009, at 21:53, Kevin Fall wrote:
>>
>>> I guess my thought would be that depending on NAT for your  
>>> security is
>>> probably not advisable.  Given that TCP is by design a bi- 
>>> directional
>>> protocol, choosing it for the CL would, I think, naturally lead to
>>> behavior of this sort.
>>
>> Does the DTN reference implementation treat TCP as fully  
>> bidirectional,
>> or do two communicating peers both sending and receiving end up  
>> opening
>> two parallel TCP sessions between them?
>
> The DTN2 RI can use a single TCP connection for bidirectional bundle
> traffic, and so could send data into a NATd environment.
>
> -m
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-26--275648076
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">ION does the same for tcpcl. =
&nbsp;For the light-weight stcpcl each nodes opens a TCP connection to =
the other one; the connections are unidirectional from the perspective =
of the bundle layer in that case (and there is a special relay for the =
NAT case).<div><br><div><div>On Nov 2, 2009, at 6:15 PM, Michael Demmer =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>On Mon, Nov 2, 2009 at 3:09 PM, Lloyd Wood &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">On 2 Nov 2009, at 21:53, Kevin Fall =
wrote:<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">I guess my thought would be that depending on NAT for your =
security is<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">probably not advisable. =
&nbsp;Given that TCP is by design a =
bi-directional<br></blockquote></blockquote><blockquote =
type=3D"cite"><blockquote type=3D"cite">protocol, choosing it for the CL =
would, I think, naturally lead =
to<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote =
type=3D"cite">behavior of this =
sort.<br></blockquote></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Does the DTN =
reference implementation treat TCP as fully =
bidirectional,<br></blockquote><blockquote type=3D"cite">or do two =
communicating peers both sending and receiving end up =
opening<br></blockquote><blockquote type=3D"cite">two parallel TCP =
sessions between them?<br></blockquote><br>The DTN2 RI can use a single =
TCP connection for bidirectional bundle<br>traffic, and so could send =
data into a NATd =
environment.<br><br>-m<br><br>____________________________________________=
___<br>dtn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-26--275648076--

Sender: [email-masked]
From: Michael Demmer <[email-masked]>
Date: Mon, 2 Nov 2009 15:15:23 -0800
To: Lloyd Wood <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

On Mon, Nov 2, 2009 at 3:09 PM, Lloyd Wood <[email-masked]> wrote:
>
> On 2 Nov 2009, at 21:53, Kevin Fall wrote:
>
>> I guess my thought would be that depending on NAT for your security is
>> probably not advisable. �Given that TCP is by design a bi-directional
>> protocol, choosing it for the CL would, I think, naturally lead to
>> behavior of this sort.
>
> Does the DTN reference implementation treat TCP as fully bidirectional,
> or do two communicating peers both sending and receiving end up opening
> two parallel TCP sessions between them?

The DTN2 RI can use a single TCP connection for bidirectional bundle
traffic, and so could send data into a NATd environment.

-m

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Mon, 2 Nov 2009 23:09:06 +0000
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

On 2 Nov 2009, at 21:53, Kevin Fall wrote:

> I guess my thought would be that depending on NAT for your security is
> probably not advisable.  Given that TCP is by design a bi-directional
> protocol, choosing it for the CL would, I think, naturally lead to
> behavior of this sort.

Does the DTN reference implementation treat TCP as fully bidirectional,
or do two communicating peers both sending and receiving end up opening
two parallel TCP sessions between them?

> One could arrange an option to not receive
> incoming bundles, or to close down half the TCP connection.  Doing the
> later would certainly increase the challenge regarding e2e and custody
> ACKs.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Sender: Alex McMahon <[email-masked]>
From: Alex McMahon <[email-masked]>
To: Nick Fox <[email-masked]>
Organization: Trinity College Dublin
Date: Mon, 02 Nov 2009 14:53:53 -0800
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] [dtn-users] bundle expire malfunction??
Reply-To: [email-masked]

--=-kgzuzH0CEPIEn8btbfpN
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Nick,

I recreated your scene and got the same result and this is not the the
intended behaviour - once the bundle has expired it should not appear on
any more lists. Bundle expiration may occur at any point in the
processing of a bundle and when a bundle expires, the bundle protocol
agent must delete the bundle.  In the scene you presented all of the
bundle's retention constraints must be removed but as you have pointed
out are not. There is no way to control which lists a bundle is "queued
on" using the tcl interface.   

I was only able to recreate this bug using routing type flood when the
bundle is defered and expires.  Even though the bundle is expired
(manually or timed) a number of mappings remain on the list which can be
seen from the warning produced by the daemon 'expired bundle bundle id 0
[dtn://sphere.dtn -> dtn://nobody1.dtn 11 byte payload] still has 3
mappings (i.e. not just in ALL_BUNDLES)'

The code which expires the bundle  from 'BundleDaemon.cc' is shown
below. 

2114     if (event->type_ == BUNDLE_EXPIRED) {
2115         bundle = ((BundleExpiredEvent*)event)->bundleref_.object();
2116         size_t num_mappings = bundle->num_mappings();
2117         if (num_mappings != 1) {
2118             log_warn("expired bundle *%p still has %zu mappings (i.e. not just in ALL_BUNDLES)",
2119                      bundle.object(), num_mappings);

)

The reason seems to be that in the implementation of flood routing the
class maintains an internal BundleList 'all_bundles_', a separate list,
in which all bundles are kept until their expiration time. The intention
is to prevent the main daemon logic from opportunistically deleting
bundles when they've been transmitted to ensure bundles aren't deleted
by the system just after they are forwarded. However, this design
appears to be the cause of the bug the bundles are not being expired
from this list by the main daemon logic

Alex

On Mon, 2009-11-02 at 10:29 -0500, Nick Fox wrote:

> Alex: What you are describing is exactly what I expected to happen,
> however that is not what I am seeing happen.  Let me attempt to
> explain again more clearly.
> 
> I have a node N1 configured with flood routing, route discovery, and
> the parameter early bundle deletion = true (this is true by default).
> It contains two links in its routing table: link-0 to N2 and link-1 to
> N3.  The scenario begins with both links closed.  
> 
> With both links closed I send a bundle manually with dtnsend to a node
> that doesn't exist: "dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m
> -p "hello world". (the expiration timer is default so 3600 seconds)
> 
> At this point I run "bundle info 0" and see the bundle is queued on 5
> lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
> link-0:deferred, and link-1:deferred.
> 
> Now I open link-0.  The bundle is flooded to node N2. I close link-0
> again.  At this point both links are again unavailable.
> 
> I again run "bundle info 0".  Now i see the bundle is only queued on 4
> lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
> and link-1:deferred.  (this is what i expect since we just sent it to
> link-0)
> 
> Now the unexpected behavior.  I run "bundle expire 0".  Now when I run
> bundle list I see:
> 
>     All Bundles (1):
>                  0  : dtn://N1.dtn -> dtn://nobody.dtn length 11 (NOT
> PENDING)
> 
> I then run "bundle info 0".  This time I see the bundle is queued on 2
> lists: all_bundles and link-1:deferred.
> 
> The bundle will remain in the bundle list until the bundle is
> transmitted over link-1.  At that point, it will finally disappear
> from the bundle list.
> 
> Again, is the the intended behavior?  If so is there a way to control
> which lists a bundle is "queued on"?  Is anyone else experiencing the
> same situation I am?
> 
> Thanks in advance for your help/suggestions,
> 
> -Nick Fox
> 
> 
> 
> 
> On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon <[email-masked]>
> wrote:
> 
>         Expiring a bundle would simply remove it from the bundle list
>         immediately and delete the bundle.  I believe what you are
>         seeing is one of three registrations being deleted and not the
>         expiration of the bundle.  If the bundle expires ( you could
>         try manually expiring it with 'bundle expire <id>')before all
>         known nodes have been encountered, I expect the bundle would
>         disappear from the bundle list and is deleted.  
>         
>         
>         Alex
>         
>         1) no bundles / default registrations
>         sphere dtn% bundle list
>         All Bundles (0): 
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         2) Two bundles sent with expiration time of 10 seconds to EID
>         that does no exist. Bundles 8 & 9 and registrations 14 & 15
>         are visible  
>         
>         $ dtnping -c 1 -e 10 dtn://blahblah2/ping
>         source_eid [dtn://sphere.dtn/ping.1747]
>         dtn_register succeeded, regid 15
>         
>         
>         $ dtnping -c 1 -e 10 dtn://blahblah1/ping
>         source_eid [dtn://sphere.dtn/ping.1745]
>         dtn_register succeeded, regid 14
>         
>         
>         sphere dtn% bundle list
>         All Bundles (2): 
>         8  : dtn://sphere.dtn/ping.1745 -> dtn://blahblah1/ping length
>         20
>         9  : dtn://sphere.dtn/ping.1747 -> dtn://blahblah2/ping length
>         20
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration
>         0]
>         id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration
>         0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         
>         3) After 10 seconds as expected the registration expires and
>         bundle expires. Registrations 14 & 15 and bundles 8 & 9 are
>         gone from lists. A signal is given by the dtnping application
>         for both bundles.  
>         
>         PING [dtn://blahblah1/ping] (expiration 10)...
>         bundle deleted at [dtn://sphere.dtn] (lifetime expired):
>         seqno=0, time=10004 m
>         
>         PING [dtn://blahblah1/ping] (expiration 10)...
>         bundle deleted at [dtn://sphere.dtn] (lifetime expired):
>         seqno=0, time=10002 ms
>         
>         sphere dtn% bundle list
>         All Bundles (0): 
>         
>         sphere dtn% registration list
>         id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
>         id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>         
>         sphere dtn% route dump
>         Route table for flood router:
>         
>         destinatio source COS    next hop    fwd    route [custody
>         timeout]
>         endpoint i  eid   BNE    link/eid   action   prio [min   pct
>         max]
>         -----------------------------------------------------------------------------
>         
>         Class of Service (COS) bits:
>         B: Bulk  N: Normal  E: Expedited
>         
>         Links:
>         
>         
>         
>         On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:
>         
>         > I am using DTN2-2.6.0 and flooding routing.  I believe I am
>         > experiencing some odd behavior with the bundle expire
>         > command.
>         > 
>         > Here is my test scenario:
>         > 
>         > Nodes N1, N2, N3, and N4 all have entries in each others
>         > link lists.  Say N1 has a dtnsend command run on it while
>         > all links are closed which creates bundle B1.  If a bundle
>         > info command is run on B1, then it is "queued" of the
>         > following lists:all_bundles, pending_bundles,
>         > FloodBundleRouter::all_bundles, link-0:deferred,
>         > link-1:deferred, and link-2:deferred (link-0=N2, link-1=N3,
>         > link-2=N4).  Now if the link opens with N3, the bundle is
>         > flooded to N3 and a bundle expire command is run on the
>         > bundle on N1.  Here is the what I see on N1.  Bundle list
>         > status = NOT PENDING.  Now if bundle info is run on it, it
>         > is "queued" on the following lists:all_bundles,
>         > link-0:deferred, link-2:deferred.  If N1 now opens a link
>         > with N2 and/or N4, the bundle is still flooded to the node
>         > and it is removed from the corresponding link:deferred list.
>         > When all known nodes have been encountered, then the bundle
>         > finally disappears from the bundle list and is deleted.
>         > Note: if N1 were to open a link to a "new" node ex. N6, then
>         > the bundle would be flooded to N6 as well.
>         > 
>         > I am curious, is this the intended behavior of the bundle
>         > expire command? I was under the impression that expiring a
>         > bundle would simply remove it from the bundle list
>         > immediately and delete the bundle.  Also, if this is the
>         > intended behavior for bundle expire, is there a way to
>         > manually alter which lists a bundle is a part of?  
>         > 
>         > Thanks in advance for your comments/suggestions.
>         > 
>         > Nick Fox 
>         > 
>         > _______________________________________________
>         > dtn-users mailing list
>         > [email-masked]
>         > http://maillists.intel-research.net/mailman/listinfo/dtn-users
> 
> 

--=-kgzuzH0CEPIEn8btbfpN
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
  <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.26.0">
</HEAD>
<BODY>
Nick,<BR>
<BR>
I recreated your scene and got the same result and this is not the the inte=
nded behaviour - once the bundle has expired it should not appear on any mo=
re lists. Bundle expiration may occur at any point in the processing of a b=
undle and when a bundle expires, the bundle protocol agent must delete the =
bundle.&nbsp; In the scene you presented all of the bundle's retention cons=
traints must be removed but as you have pointed out are not. There is no wa=
y to control which lists a bundle is &quot;queued on&quot; using the tcl in=
terface.&nbsp;&nbsp; <BR>
<BR>
I was only able to recreate this bug using routing type flood when the bund=
le is defered and expires.&nbsp; Even though the bundle is expired (manuall=
y or timed) a number of mappings remain on the list which can be seen from =
the warning produced by the daemon 'expired bundle bundle id 0 [dtn://spher=
e.dtn -&gt; dtn://nobody1.dtn 11 byte payload] still has 3 mappings (i.e. n=
ot just in ALL_BUNDLES)'<BR>
<BR>
The code which expires the bundle&nbsp; from 'BundleDaemon.cc' is shown bel=
ow. <BR>
<BR>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2114">2114</A>     if (event-&gt;type_ =3D=
=3D BUNDLE_EXPIRED) {
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2115">2115</A>         bundle =3D ((Bundle=
ExpiredEvent*)event)-&gt;bundleref_.object();
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2116">2116</A>         size_t num_mappings=
 =3D bundle-&gt;num_mappings();
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2117">2117</A>         if (num_mappings !=
=3D 1) {
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2118">2118</A>             log_warn(&quot;=
expired bundle *%p still has %zu mappings (i.e. not just in ALL_BUNDLES)&qu=
ot;,
</PRE>
<PRE>
<A HREF=3D"http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2/file/75810bc10946/s=
ervlib/bundling/BundleDaemon.cc#l2119">2119</A>                      bundle=
.object(), num_mappings);
</PRE>
<BR>
<BR>
)<BR>
<BR>
The reason seems to be that in the implementation of flood routing the clas=
s maintains an internal BundleList 'all_bundles_', a separate list,&nbsp; i=
n which all bundles are kept until their expiration time. The intention&nbs=
p; is to prevent the main daemon logic from opportunistically deleting bund=
les when they've been transmitted to ensure bundles aren't deleted by the s=
ystem just after they are forwarded. However, this design appears to be the=
 cause of the bug the bundles are not being expired from this list by the m=
ain daemon logic<BR>
<BR>
<BR>
Alex<BR>
<BR>
<BR>
On Mon, 2009-11-02 at 10:29 -0500, Nick Fox wrote:<BR>
<BLOCKQUOTE TYPE=3DCITE>
    Alex: What you are describing is exactly what I expected to happen, how=
ever that is not what I am seeing happen.&nbsp; Let me attempt to explain a=
gain more clearly.<BR>
    <BR>
    I have a node N1 configured with flood routing, route discovery, and th=
e parameter early bundle deletion =3D true (this is true by default).&nbsp;=
 It contains two links in its routing table: link-0 to N2 and link-1 to N3.=
&nbsp; The scenario begins with both links closed.&nbsp; <BR>
    <BR>
    With both links closed I send a bundle manually with dtnsend to a node =
that doesn't exist: &quot;dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m =
-p &quot;hello world&quot;. (the expiration timer is default so 3600 second=
s)<BR>
    <BR>
    At this point I run &quot;bundle info 0&quot; and see the bundle is que=
ued on 5 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundle=
s, link-0:deferred, and link-1:deferred.<BR>
    <BR>
    Now I open link-0.&nbsp; The bundle is flooded to node N2. I close link=
-0 again.&nbsp; At this point both links are again unavailable.<BR>
    <BR>
    I again run &quot;bundle info 0&quot;.&nbsp; Now i see the bundle is on=
ly queued on 4 lists: all_bundles, pending_bundles, FloodBundleRouter::all_=
bundles, and link-1:deferred.&nbsp; (this is what i expect since we just se=
nt it to link-0)<BR>
    <BR>
    Now the unexpected behavior.&nbsp; I run &quot;bundle expire 0&quot;.&n=
bsp; Now when I run bundle list I see:<BR>
    <BR>
    &nbsp;&nbsp;&nbsp; All Bundles (1):<BR>
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp;&nbsp;=
 0&nbsp; : dtn://N1.dtn -&gt; dtn://nobody.dtn length 11 (NOT PENDING)<BR>
    <BR>
    I then run &quot;bundle info 0&quot;.&nbsp; This time I see the bundle =
is queued on 2 lists: all_bundles and link-1:deferred.<BR>
    <BR>
    The bundle will remain in the bundle list until the bundle is transmitt=
ed over link-1.&nbsp; At that point, it will finally disappear from the bun=
dle list.<BR>
    <BR>
    Again, is the the intended behavior?&nbsp; If so is there a way to cont=
rol which lists a bundle is &quot;queued on&quot;?&nbsp; Is anyone else exp=
eriencing the same situation I am?<BR>
    <BR>
    Thanks in advance for your help/suggestions,<BR>
    <BR>
    -Nick Fox<BR>
    <BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon &lt;<A HREF=3D"mailto:ale=
[email-masked]">[email-masked]</A>&gt; wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    <BLOCKQUOTE>
        Expiring a bundle would simply remove it from the bundle list immed=
iately and delete the bundle.&nbsp; I believe what you are seeing is one of=
 three registrations being deleted and not the expiration of the bundle.&nb=
sp; If the bundle expires ( you could try manually expiring it with 'bundle=
 expire &lt;id&gt;')before all known nodes have been encountered, I expect =
the bundle would disappear from the bundle list and is deleted.&nbsp; <BR>
        <BR>
        <BR>
        Alex<BR>
        <BR>
        <B>1) no bundles / default registrations</B><BR>
        sphere dtn% bundle list<BR>
        All Bundles (0): <BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <B>2) Two bundles sent with expiration time of 10 seconds to EID th=
at does no exist. Bundles 8 &amp; 9 and registrations 14 &amp; 15 are visib=
le&nbsp; </B><BR>
        <BR>
        <B>$ dtnping -c 1 -e 10 dtn://blahblah2/ping</B><BR>
        <B>source_eid [dtn://sphere.dtn/ping.1747]</B><BR>
        <B>dtn_register succeeded, regid 15</B><BR>
        <BR>
        <BR>
        <B>$ dtnping -c 1 -e 10 dtn://blahblah1/ping</B><BR>
        <B>source_eid [dtn://sphere.dtn/ping.1745]</B><BR>
        <B>dtn_register succeeded, regid 14</B><BR>
        <BR>
        <BR>
        sphere dtn% bundle list<BR>
        All Bundles (2): <BR>
        8&nbsp; : dtn://sphere.dtn/ping.1745 -&gt; dtn://blahblah1/ping len=
gth 20<BR>
        9&nbsp; : dtn://sphere.dtn/ping.1747 -&gt; dtn://blahblah2/ping len=
gth 20<BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]<BR>
        id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <BR>
        <B>3) After 10 seconds as expected the registration expires and bun=
dle expires. Registrations 14 &amp; 15 and bundles 8 &amp; 9 are gone from =
lists. A signal is given by the dtnping application for both bundles.&nbsp;=
 </B><BR>
        <BR>
        <B>PING [dtn://blahblah1/ping] (expiration 10)...</B><BR>
        <B>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=
=3D0, time=3D10004 m</B><BR>
        <BR>
        <B>PING [dtn://blahblah1/ping] (expiration 10)...</B><BR>
        <B>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=
=3D0, time=3D10002 ms</B><BR>
        <BR>
        sphere dtn% bundle list<BR>
        All Bundles (0): <BR>
        <BR>
        sphere dtn% registration list<BR>
        id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<BR>
        id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<BR>
        <BR>
        sphere dtn% route dump<BR>
        Route table for flood router:<BR>
        <BR>
        destinatio source COS&nbsp;&nbsp;&nbsp; next hop&nbsp;&nbsp;&nbsp; =
fwd&nbsp;&nbsp;&nbsp; route [custody timeout]<BR>
        endpoint i&nbsp; eid&nbsp;&nbsp; BNE&nbsp;&nbsp;&nbsp; link/eid&nbs=
p;&nbsp; action&nbsp;&nbsp; prio [min&nbsp;&nbsp; pct&nbsp;&nbsp; max]<BR>
        -------------------------------------------------------------------=
----------<BR>
        <BR>
        Class of Service (COS) bits:<BR>
        B: Bulk&nbsp; N: Normal&nbsp; E: Expedited<BR>
        <BR>
        Links:<BR>
        <BR>
        <BR>
        <BR>
        On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:<BR>
        <BLOCKQUOTE TYPE=3DCITE>
            I am using DTN2-2.6.0 and flooding routing.&nbsp; I believe I a=
m experiencing some odd behavior with the bundle expire command.<BR>
            <BR>
            Here is my test scenario:<BR>
            <BR>
            Nodes N1, N2, N3, and N4 all have entries in each others link l=
ists.&nbsp; Say N1 has a dtnsend command run on it while all links are clos=
ed which creates bundle B1.&nbsp; If a bundle info command is run on B1, th=
en it is &quot;queued&quot; of the following lists:all_bundles, pending_bun=
dles, FloodBundleRouter::all_bundles, link-0:deferred, link-1:deferred, and=
 link-2:deferred (link-0=3DN2, link-1=3DN3, link-2=3DN4).&nbsp; Now if the =
link opens with N3, the bundle is flooded to N3 and a bundle expire command=
 is run on the bundle on N1.&nbsp; Here is the what I see on N1.&nbsp; Bund=
le list status =3D NOT PENDING.&nbsp; Now if bundle info is run on it, it i=
s &quot;queued&quot; on the following lists:all_bundles, link-0:deferred, l=
ink-2:deferred.&nbsp; If N1 now opens a link with N2 and/or N4, the bundle =
is still flooded to the node and it is removed from the corresponding link:=
deferred list.&nbsp; When all known nodes have been encountered, then the b=
undle finally disappears from the bundle list and is deleted.&nbsp; Note: i=
f N1 were to open a link to a &quot;new&quot; node ex. N6, then the bundle =
would be flooded to N6 as well.<BR>
            <BR>
            I am curious, is this the intended behavior of the bundle expir=
e command? I was under the impression that expiring a bundle would simply r=
emove it from the bundle list immediately and delete the bundle.&nbsp; Also=
, if this is the intended behavior for bundle expire, is there a way to man=
ually alter which lists a bundle is a part of?&nbsp; <BR>
            <BR>
            Thanks in advance for your comments/suggestions.<BR>
            <BR>
            Nick Fox=20
<PRE>
_______________________________________________
dtn-users mailing list
<A HREF=3D"mailto:[email-masked]">dtn-users@maillis=
ts.intel-research.net</A>
<A HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users">=
http://maillists.intel-research.net/mailman/listinfo/dtn-users</A>
</PRE>
        </BLOCKQUOTE>
    </BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=3DCITE>
    <BR>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-kgzuzH0CEPIEn8btbfpN--

From: Kevin Fall <[email-masked]>
Date: Mon, 2 Nov 2009 13:53:07 -0800
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

I guess my thought would be that depending on NAT for your security is  
probably not advisable.  Given that TCP is by design a bi-directional  
protocol, choosing it for the CL would, I think, naturally lead to  
behavior of this sort.  One could arrange an option to not receive  
incoming bundles, or to close down half the TCP connection.  Doing the  
later would certainly increase the challenge regarding e2e and custody  
ACKs.

- K

On Nov 2, 2009, at Nov 210:48 AMPST, Ivancic, William D. (GRC-RHN0)  
wrote:

> At GRC we implemented a Bundle Agent behind a firewall hopping to a  
> bundle agent on the open network with TCP convergence layer using  
> NAT in the firewall.  The route on the closed network points to the  
> TCP endpoint of the node on the open network.  The route on the open  
> network points to the Firewall open network address (exposed  
> address).  We open the connection between closed-node and open-node  
> using link open and DTNping from closed-node to open-node.  We then  
> DTNping from open-node to closed node!  After thinking about this a  
> bit, we believe the DTN TCP convergence layer maintains state in the  
> NAT table once we do a link open command on the closed-node.  We now  
> have a TCP hole in the firewall on a specific port that might be a  
> place to exploit via TCP (and perhaps DTN).
>
> Thoughts?
>
> --Will
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>
Date: Mon, 2 Nov 2009 21:02:00 +0000
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that are....done?]

So if a name or other change to SDNVs was warranted, and I don't  
believe it is, this informational document would not be the place,  
rather errata would need to be raised against rfcs 5050 and 5325. So  
this is the wrong target for this comment.

Also, the "not unsigned" comment in this draft doesn't reflect  
philosophy but simply a way to avoid underflow attacks, so is not  
relevant to the discussion IMO.

Lastly, I would also rather avoid an angels on a pin discussion:-)

Maybe best would be if you crafted a short paragraph describing the  
issue you perceive, that Wes could think about including?

S.

On 2 Nov 2009, at 19:46, Elwyn Davies <[email-masked]> wrote:

> Burleigh, Scott C (313B) wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:dtn-
>>> [email-masked]] On Behalf Of Elwyn  
>>> Davies
>>> Sent: Monday, November 02, 2009 7:35 AM
>>> To: Stephen Farrell
>>> Cc: [email-masked]
>>> Subject: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs  
>>> that
>>> are....done?]
>>>
>>> Stephen Farrell wrote:
>>>
>>>> So, these are my opinions as a contributor, and not as
>>>> chair - as chair I'll just add up what everyone's said
>>>> and go from there. Comments on each are below.
>>>>
>>>> [yes] draft-irtf-dtnrg-sdnv
>>>>
>>>>
>>> [no] draft-irtf-dtnrg-sdnv
>>> Looking again at this document, there is an unfortunate mismatch  
>>> between
>>> the name of the concept (Self Delimiting NUMERIC Values) and the
>>> purposes for which it is suggested it can be used (s1.3). Several of
>>> these are NOT numbers at all - the SDN concept is useful for them  
>>> even
>>> so (especially Nonces, Cookies and similar cryptographic items).  
>>> Indeed
>>> the very first use of an SDNV in RFC 5050 is for the flags field (in
>>> s4.2 of RFC 5050).
>>>
>>
>> I sense the seeding of an email thread that will encourage many on  
>> this list to spend endless hours vigorously arguing fine points of  
>> semiotics and theoretical mathematics, without discernible benefit  
>> to anyone.  It is probably impossible to head that off, and  
>> unfortunately I have got to contribute to it in order to comment at  
>> all.  But I do want to at least try, as I really think this  
>> objection is highly unhelpful.
>>
>> The purposes you cite illustrate exactly why these things are  
>> termed "numeric values" rather than "numbers".  All of them are met  
>> by data values that are numeric in nature -- that is, the values  
>> can be written as sequences of numerals without ambiguity, and  
>> thence encoded in binary.
>>
> The original version of SDNV in
> http://www.watersprings.org/pub/id/draft-irtf-dtnrg-ltp-00.txt
> explicitly states that the value is an unsigned integer, but the  
> current
> version makes no statements about the semantics of the bit pattern  
> that
> is encoded. The current SDNV algorithm takes *any* arbitrary length  
> bit
> string and encodes it in a self-delimiting form.
>
> The semantics of the encoded/decoded bit string are defined by the
> protocol that uses the mechanism to put the bits on the wire.
>> This distinguishes them from self-delimiting alphanumeric values,  
>> such as NULL-terminated strings.  Strings are "alphanumeric values"  
>> rather than "words".  They can be written as sequences of Latin  
>> alphanumeric characters without ambiguity, but they can only be  
>> written as sequences of numerals (for encoding in binary) in the  
>> context of a defined representation convention such as ASCII.
>>
> Ultimately both forms serialize a bit string in a way that you can
> identify the end just by looking at the bits on the wire. SDNVs deal
> with bit strings that have no internal structure; if you have some
> internal pattern (such as a NULL octet on the end of a 'C string' and
> guaranteed no NULLs elsewhere) other ways are possible, but it would  
> not
> prevent you sending a string as an SDNV and you could skip the NULL
> octet, adding it back at the destination if the application needs it.
> Yes, this would probably be stupid and wasteful, but it is possible.  
> The
> current SDNV is a totally general purpose solution particularly  
> suitable
> for bit fields and numbers.
>
> Regards,
> Elwyn
>> So I disagree: there is no mismatch at all between the name of the  
>> concept and the purposes for which it is used.  The SDNV concept is  
>> very straightforward.  I don't think anybody is seriously confused  
>> by it.
>>
>>
>>> S3.1 explicitly talks about non-negative integers.. this could be
>>> considered as ruling out the bit pattern case although the actual
>>> algorithm does not depend on the interpretation of the bit pattern  
>>> as an
>>> integer or anything else. All that is needed are some conditional  
>>> words
>>> saying 'if you have a non-negative integer, represent it as a  
>>> binary bit
>>> pattern and then proceed as follows'.
>>>
>>> More tediously, should the name be changed?
>>>
>>
>> I can't think of any good reason for changing the name.
>>
>> Scott
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 02 Nov 2009 19:46:13 +0000
From: Elwyn Davies <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that are....done?]

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Elwyn Davies
>> Sent: Monday, November 02, 2009 7:35 AM
>> To: Stephen Farrell
>> Cc: [email-masked]
>> Subject: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that
>> are....done?]
>>
>> Stephen Farrell wrote:
>>     
>>> So, these are my opinions as a contributor, and not as
>>> chair - as chair I'll just add up what everyone's said
>>> and go from there. Comments on each are below.
>>>
>>> [yes] draft-irtf-dtnrg-sdnv
>>>
>>>       
>> [no] draft-irtf-dtnrg-sdnv
>> Looking again at this document, there is an unfortunate mismatch between
>> the name of the concept (Self Delimiting NUMERIC Values) and the
>> purposes for which it is suggested it can be used (s1.3). Several of
>> these are NOT numbers at all - the SDN concept is useful for them even
>> so (especially Nonces, Cookies and similar cryptographic items). Indeed
>> the very first use of an SDNV in RFC 5050 is for the flags field (in
>> s4.2 of RFC 5050).
>>     
>
> I sense the seeding of an email thread that will encourage many on this list to spend endless hours vigorously arguing fine points of semiotics and theoretical mathematics, without discernible benefit to anyone.  It is probably impossible to head that off, and unfortunately I have got to contribute to it in order to comment at all.  But I do want to at least try, as I really think this objection is highly unhelpful.
>
> The purposes you cite illustrate exactly why these things are termed "numeric values" rather than "numbers".  All of them are met by data values that are numeric in nature -- that is, the values can be written as sequences of numerals without ambiguity, and thence encoded in binary.
>   
The original version of SDNV in 
http://www.watersprings.org/pub/id/draft-irtf-dtnrg-ltp-00.txt 
explicitly states that the value is an unsigned integer, but the current 
version makes no statements about the semantics of the bit pattern that 
is encoded. The current SDNV algorithm takes *any* arbitrary length bit 
string and encodes it in a self-delimiting form.

The semantics of the encoded/decoded bit string are defined by the 
protocol that uses the mechanism to put the bits on the wire.
> This distinguishes them from self-delimiting alphanumeric values, such as NULL-terminated strings.  Strings are "alphanumeric values" rather than "words".  They can be written as sequences of Latin alphanumeric characters without ambiguity, but they can only be written as sequences of numerals (for encoding in binary) in the context of a defined representation convention such as ASCII.
>   
Ultimately both forms serialize a bit string in a way that you can 
identify the end just by looking at the bits on the wire. SDNVs deal 
with bit strings that have no internal structure; if you have some 
internal pattern (such as a NULL octet on the end of a 'C string' and 
guaranteed no NULLs elsewhere) other ways are possible, but it would not 
prevent you sending a string as an SDNV and you could skip the NULL 
octet, adding it back at the destination if the application needs it. 
Yes, this would probably be stupid and wasteful, but it is possible. The 
current SDNV is a totally general purpose solution particularly suitable 
for bit fields and numbers.

Regards,
Elwyn
> So I disagree: there is no mismatch at all between the name of the concept and the purposes for which it is used.  The SDNV concept is very straightforward.  I don't think anybody is seriously confused by it.
>
>   
>> S3.1 explicitly talks about non-negative integers.. this could be
>> considered as ruling out the bit pattern case although the actual
>> algorithm does not depend on the interpretation of the bit pattern as an
>> integer or anything else. All that is needed are some conditional words
>> saying 'if you have a non-negative integer, represent it as a binary bit
>> pattern and then proceed as follows'.
>>
>> More tediously, should the name be changed?
>>     
>
> I can't think of any good reason for changing the name.
>
> Scott
>   

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 2 Nov 2009 12:48:43 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] Potential DTN/IP Security Vulnerability regarding firewalls

At GRC we implemented a Bundle Agent behind a firewall hopping to a bundle agent on the open network with TCP convergence layer using NAT in the firewall.  The route on the closed network points to the TCP endpoint of the node on the open network.  The route on the open network points to the Firewall open network address (exposed address).  We open the connection between closed-node and open-node using link open and DTNping from closed-node to open-node.  We then DTNping from open-node to closed node!  After thinking about this a bit, we believe the DTN TCP convergence layer maintains state in the NAT table once we do a link open command on the closed-node.  We now have a TCP hole in the firewall on a specific port that might be a place to exploit via TCP (and perhaps DTN).

Thoughts?

--Will

Date: Mon, 2 Nov 2009 18:19:26 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] how many checksum ciphersuites? (was: Re: DTNRG docs that are....done?)

(Changing the subject since this may be more interesting than
document processing.)

Lloyd Wood wrote:
> Stephen Farrell wrote:
>> There are reasons to avoid MD5 (people auditing code have to do
>> work to justify its continuing presence) but in this case an MD5
>> based ciphersuite could be acceptable. However, I don't think it
>> offers significant benefit compared to a HMAC variant.
> 
> The key isn't needed for reliability; I'd be happier sans a key.

The hard-coded key? I think we can agree that that's an
insignificant difference.

>> But this is a more interesting topic. For security, algorithms only
>> get worse,
> 
> ...over time, as they're cracked...

Right.

>> so we need algorithm agility. In this case however, I don't
>> think that applies, assuming that the checksum algorithms are good
>> enough to start with, so if one ciphersuite were good enough, then
>> that'd be all that's needed.
> 
> It costs too much in CPU time (and resulting energy draw)
> to mandate the strongest reliability algorithm that is known for
> all bundle sizes. That also leads to a digest that is larger
> than the bundle that it is run across.

So I think that's a fair point, some checksums cost more in
CPU at runtime and are bigger. (There are truncated HMAC
variants that exist that handle the latter.)

>> I also don't buy the overkill argument, and if what you'd like
>> are all intermediate nodes verifying checksums on all bundles then
>> that implies that all generic nodes will need to implement all
>> checksum ciphersuites, which is costly, (in development terms) and
>> could affect interoperability and/or reliability (if some code only
>> does a subset).
> 
> No, it depends on bundle size. If the implementation is only dealing
> with small bundle sizes, then only CRC32c is needed. It never sees
> large bundles, the nodes probably can't even carry large bundles,
> it never needs to support checksumming methods for
> large bundles.

But aren't you arguing that all DTN nodes should verify the
checksum? In that case, the nodes in the "middle," that can see
any size bundles will need to implement all your ciphersuites
or you don't get your benefit. So by optimising for the node
that apparently can't run HMAC, you're requiring many other
implementations to do all checksums. I'd argue that that's not
the best optimisation.

The only argument I can see for more than one is the runtime
requirement. And I don't find that sufficiently convincing.
I'd be interested in other opinions.

> I do not expect interoperability between bundle implementations to
> be a requirement. 

We disagree there. I very much want interop to be the default.

S.

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 2 Nov 2009 17:55:58 +0000
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] DTNRG docs that are....done?

On 2 Nov 2009, at 11:48, Stephen Farrell wrote:
> > >- Three ciphersuites is still two too many. I'm not convinced that
>>> there are really different nodes/networks where subsets of these
>>> would be used.
>>
>> (since one of them uses MD5, is this part of your crusade to not use
>> MD5, even though MD5 is perfectly fine in a non-security context?)
>
> Is "crusade" a helpful phrase there?

No, as it's not that accurate. "Tilting at windmills" would be better.

> There are reasons to avoid MD5 (people auditing code have to do
> work to justify its continuing presence) but in this case an MD5
> based ciphersuite could be acceptable. However, I don't think it
> offers significant benefit compared to a HMAC variant.

The key isn't needed for reliability; I'd be happier sans a key.

>> It depends on how large your bundles are, which dictates which  
>> algorithm
>> is best suited to check those bundles, preserving CPU resources.  
>> It's an
>> engineering tradeoff. SHA on a 5K bundle is overkill. CRC32 is
>> well-suited to a 5K bundle, but across a bundle hundreds of  
>> megabytes in
>> size CRC32 does not offer an adequate guarantee that there are no  
>> errors
>> (and we have been sending, fragmenting and reassembling bundles of  
>> that
>> size, which differs from the 'a bundle is just a packet and will  
>> never
>> be larger than 64K' philosophy of others). One size does not fit all.
>>
>> This is mentioned in the draft - perhaps we simply need more  
>> commentary
>> there to explain it in more detail?
>
> No I don't think we need more commentary.
>
> But this is a more interesting topic. For security, algorithms only
> get worse,

...over time, as they're cracked...

> so we need algorithm agility. In this case however, I don't
> think that applies, assuming that the checksum algorithms are good
> enough to start with, so if one ciphersuite were good enough, then
> that'd be all that's needed.

It costs too much in CPU time (and resulting energy draw)
to mandate the strongest reliability algorithm that is known for
all bundle sizes. That also leads to a digest that is larger
than the bundle that it is run across.

> I also don't buy the overkill argument, and if what you'd like
> are all intermediate nodes verifying checksums on all bundles then
> that implies that all generic nodes will need to implement all
> checksum ciphersuites, which is costly, (in development terms) and
> could affect interoperability and/or reliability (if some code only
> does a subset).

No, it depends on bundle size. If the implementation is only dealing
with small bundle sizes, then only CRC32c is needed. It never sees
large bundles, the nodes probably can't even carry large bundles,
it never needs to support checksumming methods for
large bundles.

I do not expect interoperability between bundle implementations to
be a requirement. (And by 'implementation' I mean 'purpose-built
standalone bundle network').

What does a space probe have to say to a reindeer
herder? These are isolated networks with purpose-designed nodes.
The applications are separate, the networks are separate, the bundle
sizes and node designs fit the applications.

L.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Elwyn Davies <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Mon, 2 Nov 2009 08:16:47 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that	are....done?]

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Elwyn Davies
> Sent: Monday, November 02, 2009 7:35 AM
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that
> are....done?]
> 
> Stephen Farrell wrote:
> > So, these are my opinions as a contributor, and not as
> > chair - as chair I'll just add up what everyone's said
> > and go from there. Comments on each are below.
> >
> > [yes] draft-irtf-dtnrg-sdnv
> >
> [no] draft-irtf-dtnrg-sdnv
> Looking again at this document, there is an unfortunate mismatch between
> the name of the concept (Self Delimiting NUMERIC Values) and the
> purposes for which it is suggested it can be used (s1.3). Several of
> these are NOT numbers at all - the SDN concept is useful for them even
> so (especially Nonces, Cookies and similar cryptographic items). Indeed
> the very first use of an SDNV in RFC 5050 is for the flags field (in
> s4.2 of RFC 5050).

I sense the seeding of an email thread that will encourage many on this list to spend endless hours vigorously arguing fine points of semiotics and theoretical mathematics, without discernible benefit to anyone.  It is probably impossible to head that off, and unfortunately I have got to contribute to it in order to comment at all.  But I do want to at least try, as I really think this objection is highly unhelpful.

The purposes you cite illustrate exactly why these things are termed "numeric values" rather than "numbers".  All of them are met by data values that are numeric in nature -- that is, the values can be written as sequences of numerals without ambiguity, and thence encoded in binary.

This distinguishes them from self-delimiting alphanumeric values, such as NULL-terminated strings.  Strings are "alphanumeric values" rather than "words".  They can be written as sequences of Latin alphanumeric characters without ambiguity, but they can only be written as sequences of numerals (for encoding in binary) in the context of a defined representation convention such as ASCII.

So I disagree: there is no mismatch at all between the name of the concept and the purposes for which it is used.  The SDNV concept is very straightforward.  I don't think anybody is seriously confused by it.

> S3.1 explicitly talks about non-negative integers.. this could be
> considered as ruling out the bit pattern case although the actual
> algorithm does not depend on the interpretation of the bit pattern as an
> integer or anything else. All that is needed are some conditional words
> saying 'if you have a non-negative integer, represent it as a binary bit
> pattern and then proceed as follows'.
> 
> More tediously, should the name be changed?

I can't think of any good reason for changing the name.

Scott

Date: Mon, 02 Nov 2009 15:34:48 +0000
From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] SDNVs and bit patterns [was Re: DTNRG docs that are....done?]

Stephen Farrell wrote:
> So, these are my opinions as a contributor, and not as
> chair - as chair I'll just add up what everyone's said
> and go from there. Comments on each are below.
>
> [yes] draft-irtf-dtnrg-sdnv
>   
[no] draft-irtf-dtnrg-sdnv
Looking again at this document, there is an unfortunate mismatch between 
the name of the concept (Self Delimiting NUMERIC Values) and the 
purposes for which it is suggested it can be used (s1.3). Several of 
these are NOT numbers at all - the SDN concept is useful for them even 
so (especially Nonces, Cookies and similar cryptographic items). Indeed 
the very first use of an SDNV in RFC 5050 is for the flags field (in 
s4.2 of RFC 5050).

S3.1 explicitly talks about non-negative integers.. this could be 
considered as ruling out the bit pattern case although the actual 
algorithm does not depend on the interpretation of the bit pattern as an 
integer or anything else. All that is needed are some conditional words 
saying 'if you have a non-negative integer, represent it as a binary bit 
pattern and then proceed as follows'.

More tediously, should the name be changed?
One cunning fudge would be to use SDNV to stand for Self Delimiting 
Network Value.

Affected drafts (at least):
Neighbor Discovery
Bundle Checksum

Some drafts point back to RFC 5050
TCP Convergence Layer

I note that some drafts use SDNV without providing either an explicit 
definition or pointer back to RFC 5050 or this SDNV draft:
Previous Hop insertion block
Metadata Extension Block
Bundle-in-bundle block

I thought I had raised this issue earlier but the mail doesn't seem to 
have got through.

Regards,
Elwyn

Sender: [email-masked]
Date: Mon, 2 Nov 2009 10:29:04 -0500
From: Nick Fox <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] [dtn-users] bundle expire malfunction??

--00c09ffb4d2fb315a104776509d9
Content-Type: text/plain; charset=ISO-8859-1

Alex: What you are describing is exactly what I expected to happen, however
that is not what I am seeing happen.  Let me attempt to explain again more
clearly.

I have a node N1 configured with flood routing, route discovery, and the
parameter early bundle deletion = true (this is true by default).  It
contains two links in its routing table: link-0 to N2 and link-1 to N3.  The
scenario begins with both links closed.

With both links closed I send a bundle manually with dtnsend to a node that
doesn't exist: "dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -t m -p "hello
world". (the expiration timer is default so 3600 seconds)

At this point I run "bundle info 0" and see the bundle is queued on 5 lists:
all_bundles, pending_bundles, FloodBundleRouter::all_bundles,
link-0:deferred, and link-1:deferred.

Now I open link-0.  The bundle is flooded to node N2. I close link-0 again.
At this point both links are again unavailable.

I again run "bundle info 0".  Now i see the bundle is only queued on 4
lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundles, and
link-1:deferred.  (this is what i expect since we just sent it to link-0)

Now the unexpected behavior.  I run "bundle expire 0".  Now when I run
bundle list I see:

    All Bundles (1):
                 0  : dtn://N1.dtn -> dtn://nobody.dtn length 11 (NOT
PENDING)

I then run "bundle info 0".  This time I see the bundle is queued on 2
lists: all_bundles and link-1:deferred.

The bundle will remain in the bundle list until the bundle is transmitted
over link-1.  At that point, it will finally disappear from the bundle list.

Again, is the the intended behavior?  If so is there a way to control which
lists a bundle is "queued on"?  Is anyone else experiencing the same
situation I am?

Thanks in advance for your help/suggestions,

-Nick Fox

On Fri, Oct 30, 2009 at 5:30 PM, Alex McMahon <[email-masked]>wrote:

>  Expiring a bundle would simply remove it from the bundle list immediately
> and delete the bundle.  I believe what you are seeing is one of three
> registrations being deleted and not the expiration of the bundle.  If the
> bundle expires ( you could try manually expiring it with 'bundle expire
> <id>')before all known nodes have been encountered, I expect the bundle
> would disappear from the bundle list and is deleted.
>
>
> Alex
>
> *1) no bundles / default registrations*
> sphere dtn% bundle list
> All Bundles (0):
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
> *2) Two bundles sent with expiration time of 10 seconds to EID that does
> no exist. Bundles 8 & 9 and registrations 14 & 15 are visible  *
>
> *$ dtnping -c 1 -e 10 dtn://blahblah2/ping*
> *source_eid [dtn://sphere.dtn/ping.1747]*
> *dtn_register succeeded, regid 15*
>
>
> *$ dtnping -c 1 -e 10 dtn://blahblah1/ping*
> *source_eid [dtn://sphere.dtn/ping.1745]*
> *dtn_register succeeded, regid 14*
>
>
> sphere dtn% bundle list
> All Bundles (2):
> 8  : dtn://sphere.dtn/ping.1745 -> dtn://blahblah1/ping length 20
> 9  : dtn://sphere.dtn/ping.1747 -> dtn://blahblah2/ping length 20
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
> id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]
> id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
>
> *3) After 10 seconds as expected the registration expires and bundle
> expires. Registrations 14 & 15 and bundles 8 & 9 are gone from lists. A
> signal is given by the dtnping application for both bundles.  *
>
> *PING [dtn://blahblah1/ping] (expiration 10)...*
> *bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=0,
> time=10004 m*
>
> *PING [dtn://blahblah1/ping] (expiration 10)...*
> *bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=0,
> time=10002 ms*
>
> sphere dtn% bundle list
> All Bundles (0):
>
> sphere dtn% registration list
> id 0: active dtn://sphere.dtn (DEFER) [expiration 0]
> id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]
>
> sphere dtn% route dump
> Route table for flood router:
>
> destinatio source COS    next hop    fwd    route [custody timeout]
> endpoint i  eid   BNE    link/eid   action   prio [min   pct   max]
>
> -----------------------------------------------------------------------------
>
> Class of Service (COS) bits:
> B: Bulk  N: Normal  E: Expedited
>
> Links:
>
>
>
> On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:
>
> I am using DTN2-2.6.0 and flooding routing.  I believe I am experiencing
> some odd behavior with the bundle expire command.
>
> Here is my test scenario:
>
> Nodes N1, N2, N3, and N4 all have entries in each others link lists.  Say
> N1 has a dtnsend command run on it while all links are closed which creates
> bundle B1.  If a bundle info command is run on B1, then it is "queued" of
> the following lists:all_bundles, pending_bundles,
> FloodBundleRouter::all_bundles, link-0:deferred, link-1:deferred, and
> link-2:deferred (link-0=N2, link-1=N3, link-2=N4).  Now if the link opens
> with N3, the bundle is flooded to N3 and a bundle expire command is run on
> the bundle on N1.  Here is the what I see on N1.  Bundle list status = NOT
> PENDING.  Now if bundle info is run on it, it is "queued" on the following
> lists:all_bundles, link-0:deferred, link-2:deferred.  If N1 now opens a link
> with N2 and/or N4, the bundle is still flooded to the node and it is removed
> from the corresponding link:deferred list.  When all known nodes have been
> encountered, then the bundle finally disappears from the bundle list and is
> deleted.  Note: if N1 were to open a link to a "new" node ex. N6, then the
> bundle would be flooded to N6 as well.
>
> I am curious, is this the intended behavior of the bundle expire command? I
> was under the impression that expiring a bundle would simply remove it from
> the bundle list immediately and delete the bundle.  Also, if this is the
> intended behavior for bundle expire, is there a way to manually alter which
> lists a bundle is a part of?
>
> Thanks in advance for your comments/suggestions.
>
> Nick Fox
>
> _______________________________________________
> dtn-users mailing [email-masked]://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>

--00c09ffb4d2fb315a104776509d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alex: What you are describing is exactly what I expected to happen, however=
 that is not what I am seeing happen.=A0 Let me attempt to explain again mo=
re clearly.<br><br>I have a node N1 configured with flood routing, route di=
scovery, and the parameter early bundle deletion =3D true (this is true by =
default).=A0 It contains two links in its routing table: link-0 to N2 and l=
ink-1 to N3.=A0 The scenario begins with both links closed.=A0 <br>
<br>With both links closed I send a bundle manually with dtnsend to a node =
that doesn&#39;t exist: &quot;dtnsend -s dtn://N1.dtn -d dtn://nobody.dtn -=
t m -p &quot;hello world&quot;. (the expiration timer is default so 3600 se=
conds)<br>
<br>At this point I run &quot;bundle info 0&quot; and see the bundle is que=
ued on 5 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bundle=
s, link-0:deferred, and link-1:deferred.<br><br>Now I open link-0.=A0 The b=
undle is flooded to node N2. I close link-0 again.=A0 At this point both li=
nks are again unavailable.<br>
<br>I again run &quot;bundle info 0&quot;.=A0 Now i see the bundle is only =
queued on 4 lists: all_bundles, pending_bundles, FloodBundleRouter::all_bun=
dles, and link-1:deferred.=A0 (this is what i expect since we just sent it =
to link-0)<br>
<br>Now the unexpected behavior.=A0 I run &quot;bundle expire 0&quot;.=A0 N=
ow when I run bundle list I see:<br><br>=A0=A0=A0 All Bundles (1):<br>=A0=
=A0=A0 =A0=A0 =A0 =A0  =A0=A0  =A0=A0 0=A0 : dtn://N1.dtn -&gt; dtn://nobod=
y.dtn length 11 (NOT PENDING)<br>
<br>I then run &quot;bundle info 0&quot;.=A0 This time I see the bundle is =
queued on 2 lists: all_bundles and link-1:deferred.<br><br>The bundle will =
remain in the bundle list until the bundle is transmitted over link-1.=A0 A=
t that point, it will finally disappear from the bundle list.<br>
<br>Again, is the the intended behavior?=A0 If so is there a way to control=
 which lists a bundle is &quot;queued on&quot;?=A0 Is anyone else experienc=
ing the same situation I am?<br><br>Thanks in advance for your help/suggest=
ions,<br>
<br>-Nick Fox<br><br><br><br><div class=3D"gmail_quote">On Fri, Oct 30, 200=
9 at 5:30 PM, Alex McMahon <span dir=3D"ltr">&lt;<a href=3D"mailto:alex.mcm=
[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

 =20
 =20

<div>
Expiring a bundle would simply remove it from the bundle list immediately a=
nd delete the bundle.=A0 I believe what you are seeing is one of three regi=
strations being deleted and not the expiration of the bundle.=A0 If the bun=
dle expires ( you could try manually expiring it with &#39;bundle expire &l=
t;id&gt;&#39;)before all known nodes have been encountered, I expect the bu=
ndle would disappear from the bundle list and is deleted.=A0 <br>

<br>
<br>
Alex<br>
<br>
<b>1) no bundles / default registrations</b><br>
sphere dtn% bundle list<br>
All Bundles (0): <br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<b>2) Two bundles sent with expiration time of 10 seconds to EID that does =
no exist. Bundles 8 &amp; 9 and registrations 14 &amp; 15 are visible=A0 </=
b><br>
<br>
<b>$ dtnping -c 1 -e 10 dtn://blahblah2/ping</b><br>
<b>source_eid [dtn://sphere.dtn/ping.1747]</b><br>
<b>dtn_register succeeded, regid 15</b><br>
<br>
<br>
<b>$ dtnping -c 1 -e 10 dtn://blahblah1/ping</b><br>
<b>source_eid [dtn://sphere.dtn/ping.1745]</b><br>
<b>dtn_register succeeded, regid 14</b><br>
<br>
<br>
sphere dtn% bundle list<br>
All Bundles (2): <br>
	8=A0 : dtn://sphere.dtn/ping.1745 -&gt; dtn://blahblah1/ping length 20<br>
	9=A0 : dtn://sphere.dtn/ping.1747 -&gt; dtn://blahblah2/ping length 20<br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
id 14: active dtn://sphere.dtn/ping.1745 (DEFER) [expiration 0]<br>
id 15: active dtn://sphere.dtn/ping.1747 (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<br>
<b>3) After 10 seconds as expected the registration expires and bundle expi=
res. Registrations 14 &amp; 15 and bundles 8 &amp; 9 are gone from lists. A=
 signal is given by the dtnping application for both bundles.=A0 </b><br>

<br>
<b>PING [dtn://blahblah1/ping] (expiration 10)...</b><br>
<b>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time=
=3D10004 m</b><br>
<br>
<b>PING [dtn://blahblah1/ping] (expiration 10)...</b><br>
<b>bundle deleted at [dtn://sphere.dtn] (lifetime expired): seqno=3D0, time=
=3D10002 ms</b><br>
<br>
sphere dtn% bundle list<br>
All Bundles (0): <br>
<br>
sphere dtn% registration list<br>
id 0: active dtn://sphere.dtn (DEFER) [expiration 0]<br>
id 2: active dtn://sphere.dtn/ping (DEFER) [expiration 0]<br>
<br>
sphere dtn% route dump<br>
Route table for flood router:<br>
<br>
destinatio source COS=A0=A0=A0 next hop=A0=A0=A0 fwd=A0=A0=A0 route [custod=
y timeout]<br>
endpoint i=A0 eid=A0=A0 BNE=A0=A0=A0 link/eid=A0=A0 action=A0=A0 prio [min=
=A0=A0 pct=A0=A0 max]<br>
---------------------------------------------------------------------------=
--<br>
<br>
Class of Service (COS) bits:<br>
	B: Bulk=A0 N: Normal=A0 E: Expedited<br>
<br>
Links:<br>
<br>
<br>
<br>
On Wed, 2009-09-30 at 14:44 -0400, Nick Fox wrote:<br>
<blockquote type=3D"CITE">
    I am using DTN2-2.6.0 and flooding routing.=A0 I believe I am experienc=
ing some odd behavior with the bundle expire command.<br>
    <br>
    Here is my test scenario:<br>
    <br>
    Nodes N1, N2, N3, and N4 all have entries in each others link lists.=A0=
 Say N1 has a dtnsend command run on it while all links are closed which cr=
eates bundle B1.=A0 If a bundle info command is run on B1, then it is &quot=
;queued&quot; of the following lists:all_bundles, pending_bundles, FloodBun=
dleRouter::all_bundles, link-0:deferred, link-1:deferred, and link-2:deferr=
ed (link-0=3DN2, link-1=3DN3, link-2=3DN4).=A0 Now if the link opens with N=
3, the bundle is flooded to N3 and a bundle expire command is run on the bu=
ndle on N1.=A0 Here is the what I see on N1.=A0 Bundle list status =3D NOT =
PENDING.=A0 Now if bundle info is run on it, it is &quot;queued&quot; on th=
e following lists:all_bundles, link-0:deferred, link-2:deferred.=A0 If N1 n=
ow opens a link with N2 and/or N4, the bundle is still flooded to the node =
and it is removed from the corresponding link:deferred list.=A0 When all kn=
own nodes have been encountered, then the bundle finally disappears from th=
e bundle list and is deleted.=A0 Note: if N1 were to open a link to a &quot=
;new&quot; node ex. N6, then the bundle would be flooded to N6 as well.<br>

    <br>
    I am curious, is this the intended behavior of the bundle expire comman=
d? I was under the impression that expiring a bundle would simply remove it=
 from the bundle list immediately and delete the bundle.=A0 Also, if this i=
s the intended behavior for bundle expire, is there a way to manually alter=
 which lists a bundle is a part of?=A0 <br>

    <br>
    Thanks in advance for your comments/suggestions.<br>
    <br>
    Nick Fox
<pre>_______________________________________________
dtn-users mailing list
<a href=3D"mailto:[email-masked]" target=3D"_blank"=
>[email-masked]</a>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-users" =
target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-=
users</a>
</pre>
</blockquote>
</div>

</blockquote></div><br>

--00c09ffb4d2fb315a104776509d9--

From: Peter Lovell <[email-masked]>
To: Anders Lindgren <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Mon, 02 Nov 2009 09:33:46 -0500
Cc: [email-masked]
Subject: [dtn-interest] Re(2):  DTNRG docs that are....done?

On Mon, Nov 2, 2009, Anders Lindgren <[email-masked]> wrote:

>it's obviously too late to get it submitted properly
>before the meeting

Actually, you can submit again starting Monday morning (probably that's
Monday evening Japan-time)

Cheers.....Peter

Date: Mon, 2 Nov 2009 15:07:37 +0100
From: Anders Lindgren <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

--001636ed677c68ea5e047763e648
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the comments.
As the current draft is expired, I'll make sure to produce a new version
with the comments below addressed and send it out to the list before the
Hiroshima meeting (it's obviously too late to get it submitted properly
before the meeting, but I'll take care of that after the meeting).

/Anders

On Sun, Nov 1, 2009 at 6:41 PM, Stephen Farrell
<[email-masked]>wrote:

>
> Finishing my reading:
>
> [yes] draft-irtf-dtnrg-prophet
>
> Stephen.
>
> - p6: s/In this draft/In this specification/
> - p6: expand EID on first use
> - p7: s/protocoll/protocol/
> - p13: "Instance numbers" forward reference - be nicer if that
>  could be omitted
> - p16: s/Tead/T_aed/ & expand TTL on 1st use
> - p18: says that nodes SHOULD forward bundles when in direct contact
>  with the bundle destination - why is that not a MUST? Can't think
>  of any reason myself.
> - p21: s/there need/there needs/
> - p22: section 4.1 could be deleted since it says nothing
> - p24, "Hello SYN" etc are used without having been introduced
>  (same for RSTACK)
> - p31: I don't understand the description of the flags are
>  all bit reserved? what does "0b1" signify? Giving some examples
>  of P-value encoding would be good - its something coders could
>  get wrong easily
> - p34: Why isn't ESTAB a state listed in 5.1? (or SYNSENT or the
>  others)
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--001636ed677c68ea5e047763e648
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the comments.<br>As the current draft is expired, I&#39;ll make =
sure to produce a new version with the comments below addressed and send it=
 out to the list before the Hiroshima meeting (it&#39;s obviously too late =
to get it submitted properly before the meeting, but I&#39;ll take care of =
that after the meeting).<br>
<br>/Anders<br><br><div class=3D"gmail_quote">On Sun, Nov 1, 2009 at 6:41 P=
M, Stephen Farrell <span dir=3D"ltr">&lt;<a href=3D"mailto:stephen.farrell@=
cs.tcd.ie">[email-masked]</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); ma=
rgin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Finishing my reading:<br>
<div class=3D"im"><br>
[yes] draft-irtf-dtnrg-prophet<br>
<br>
</div>Stephen.<br>
<br>
- p6: s/In this draft/In this specification/<br>
- p6: expand EID on first use<br>
- p7: s/protocoll/protocol/<br>
- p13: &quot;Instance numbers&quot; forward reference - be nicer if that<br=
>
 =A0could be omitted<br>
- p16: s/Tead/T_aed/ &amp; expand TTL on 1st use<br>
- p18: says that nodes SHOULD forward bundles when in direct contact<br>
 =A0with the bundle destination - why is that not a MUST? Can&#39;t think<b=
r>
 =A0of any reason myself.<br>
- p21: s/there need/there needs/<br>
- p22: section 4.1 could be deleted since it says nothing<br>
- p24, &quot;Hello SYN&quot; etc are used without having been introduced<br=
>
 =A0(same for RSTACK)<br>
- p31: I don&#39;t understand the description of the flags are<br>
 =A0all bit reserved? what does &quot;0b1&quot; signify? Giving some exampl=
es<br>
 =A0of P-value encoding would be good - its something coders could<br>
 =A0get wrong easily<br>
- p34: Why isn&#39;t ESTAB a state listed in 5.1? (or SYNSENT or the<br>
 =A0others)<br>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t" target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/d=
tn-interest</a><br>
</div></div></blockquote></div><br>

--001636ed677c68ea5e047763e648--

From: Peter Lovell <[email-masked]>
To: Stephen Farrell <[email-masked]>, [email-masked]
Date: Mon, 02 Nov 2009 08:41:45 -0500
Subject: [dtn-interest] Re(2):  DTNRG docs that are....done?

Hi Stephen,

On Fri, Oct 30, 2009, Stephen Farrell <[email-masked]> wrote:

>draft-irtf-dtnrg-bundle-security
>
>(I only looked at the diff from -08 so really need to give
>this a thorough read again.)
>- general: "STRONGLY RECOMMENDED" isn't in rfc 2119 is it?

No it's not. I thought that I had fixed all of those but obviously (at
least) went by. I'll check again and revise. I did manage to get the
updated boilerplate that I think is appropriate for us.

>- p5: should we delete the reference to the security overview
>  or are we ok that this waits on that document?

My recollection from March is that we thought that it was OK to say as-
is, but not wait on the overview document. But I don't have any leanings
either way. I'm happy to remove it if we think it's  inappropriate.

Thanks.....Peter

Date: Mon, 2 Nov 2009 11:48:29 +0000
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

Lloyd Wood wrote:
> On 1 Nov 2009, at 18:45, Stephen Farrell wrote:
>> [email-masked] wrote:
>>> draft-irtf-dtnrg-bundle-checksum
>>>
>>> yes
>>
>> Disagree. I just re-read that and lots of at least my comments
>> (sent to the list March 16th) still need addressing (though
>> it has improved some).
>>
>> Summarising those:
>>
>> - The draft still has too much commentary that is inappropriate in
>>  a protocol specification.
> 
> Specifying the 'why' as well as the 'how' is important in an
> experimental research document. The 'why' here is particularly
> important, as it provides a necessary grounding in the area for those
> unfamiliar with reliability and checksums who might otherwise dismiss
> the work out of hand, or would design protocols that don't consider
> reliability.

I agree with that, and if that was all that was in the draft, I'd
be fine with it (and this version is certainly better than previous
ones), however phrases like "redress this lack of robustness in
the existing Bundle Protocol," "heavyweight security protocols,"
"While impressively named..." remain, are disputed, or read to me
as sarcastic, and do not help anyone that I can see. There's also
a *lot* of text about why this isn't security relevant, which should
only IMO require one sentence. The main point of the draft should
not be to critique what you don't like, but to define ciphersuites
so people can write code that will interoperate, and presumably,
if the arguments presented are correct, lead to more robust DTNs.

If you, Wes or Will are going to be in Hiroshima, I'd be happy to
go through it with you in detail, or we could setup a concall
afterwards if that helps. I think that'd be quicker than
thrashing it all on the list.

>> - Three ciphersuites is still two too many. I'm not convinced that
>>  there are really different nodes/networks where subsets of these
>>  would be used.
> 
> (since one of them uses MD5, is this part of your crusade to not use
> MD5, even though MD5 is perfectly fine in a non-security context?)

Is "crusade" a helpful phrase there?

There are reasons to avoid MD5 (people auditing code have to do
work to justify its continuing presence) but in this case an MD5
based ciphersuite could be acceptable. However, I don't think it
offers significant benefit compared to a HMAC variant.

> It depends on how large your bundles are, which dictates which algorithm
> is best suited to check those bundles, preserving CPU resources. It's an
> engineering tradeoff. SHA on a 5K bundle is overkill. CRC32 is
> well-suited to a 5K bundle, but across a bundle hundreds of megabytes in
> size CRC32 does not offer an adequate guarantee that there are no errors
> (and we have been sending, fragmenting and reassembling bundles of that
> size, which differs from the 'a bundle is just a packet and will never
> be larger than 64K' philosophy of others). One size does not fit all.
> 
> This is mentioned in the draft - perhaps we simply need more commentary
> there to explain it in more detail?

No I don't think we need more commentary.

But this is a more interesting topic. For security, algorithms only
get worse, so we need algorithm agility. In this case however, I don't
think that applies, assuming that the checksum algorithms are good
enough to start with, so if one ciphersuite were good enough, then
that'd be all that's needed.

I also don't buy the overkill argument, and if what you'd like
are all intermediate nodes verifying checksums on all bundles then
that implies that all generic nodes will need to implement all
checksum ciphersuites, which is costly, (in development terms) and
could affect interoperability and/or reliability (if some code only
does a subset).

To me that argues for defining one mandatory to implement
ciphersuite for implementations of this spec, with the others
either dropped or else optional to implement, and I think I
prefer dropping them on the basis that simplicity is better.

Speaking of implementations, do we know of any? It might be
useful input into this discussion.

Stephen.

> 
> 
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 2 Nov 2009 09:15:03 +0000
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] DTNRG docs that are....done?

On 1 Nov 2009, at 18:45, Stephen Farrell wrote:
> [email-masked] wrote:
>> draft-irtf-dtnrg-bundle-checksum
>>
>> yes
>
> Disagree. I just re-read that and lots of at least my comments
> (sent to the list March 16th) still need addressing (though
> it has improved some).
>
> Summarising those:
>
> - The draft still has too much commentary that is inappropriate in
>  a protocol specification.

Specifying the 'why' as well as the 'how' is important in an  
experimental research document. The 'why' here is particularly  
important, as it provides a necessary grounding in the area for those  
unfamiliar with reliability and checksums who might otherwise dismiss  
the work out of hand, or would design protocols that don't consider  
reliability.

> - Three ciphersuites is still two too many. I'm not convinced that
>  there are really different nodes/networks where subsets of these
>  would be used.

(since one of them uses MD5, is this part of your crusade to not use  
MD5, even though MD5 is perfectly fine in a non-security context?)

It depends on how large your bundles are, which dictates which  
algorithm is best suited to check those bundles, preserving CPU  
resources. It's an engineering tradeoff. SHA on a 5K bundle is  
overkill. CRC32 is well-suited to a 5K bundle, but across a bundle  
hundreds of megabytes in size CRC32 does not offer an adequate  
guarantee that there are no errors (and we have been sending,  
fragmenting and reassembling bundles of that size, which differs from  
the 'a bundle is just a packet and will never be larger than 64K'  
philosophy of others). One size does not fit all.

This is mentioned in the draft - perhaps we simply need more  
commentary there to explain it in more detail?

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Oyake, Amalaye (316D)" <[email-masked]>
To: dtn-interest <[email-masked]>
Date: Sun, 1 Nov 2009 21:37:17 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] 40 Years Later, Looking Back At The Internet's Birth

--_000_C713B009823DAmalayeOyakejplnasagov_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This story was on the radio today ... Very worthwhile for me:

http://www.npr.org/templates/story/story.php?storyId=3D114376728

Forty years ago this past week, a message was sent across ARPANET, the comp=
uter network developed by the Defense Department's Advanced Projects Agency=
. Many people consider that the day the Internet was born. For our series "=
The Net at 40," Guy Raz profiles the people who worked to make that transmi=
ssion happen, as well as the two university lab students who sent the first=
 message. Their goal? Type the simple word "login."

* Amalaye Oyake                                    *
* Flight Software Applications & Data Product Mgmt */\
* 818.393.7168 work   626.399.1707 cell            *||
* Jet Propulsion Laboratory, Pasadena  CA 91109   */||\
--

--_000_C713B009823DAmalayeOyakejplnasagov_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>40 Years Later, Looking Back At The Internet's Birth</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Inconsolata"><SPAN STYLE=3D'font-size:12pt'>This story was on=
 the radio today ... Very worthwhile for me:<BR>
<BR>
<a href=3D"http://www.npr.org/templates/story/story.php?storyId=3D114376728=
">http://www.npr.org/templates/story/story.php?storyId=3D114376728</a><BR>
<BR>
<I>Forty years ago this past week, a message was sent across ARPANET, the c=
omputer network developed by the Defense Department's Advanced Projects Age=
ncy. Many people consider that the day the Internet was born. For our serie=
s &quot;The Net at 40,&quot; Guy Raz profiles the people who worked to make=
 that transmission happen, as well as the two university lab students who s=
ent the first message. Their goal? Type the simple word &quot;login.&quot;<=
BR>
</I><BR>
<BR>
<BR>
* Amalaye Oyake &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;*<BR>
* Flight Software Applications &amp; Data Product Mgmt */\<BR>
* 818.393.7168 work &nbsp;&nbsp;626.399.1707 cell &nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*||<BR>
* Jet Propulsion Laboratory, Pasadena &nbsp;CA 91109 &nbsp;&nbsp;*/||\<BR>
-- <BR>
</SPAN></FONT>
</BODY>
</HTML>

--_000_C713B009823DAmalayeOyakejplnasagov_--

Date: Mon, 2 Nov 2009 10:26:48 +0800 (CST)
From: "Zhongtian Jia" <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] DTNRG docs that are....done?

------=_Part_116642_7036755.1257128808669
Content-Type: text/plain; charset=gbk
Content-Transfer-Encoding: base64

PiBbZHVubm9dIGRyYWZ0LWlydGYtZHRucmctc2Rudgo+IFtkdW5ub10gZHJhZnQtaXJ0Zi1kdG5y
Zy1idW5kbGUtcHJldmlvdXMtaG9wLWJsb2NrCj4gW2R1bm5vXSBkcmFmdC1pcnRmLWR0bnJnLWJ1
bmRsZS1tZXRhZGF0YS1ibG9jawo+IFtkdW5ub10gZHJhZnQtaXJ0Zi1kdG5yZy1idW5kbGUtcmV0
cmFucy1ibG9jawo+IFtkdW5ub10gZHJhZnQtaXJ0Zi1kdG5yZy1jYmhlCj4gW3llc10gZHJhZnQt
aXJ0Zi1kdG5yZy1idW5kbGUtc2VjdXJpdHkKPiBbZHVubm9dIGRyYWZ0LWlydGYtZHRucmctcHJv
cGhldAoKLS0KCkJlc3QgUmVnYXJkcywKWmhvbmd0aWFuIEppYQ==
------=_Part_116642_7036755.1257128808669
Content-Type: text/html; charset=gbk
Content-Transfer-Encoding: base64

------=_Part_116642_7036755.1257128808669--

Date: Sun, 01 Nov 2009 18:45:25 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

[email-masked] wrote:
> draft-irtf-dtnrg-bundle-checksum
> 
> yes

Disagree. I just re-read that and lots of at least my comments
(sent to the list March 16th) still need addressing (though
it has improved some).

Summarising those:

- The draft still has too much commentary that is inappropriate in
  a protocol specification.
- Three ciphersuites is still two too many. I'm not convinced that
  there are really different nodes/networks where subsets of these
  would be used.

S.

Date: Sun, 1 Nov 2009 13:01:09 -0500
From: Rajesh Krishnan <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

 - p18: says that nodes SHOULD forward bundles when in direct contact
>  with the bundle destination - why is that not a MUST? Can't think
>  of any reason myself.

Suppose: (i) bundles co-exist with other PDUs and BPAs coordinate with
other traffic generators on priority; (ii) the destination's storage
is overflowing, and that becomes known to the relay (say through a
management protocol).

So the relay has to drive around the block again (reminds me of an
episode of Keeping Up Appearances :).

-Rajesh

On Sun, Nov 1, 2009 at 12:41 PM, Stephen Farrell
<[email-masked]> wrote:
>
> Finishing my reading:
>
> [yes] draft-irtf-dtnrg-prophet
>
> Stephen.
>
> - p6: s/In this draft/In this specification/
> - p6: expand EID on first use
> - p7: s/protocoll/protocol/
> - p13: "Instance numbers" forward reference - be nicer if that
> �could be omitted
> - p16: s/Tead/T_aed/ & expand TTL on 1st use
> - p18: says that nodes SHOULD forward bundles when in direct contact
> �with the bundle destination - why is that not a MUST? Can't think
> �of any reason myself.
> - p21: s/there need/there needs/
> - p22: section 4.1 could be deleted since it says nothing
> - p24, "Hello SYN" etc are used without having been introduced
> �(same for RSTACK)
> - p31: I don't understand the description of the flags are
> �all bit reserved? what does "0b1" signify? Giving some examples
> �of P-value encoding would be good - its something coders could
> �get wrong easily
> - p34: Why isn't ESTAB a state listed in 5.1? (or SYNSENT or the
> �others)
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Sun, 01 Nov 2009 17:41:01 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTNRG docs that are....done?

Finishing my reading:

[yes] draft-irtf-dtnrg-prophet

Stephen.

- p6: s/In this draft/In this specification/
- p6: expand EID on first use
- p7: s/protocoll/protocol/
- p13: "Instance numbers" forward reference - be nicer if that
  could be omitted
- p16: s/Tead/T_aed/ & expand TTL on 1st use
- p18: says that nodes SHOULD forward bundles when in direct contact
  with the bundle destination - why is that not a MUST? Can't think
  of any reason myself.
- p21: s/there need/there needs/
- p22: section 4.1 could be deleted since it says nothing
- p24, "Hello SYN" etc are used without having been introduced
  (same for RSTACK)
- p31: I don't understand the description of the flags are
  all bit reserved? what does "0b1" signify? Giving some examples
  of P-value encoding would be good - its something coders could
  get wrong easily
- p34: Why isn't ESTAB a state listed in 5.1? (or SYNSENT or the
  others)