Subject: RE: [dtn-interest] Re: [nasa-dtn] DTN Basics (the very basics)
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Ivancic, William D. \(GRC-RCN0\)" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
Date: Tue, 31 Jul 2007 13:02:12 -0500
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

I revised the charts once again to include Scott's suggestions. In
addition, chart 6 gives a better indication of what regions are
opportunistic and what is scheduled.

http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt

Any other constructive criticisms that will improve this are welcome.  

Now, perhaps we can work on improving the protocols and moving the
technology forward.  ;-)

Cheers,

Will

PS. I plan to use these slides this Thursday for a presentation to my
directorate head.  

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

> -----Original Message-----
> From: Ivancic, William D. (GRC-RCN0) 
> Sent: Tuesday, July 31, 2007 8:08 AM
> To: 'Scott Burleigh'; [email-masked]
> Subject: RE: [dtn-interest] Re: [nasa-dtn] DTN Basics (the 
> very basics)
> 
> Right Scott.  Go point.  Let me think about it a bit.
> 
> I guess I should probably label that "Opportunistic Bundle 
> Agent Discovery - see chart 6"  as opposed to just "Bundle 
> Agent Discovery".   The only problem is that then you get 
> caught up in trying to explain opportunistic vs scheduled 
> early on to a non-technical person.  That is what chart 6 is 
> suppose to do.  To many concepts to quickly is always tricky.
> 
> Will
> 
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Scott 
> > Burleigh
> > Sent: Tuesday, July 31, 2007 12:32 AM
> > To: [email-masked]
> > Subject: [dtn-interest] Re: [nasa-dtn] DTN Basics (the very basics)
> > 
> > Ivancic, William D. (GRC-RCN0) wrote:
> > > I put this simple presentation together with animation to
> > explain DTN
> > > to non-networking (and some networking) people as well as
> > high-level
> > > managers.  Feel free to use it.  If the DTN group wishes to
> > post it on
> > > the DTN site for tutorial purposes, feel free.  If someone
> > wishes to
> > > modify it, feel free to do that also.  Wild West pictures
> > may not fit
> > > your historical background and culture.
> > > 
> > > http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
> > 
> > Nice, Will, I think this will be a great vehicle for 
> explaining DTN in 
> > high-level presentations.
> > 
> > One point I'd want to think about a little more, though, is 
> the early 
> > animation on bundle agent discovery.  In the case you're showing it 
> > works great, because Jane Seymour and Chuck Wagon are able to stand 
> > within a few yards of each other and have a conversation.  
> In the more 
> > general case, there may be a great deal of delay in the 
> communication 
> > between Jane and Chuck, in addition to the delay entailed 
> in conveying 
> > Jane's letter over the lonesome prairie to downtown Fort Pitt.  For 
> > example, maybe Jane has to stay in the schoolhouse all day and can 
> > really only ask Chuck about his travel plans by sending 
> little Homer 
> > out to the North Forty with a note.  And by the time Homer 
> gets back 
> > with Chuck's reply that evening, Chuck's mule could have 
> stepped in a 
> > prairie dog hole and come up lame, so now Chuck won't be 
> heading out 
> > for Knoxville until Thursday; Jane's out of luck -- she's 
> got to find 
> > some other itinerant yet trustworthy cowpoke -- and she 
> doesn't even 
> > know it yet.
> > 
> > Scott
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Re: [nasa-dtn] DTN Basics (the very basics)
Date: Tue, 31 Jul 2007 07:07:56 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Right Scott.  Go point.  Let me think about it a bit.

I guess I should probably label that "Opportunistic Bundle Agent
Discovery - see chart 6"  as opposed to just "Bundle Agent Discovery".
The only problem is that then you get caught up in trying to explain
opportunistic vs scheduled early on to a non-technical person.  That is
what chart 6 is suppose to do.  To many concepts to quickly is always
tricky.

Will

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Scott Burleigh
> Sent: Tuesday, July 31, 2007 12:32 AM
> To: [email-masked]
> Subject: [dtn-interest] Re: [nasa-dtn] DTN Basics (the very basics)
> 
> Ivancic, William D. (GRC-RCN0) wrote:
> > I put this simple presentation together with animation to 
> explain DTN 
> > to non-networking (and some networking) people as well as 
> high-level 
> > managers.  Feel free to use it.  If the DTN group wishes to 
> post it on 
> > the DTN site for tutorial purposes, feel free.  If someone 
> wishes to 
> > modify it, feel free to do that also.  Wild West pictures 
> may not fit 
> > your historical background and culture.
> > 
> > http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
> 
> Nice, Will, I think this will be a great vehicle for 
> explaining DTN in high-level presentations.
> 
> One point I'd want to think about a little more, though, is 
> the early animation on bundle agent discovery.  In the case 
> you're showing it works great, because Jane Seymour and Chuck 
> Wagon are able to stand within a few yards of each other and 
> have a conversation.  In the more general case, there may be 
> a great deal of delay in the communication between Jane and 
> Chuck, in addition to the delay entailed in conveying Jane's 
> letter over the lonesome prairie to downtown Fort Pitt.  For 
> example, maybe Jane has to stay in the schoolhouse all day 
> and can really only ask Chuck about his travel plans by 
> sending little Homer out to the North Forty with a note.  And 
> by the time Homer gets back with Chuck's reply that evening, 
> Chuck's mule could have stepped in a prairie dog hole and 
> come up lame, so now Chuck won't be heading out for Knoxville 
> until Thursday; Jane's out of luck -- she's got to find some 
> other itinerant yet trustworthy cowpoke -- and she doesn't 
> even know it yet.
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 30 Jul 2007 21:31:38 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Re: [nasa-dtn] DTN Basics (the very basics)
Sender: [email-masked]

Ivancic, William D. (GRC-RCN0) wrote:
> I put this simple presentation together with animation to explain DTN to
> non-networking (and some networking) people as well as high-level
> managers.  Feel free to use it.  If the DTN group wishes to post it on
> the DTN site for tutorial purposes, feel free.  If someone wishes to
> modify it, feel free to do that also.  Wild West pictures may not fit
> your historical background and culture.
> 
> http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt

Nice, Will, I think this will be a great vehicle for explaining DTN in high-level presentations.

One point I'd want to think about a little more, though, is the early animation on bundle agent discovery.  In the case you're showing it works great, because Jane Seymour and Chuck Wagon are able to stand within a few yards of each other and have a conversation.  In the more general case, there may be a great deal of delay in the communication between Jane and Chuck, in addition to the delay entailed in conveying Jane's letter over the lonesome prairie to downtown Fort Pitt.  For example, maybe Jane has to stay in the schoolhouse all day and can really only ask Chuck about his travel plans by sending little Homer out to the North Forty with a note.  And by the time Homer gets back with Chuck's reply that evening, Chuck's mule could have stepped in a prairie dog hole and come up lame, so now Chuck won't be heading out for Knoxville until Thursday; Jane's out of luck -- she's got to find some other itinerant yet trustworthy cowpoke -- and she doesn't even know it yet.

Scott

Subject: RE: [dtn-interest] DTN Basics (the very basics)
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Organization: BBN Technologies
Date: Mon, 30 Jul 2007 18:53:55 -0400
Sender: [email-masked]

DTN as overlay is without a doubt the near-term dominant case.

Over time, however, what gets overlaid on what could change, and ideas
on the best/cost-efficient way to deploy a technology or how to gateway
information between network technologies can evolve.  IP over telephone
networks vs. VoIP is an example of an overlay-to-underlay relationship
getting inverted over time.  I am not claiming that DTN will achieve
such an inversion, but I do find as an intriguing possibility a future
content/dissemination-oriented network based on DTN within which
one-to-one interpersonal communication is handled as a special case.

(Off-topic and should be taken off-line:  My interpretation is that WAND
explores an alternative way of inter-working with IP, but it does not
ignore the reach-back to the big Internet or lessons learned from
earlier MANET work.  Data born as IP can be sourced, destined to, or
relayed over WAND nodes.)

Best  Regards,
Rajesh

On Mon, 2007-07-30 at 15:39 -0500, Ivancic, William D. (GRC-RCN0) wrote:
> Adrian,
>  
> Eventually one would want to do slide 15
>  
> http://web-ext2.darpa.mil/sto/solicitations/WAND/pdf/WAND_Proposers_Day_Briefing.pdf
>  
> Thus a DTN in WAND would talk to  a DTN that has some other
> convergence layer.  Sort of the point of DTN.
>  
> However, if one looks at slide 11, one may decide to run DTN over IPv6
> over WAND and not have to write multiple convergence layers and
> multiple applications to address the uniqueness of each convergence
> layer (bundle agent discover, etc..).  It is a scalability and
> deployment issue.
>  
> Writing  DTN directly over WAND and only operating with DTNs that are
> on WAND is pretty restrictive.  This is sort of like the manet initial
> work when the realization came along that at some point one may want
> to talk to something outside the manet. - reach back to the big
> Internet.
>  
> Or, to put is simply - I believe overlay applies.  It is semantics
> that can be argued either way.
>  
> Will
>  
> ******************************
> 
> William D. Ivancic
> 
> Phone 216-433-3494
> 
> Fax 216-433-8705
> 
> Lab 216-433-2620
> 
> Mobile 440-503-4892
> 
> http://roland.grc.nasa.gov/~ivancic 
> 
>  
> 
>         
>         ______________________________________________________________
>         From: Adrian J. Hooke [mailto:[email-masked]] 
>         Sent: Monday, July 30, 2007 12:32 PM
>         To: Ivancic, William D. (GRC-RCN0)
>         Cc: [email-masked]
>         Subject: RE: [dtn-interest] DTN Basics (the very basics)
>         
>         
>         
>         At 11:09 AM 7/30/2007, Ivancic, William D. (GRC-RCN0) wrote:
>         > http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt 
>         
>         Will: on slide 5 you still assert that "the architecture
>         operates as an overlay network". Is that universally true, or
>         are there cases (such as below) where DTN will run natively?
>         If so, shouldn't the assertion be modified?
>         
>         ///adrian
>         
>         > At 01:11 PM 7/27/2007, Rajesh Krishnan wrote:
>         > > 
>         > > The DARPA WAND program has as a goal implementing DTN as a
>         > > native protocol rather than as an overlay as it is
>         > > currently envisioned for the
>         > > most part.
>         

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Date: Mon, 30 Jul 2007 15:39:13 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Adrian J. Hooke" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7D2E9.BAFC0FAE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Adrian,
=20
Eventually one would want to do slide 15
=20
http://web-ext2.darpa.mil/sto/solicitations/WAND/pdf/WAND_Proposers_Day_
Briefing.pdf
=20
Thus a DTN in WAND would talk to  a DTN that has some other convergence
layer.  Sort of the point of DTN.
=20
However, if one looks at slide 11, one may decide to run DTN over IPv6
over WAND and not have to write multiple convergence layers and multiple
applications to address the uniqueness of each convergence layer (bundle
agent discover, etc..).  It is a scalability and deployment issue.
=20
Writing  DTN directly over WAND and only operating with DTNs that are on
WAND is pretty restrictive.  This is sort of like the manet initial work
when the realization came along that at some point one may want to talk
to something outside the manet. - reach back to the big Internet.
=20
Or, to put is simply - I believe overlay applies.  It is semantics that
can be argued either way.
=20
Will
=20

******************************

William D. Ivancic

Phone 216-433-3494

Fax 216-433-8705

Lab 216-433-2620

Mobile 440-503-4892

http://roland.grc.nasa.gov/~ivancic
<http://roland.grc.nasa.gov/~ivancic> =20

=20

________________________________

	From: Adrian J. Hooke [mailto:[email-masked]]=20
	Sent: Monday, July 30, 2007 12:32 PM
	To: Ivancic, William D. (GRC-RCN0)
	Cc: [email-masked]
	Subject: RE: [dtn-interest] DTN Basics (the very basics)
=09
=09
	At 11:09 AM 7/30/2007, Ivancic, William D. (GRC-RCN0) wrote:
=09

		http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt=20

	Will: on slide 5 you still assert that "the architecture
operates as an overlay network". Is that universally true, or are there
cases (such as below) where DTN will run natively? If so, shouldn't the
assertion be modified?
=09
	///adrian
=09
=09

		At 01:11 PM 7/27/2007, Rajesh Krishnan wrote:
	=09

			The DARPA WAND program has as a goal
implementing DTN as a native protocol rather than as an overlay as it is
currently envisioned for the
			most part.

------_=_NextPart_001_01C7D2E9.BAFC0FAE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Adrian,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Eventually one would want to do slide=20
15</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2><A=20
href=3D"http://web-ext2.darpa.mil/sto/solicitations/WAND/pdf/WAND_Propose=
rs_Day_Briefing.pdf">http://web-ext2.darpa.mil/sto/solicitations/WAND/pdf=
/WAND_Proposers_Day_Briefing.pdf</A></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thus a DTN in WAND would talk to&nbsp; a DTN =
that has some=20
other convergence layer.&nbsp; Sort of the point of =
DTN.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>However, if one looks at slide 11, one may =
decide to run=20
DTN over IPv6 over WAND and not have to write multiple convergence =
layers and=20
multiple applications to address the uniqueness of each convergence =
layer=20
(bundle agent discover, etc..).&nbsp; It is a scalability and deployment =

issue.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Writing&nbsp; DTN directly over WAND and only =
operating=20
with DTNs that are on WAND is pretty restrictive.&nbsp; This is sort of =
like the=20
manet initial work when the realization came along that at some point =
one may=20
want to talk to something outside the manet. - reach back to the big=20
Internet.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Or, to put is simply - I believe overlay =
applies.&nbsp; It=20
is semantics that can be argued either way.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D078263220-30072007><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Will</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P align=3Dleft><FONT face=3DCourier=20
size=3D2>******************************</FONT></P>
<P align=3Dleft><FONT face=3DCourier size=3D2>William D. =
Ivancic</FONT></P>
<P align=3Dleft><FONT face=3DCourier size=3D2>Phone =
216-433-3494</FONT></P>
<P align=3Dleft><FONT face=3DCourier size=3D2>Fax =
216-433-8705</FONT></P>
<P align=3Dleft><FONT face=3DCourier size=3D2>Lab =
216-433-2620</FONT></P>
<P align=3Dleft><FONT face=3DCourier size=3D2>Mobile =
440-503-4892</FONT></P>
<P align=3Dleft><A href=3D"http://roland.grc.nasa.gov/~ivancic"><U><FONT =

color=3D#0000ff><FONT face=3DCourier=20
size=3D2>http://roland.grc.nasa.gov/~ivancic</FONT></U></FONT></A><FONT=20
face=3DCourier size=3D2> </FONT></P>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Adrian J. Hooke=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Monday, July 30, =
2007=20
  12:32 PM<BR><B>To:</B> Ivancic, William D. (GRC-RCN0)<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> RE: [dtn-interest] =
DTN=20
  Basics (the very basics)<BR></FONT><BR></DIV>
  <DIV></DIV><FONT size=3D3>At 11:09 AM 7/30/2007, Ivancic, William D. =
(GRC-RCN0)=20
  wrote:<BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><A=20
    href=3D"http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt"=20
    =
eudora=3D"autourl">http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt=
</A></FONT>=20
  </BLOCKQUOTE><BR>Will: on slide 5 you still assert that "the =
architecture=20
  operates as an overlay network". Is that universally true, or are =
there cases=20
  (such as below) where DTN will run natively? If so, shouldn't the =
assertion be=20
  modified?<BR><BR>///adrian<BR><BR>
  <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT size=3D3>At =
01:11 PM=20
    7/27/2007, Rajesh Krishnan wrote:<BR>
    <BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><BR>The DARPA WAND =
program has=20
      as a goal implementing DTN as a native protocol rather than as an =
overlay=20
      as it is currently envisioned for the<BR>most=20
  part.</FONT></BLOCKQUOTE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C7D2E9.BAFC0FAE--

Date: Mon, 30 Jul 2007 12:31:51 -0400
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Cc: <[email-masked]>
Sender: [email-masked]

--=====================_4957218==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 11:09 AM 7/30/2007, Ivancic, William D. (GRC-RCN0) wrote:
>http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt

Will: on slide 5 you still assert that "the architecture operates as 
an overlay network". Is that universally true, or are there cases 
(such as below) where DTN will run natively? If so, shouldn't the 
assertion be modified?

///adrian

>At 01:11 PM 7/27/2007, Rajesh Krishnan wrote:
>>
>>The DARPA WAND program has as a goal implementing DTN as a native 
>>protocol rather than as an overlay as it is currently envisioned for the
>>most part.

--=====================_4957218==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font size=3>At 11:09 AM 7/30/2007, Ivancic, William D. (GRC-RCN0)
wrote:<br>
<blockquote type=cite class=cite cite="">
<a href="http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt" eudora="autourl">
http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt</a></font>
</blockquote><br>
Will: on slide 5 you still assert that &quot;the architecture operates as
an overlay network&quot;. Is that universally true, or are there cases
(such as below) where DTN will run natively? If so, shouldn't the
assertion be modified?<br><br>
///adrian<br><br>
<blockquote type=cite class=cite cite=""><font size=3>At 01:11 PM
7/27/2007, Rajesh Krishnan wrote:<br>
<blockquote type=cite class=cite cite=""><br>
The DARPA WAND program has as a goal implementing DTN as a native
protocol rather than as an overlay as it is currently envisioned for
the<br>
most part.</font></blockquote></blockquote></body>
<br>
</html>

--=====================_4957218==.ALT--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Date: Mon, 30 Jul 2007 10:09:17 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Kevin Fall" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Kevin,

Changes to the slides have been made per your suggestions.  File name
remains the same.

http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt

Will

==============================
Sound like a good suggestion to me. Thanks. I'll make the change.

There is always potential for problems with charts without the presenter
to clarify any sound bites.

Will

-----Original Message-----
From: Kevin Fall [mailto:[email-masked]]
Sent: Fri 7/27/2007 1:25 PM
To: Ivancic, William D. (GRC-RCN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN Basics (the very basics)
 
I think I see.  I might make the point differently.  How about this:

may add significant unnecessary overhead for very simple network  
topologies/environments

- K

Date: Mon, 30 Jul 2007 15:58:04 +0100
To: Leigh Torgerson <[email-masked]>, "Ivancic, William D. (GRC-RCN0)" <[email-masked]>, <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] DTN Basics (the very basics)
Sender: [email-masked]

At Monday 30/07/2007 06:05 -0700, Leigh Torgerson wrote:
>I'm sure people made agruments about the horrendous overhead of ATM - but given the hardware technology of the time, it had to be the way it is because the hardware just wasn't fast enough to handle larger payloads. 

Actually, handling larger payloads takes slower hardware, since you're just serialising out from memory - it's why router IPv4 switching performance is always measured with small 64-octet packets, rather than with larger packets. Larger payloads are easier.

I presume you're talking about the overhead of ATM cells, since e.g. AAL5 frames can go up to 64K (though their IP MTU is only 9180 bytes). When the CCITT was standardizing ATM, the choice was 32 or 64 bytes for cell payloads, depending on the echo cancellation needs of the existing voice systems (US/Europe). 48 bytes was a political compromise that was harder to handle in hardware. This is described well in
Stevenson, D., "Electropolitical Correctness and High-Speed Networking, or, Why ATM is like a Nose", Proceedings of TriCom '93, April 1993.
(Haven't seen a copy of that paper in years...)

L.

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

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Date: Mon, 30 Jul 2007 08:45:57 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Leigh Torgerson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Leigh,

I agree with everything you say.  The basic point is DTN does add
overhead and you are either willing to accept that because it provides
flexibility and functionality or you are not.  To point this out and
explain why that functionality is advantageous is important.  To gloss
over the additional overhead will likely result in decision makers
questioning a DTN advocates credibility.  As you pointed out below,
there may be cases where one might decide against DTN.   Hopefully that
decision make has all of the factual information they need to make a
sound decision.

Will

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

> -----Original Message-----
> From: Leigh Torgerson [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 9:06 AM
> To: Ivancic, William D. (GRC-RCN0); [email-masked]
> Subject: Re: [dtn-interest] DTN Basics (the very basics)
> 
> I guess I'm not sure the slide about overhead tells the story 
> unless you want to make a case against DTN..
> 
> One can always argue that a new protocol may add overhead and 
> cost money to implement. However, even in the case of  
> "simple" topology of 2 rovers talking to two orbiters who 
> talk to 3 DSN stations and at least 2 different ground 
> stations, the operational benefits of DTN in terms of 
> automated routing, ability to take advantage of opportunistic 
> links and the ability to route over different paths far 
> outweigh the cost of implementation and any overhead on the 
> link. Our studies and discussions with both the science 
> community and mission operations people show a very 
> worthwhile operations cost savings with DTN.
> 
> I'm sure people made agruments about the horrendous overhead 
> of ATM - but given the hardware technology of the time, it 
> had to be the way it is because the hardware just wasn't fast 
> enough to handle larger payloads. The functionality and 
> advantages far outweighed the additional overhead on the link.
> 
> In the same way, our work in autonomous science means a large 
> amount of processing overhead on spacecraft with limited 
> processing power, but the benefits far outweigh the costs of 
> implementing the software and processing power needed.
> 
> RF engineers argued that automatic retransmission was a waste 
> of time when "all you need is a few more dBs link margin" and 
> more robust coding and you hardly ever lose a packet... They 
> never stopped to think that with the possibility of any data 
> loss, the science community has to have daily meetings 
> debating whether or not to order the recovery of missing 
> data, while the data sits in spacecraft memory waiting for a 
> possible manually-commanded retransmission. The small 
> additional overhead of an ARQ scheme is well worth the effort 
> when the system-level view is fully evaluated.
> 
> So while it's fair to point out "additional overhead", it 
> might be better to quantify that overhead and then explain 
> what it buys you in terms of operational flexibility and 
> efficiency.  I'd probably agree that for a single 
> point-to-point link DTN might not be the best solution, but 
> for any non-trivial topology where the link combinations grow 
> factorially, DTN is a good solution.
> 
> Leigh
> 
> 
> At 10:48 AM -0500 7/27/07, Ivancic, William D. (GRC-RCN0) wrote:
> >I put this simple presentation together with animation to 
> explain DTN 
> >to non-networking (and some networking) people as well as high-level 
> >managers.  Feel free to use it.  If the DTN group wishes to 
> post it on 
> >the DTN site for tutorial purposes, feel free.  If someone wishes to 
> >modify it, feel free to do that also.  Wild West pictures 
> may not fit 
> >your historical background and culture.
> >
> >http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
> >
> >
> >
> >Will
> >******************************
> >_______________________________________________
> >dtn-interest mailing list
> >[email-masked]
> >http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> --
> -------------------------------------------------------------------
> J. Leigh Torgerson
> [email-masked]
> Jet Propulsion Laboratory -  Communications Systems Research 
> Sec. 332 DARPA DTN / DSMS Advanced Protcol Implementation 
> Work Area Manager
> (818) 393-0695
> (818) 393-4643 fax
> -------------------------------------------------------------------
> 

Date: Mon, 30 Jul 2007 06:05:43 -0700
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>, <[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] DTN Basics (the very basics)
Sender: [email-masked]

I guess I'm not sure the slide about overhead tells the story unless 
you want to make a case against DTN..

One can always argue that a new protocol may add overhead and cost 
money to implement. However, even in the case of  "simple" topology 
of 2 rovers talking to two orbiters who talk to 3 DSN stations and at 
least 2 different ground stations, the operational benefits of DTN in 
terms of automated routing, ability to take advantage of 
opportunistic links and the ability to route over different paths far 
outweigh the cost of implementation and any overhead on the link. Our 
studies and discussions with both the science community and mission 
operations people show a very worthwhile operations cost savings with 
DTN.

I'm sure people made agruments about the horrendous overhead of ATM - 
but given the hardware technology of the time, it had to be the way 
it is because the hardware just wasn't fast enough to handle larger 
payloads. The functionality and advantages far outweighed the 
additional overhead on the link.

In the same way, our work in autonomous science means a large amount 
of processing overhead on spacecraft with limited processing power, 
but the benefits far outweigh the costs of implementing the software 
and processing power needed.

RF engineers argued that automatic retransmission was a waste of time 
when "all you need is a few more dBs link margin" and more robust 
coding and you hardly ever lose a packet... They never stopped to 
think that with the possibility of any data loss, the science 
community has to have daily meetings debating whether or not to order 
the recovery of missing data, while the data sits in spacecraft 
memory waiting for a possible manually-commanded retransmission. The 
small additional overhead of an ARQ scheme is well worth the effort 
when the system-level view is fully evaluated.

So while it's fair to point out "additional overhead", it might be 
better to quantify that overhead and then explain what it buys you in 
terms of operational flexibility and efficiency.  I'd probably agree 
that for a single point-to-point link DTN might not be the best 
solution, but for any non-trivial topology where the link 
combinations grow factorially, DTN is a good solution.

Leigh

At 10:48 AM -0500 7/27/07, Ivancic, William D. (GRC-RCN0) wrote:
>I put this simple presentation together with animation to explain DTN to
>non-networking (and some networking) people as well as high-level
>managers.  Feel free to use it.  If the DTN group wishes to post it on
>the DTN site for tutorial purposes, feel free.  If someone wishes to
>modify it, feel free to do that also.  Wild West pictures may not fit
>your historical background and culture.
>
>http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
>
>
>
>Will
>******************************
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
-------------------------------------------------------------------
J. Leigh Torgerson 
[email-masked]
Jet Propulsion Laboratory -  Communications Systems Research Sec. 332
DARPA DTN / DSMS Advanced Protcol Implementation Work Area Manager
(818) 393-0695 
(818) 393-4643 fax
-------------------------------------------------------------------

Date: Mon, 30 Jul 2007 12:59:25 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Updating the list of papers...
Sender: [email-masked]

Hi all,

Someone asked me to post a link to a recent dtn-related paper
of theirs on the dtnrg.org page for that [1].

Seems like we've not done that for a while, so I'll collate
'em and post a bunch together.

To make that easy can you send stuff to me (don't cc the list
please) in the wiki source format, as shown by the examples
below which are the current 2007 set of papers. I reserve
the right to ignore stuff in the wrong format:-)

I'll give it a week or so and then post the lot in one go.

Cheers,
S.

[1] http://www.dtnrg.org/wiki/Docs

--- example format

  * T. Spyropoulos, K. Psounis, and C. Raghavendra, 
“[http://www-sop.inria.fr/planete/spyropoulos/papers/ton-singlecopy.pdf 
Efficient Routing in Intermittently Connected Mobile Networks: The 
Single-copy Case]”, to appear in ACM/IEEE journal of Transactions on 
Networking.
   * T. Spyropoulos, K. Psounis, and C. Raghavendra, 
“[http://www-sop.inria.fr/planete/spyropoulos/papers/ton-multicopy-final.pdf 
Efficient Routing in Intermittently Connected Mobile Networks: The 
Multi-copy Case]”, to appear in ACM/IEEE journal of Transactions on 
Networking.
   * K. Harras, M. Wittie, K. Almeroth and E. Belding. 
"[http://www.cs.ucsb.edu/~kharras/docs/paranets.pdf ParaNets: A Parallel 
Network Architecture for Challenged Networks]", IEEE Workshop on Mobile 
Computing Systems and Applications (HotMobile). Tucson, AZ, February 2007.

Date: Sun, 29 Jul 2007 10:56:39 -0400
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Cc: <[email-masked]>
Sender: [email-masked]

--=====================_420672656==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 02:19 PM 7/27/2007, Ivancic, William D. (GRC-RCN0) wrote:
>Let's say we have a spacecraft at Saturn and ground infrastructure 
>on the Earth and nothing else.  The system is highly scheduled.  DTN will
>work, but adds what might be considered significant overhead.

Will: in this configuration, do you base your overhead concerns on 
the assumption that on the ground-Saturn hop DTN is running natively 
over the space Link protocol, or as an overlay network running over 
an IP stack?

///adrian

--=====================_420672656==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font size=3 color="#0000FF">At 02:19 PM 7/27/2007, Ivancic, William D.
(GRC-RCN0) wrote:<br>
<blockquote type=cite class=cite cite="">Let's say we have a spacecraft
at Saturn and ground infrastructure on the Earth and nothing else.&nbsp;
The system is highly scheduled.&nbsp; DTN will<br>
work, but adds what might be considered significant overhead.
</font><font size=3></font></blockquote><br>
Will: in this configuration, do you base your overhead concerns on the
assumption that on the ground-Saturn hop DTN is running natively over the
space Link protocol, or as an overlay network running over an IP
stack?<br><br>
///adrian<br>
</body>
<br>
</html>

--=====================_420672656==.ALT--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Date: Fri, 27 Jul 2007 21:59:14 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Kevin Fall" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7D0C3.97D44159
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Sound like a good suggestion to me. Thanks. I'll make the change.

There is always potential for problems with charts without the presenter =
to clarify any sound bites.

Will

-----Original Message-----
From: Kevin Fall [mailto:[email-masked]]
Sent: Fri 7/27/2007 1:25 PM
To: Ivancic, William D. (GRC-RCN0)
Cc: [email-masked]
Subject: Re: [dtn-interest] DTN Basics (the very basics)
=20
I think I see.  I might make the point differently.  How about this:

may add significant unnecessary overhead for very simple network =20
topologies/environments

- K

On Jul 27, 2007, at 11:19 AM@Jul 27, 2007, Ivancic, William D. (GRC-=20
RCN0) wrote:

> Let's say we have a spacecraft at Saturn and ground infrastructure on
> the Earth and nothing else.  The system is highly scheduled.  DTN will
> work, but adds what might be considered significant overhead.  If I =20
> know
> my source and destination and they never change, I can most certainly
> hard code stuff - a one off.  This has been done.  It is an =20
> engineering
> and cost decision.  DTN may not be buying me a whole lot.
>
> If we oversell DTN as the best solution for all things (at least in =20
> the
> NASA world), at some point it will come  back to haunt us.  Better =20
> to be
> upfront on the pros and cons.  At least that has worked for me in the
> past.  Credibility if vital to establishing necessary relationships to
> obtain and maintain funding.  Not a technical thing, but without the
> money, it is hard to move the technology forward.
>
> Will
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>> -----Original Message-----
>> From: Kevin Fall [mailto:[email-masked]]
>> Sent: Friday, July 27, 2007 12:06 PM
>> To: Ivancic, William D. (GRC-RCN0)
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] DTN Basics (the very basics)
>>
>> One of your slides says this:
>>
>> Non-Optimal Solution for particular situations such as if
>> limited infrastructure exists
>>
>> Not sure I understand what you mean here.  How do you know
>> whether its optimal or not?  Is this related to packet
>> overhead or something else?
>>
>> - K
>>
>> On Jul 27, 2007, at 8:48 AM@Jul 27, 2007, Ivancic, William D. (GRC-
>> RCN0) wrote:
>>
>>>
>>> I put this simple presentation together with animation to explain
>>> DTN to
>>> non-networking (and some networking) people as well as high-level
>>> managers.  Feel free to use it.  If the DTN group wishes to
>> post it on
>>> the DTN site for tutorial purposes, feel free.  If someone wishes to
>>> modify it, feel free to do that also.  Wild West pictures
>> may not fit
>>> your historical background and culture.
>>>
>>> http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
>>>
>>>
>>>
>>> Will
>>> ******************************
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

------_=_NextPart_001_01C7D0C3.97D44159
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.7651.59">
<TITLE>RE: [dtn-interest] DTN Basics (the very basics)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Sound like a good suggestion to me. Thanks. I'll make =
the change.<BR>
<BR>
There is always potential for problems with charts without the presenter =
to clarify any sound bites.<BR>
<BR>
Will<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Kevin Fall [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
Sent: Fri 7/27/2007 1:25 PM<BR>
To: Ivancic, William D. (GRC-RCN0)<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] DTN Basics (the very basics)<BR>
<BR>
I think I see.&nbsp; I might make the point differently.&nbsp; How about =
this:<BR>
<BR>
may add significant unnecessary overhead for very simple =
network&nbsp;<BR>
topologies/environments<BR>
<BR>
- K<BR>
<BR>
On Jul 27, 2007, at 11:19 AM@Jul 27, 2007, Ivancic, William D. (GRC-<BR>
RCN0) wrote:<BR>
<BR>
&gt; Let's say we have a spacecraft at Saturn and ground infrastructure =
on<BR>
&gt; the Earth and nothing else.&nbsp; The system is highly =
scheduled.&nbsp; DTN will<BR>
&gt; work, but adds what might be considered significant overhead.&nbsp; =
If I&nbsp;<BR>
&gt; know<BR>
&gt; my source and destination and they never change, I can most =
certainly<BR>
&gt; hard code stuff - a one off.&nbsp; This has been done.&nbsp; It is =
an&nbsp;<BR>
&gt; engineering<BR>
&gt; and cost decision.&nbsp; DTN may not be buying me a whole lot.<BR>
&gt;<BR>
&gt; If we oversell DTN as the best solution for all things (at least =
in&nbsp;<BR>
&gt; the<BR>
&gt; NASA world), at some point it will come&nbsp; back to haunt =
us.&nbsp; Better&nbsp;<BR>
&gt; to be<BR>
&gt; upfront on the pros and cons.&nbsp; At least that has worked for me =
in the<BR>
&gt; past.&nbsp; Credibility if vital to establishing necessary =
relationships to<BR>
&gt; obtain and maintain funding.&nbsp; Not a technical thing, but =
without the<BR>
&gt; money, it is hard to move the technology forward.<BR>
&gt;<BR>
&gt; Will<BR>
&gt;<BR>
&gt; ******************************<BR>
&gt; William D. Ivancic<BR>
&gt; Phone 216-433-3494<BR>
&gt; Fax 216-433-8705<BR>
&gt; Lab 216-433-2620<BR>
&gt; Mobile 440-503-4892<BR>
&gt; <A =
HREF=3D"http://roland.grc.nasa.gov/~ivancic">http://roland.grc.nasa.gov/~=
ivancic</A><BR>
&gt;<BR>
&gt;<BR>
&gt;&gt; -----Original Message-----<BR>
&gt;&gt; From: Kevin Fall [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<B=
R>
&gt;&gt; Sent: Friday, July 27, 2007 12:06 PM<BR>
&gt;&gt; To: Ivancic, William D. (GRC-RCN0)<BR>
&gt;&gt; Cc: [email-masked]<BR>
&gt;&gt; Subject: Re: [dtn-interest] DTN Basics (the very basics)<BR>
&gt;&gt;<BR>
&gt;&gt; One of your slides says this:<BR>
&gt;&gt;<BR>
&gt;&gt; Non-Optimal Solution for particular situations such as if<BR>
&gt;&gt; limited infrastructure exists<BR>
&gt;&gt;<BR>
&gt;&gt; Not sure I understand what you mean here.&nbsp; How do you =
know<BR>
&gt;&gt; whether its optimal or not?&nbsp; Is this related to packet<BR>
&gt;&gt; overhead or something else?<BR>
&gt;&gt;<BR>
&gt;&gt; - K<BR>
&gt;&gt;<BR>
&gt;&gt; On Jul 27, 2007, at 8:48 AM@Jul 27, 2007, Ivancic, William D. =
(GRC-<BR>
&gt;&gt; RCN0) wrote:<BR>
&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; I put this simple presentation together with animation to =
explain<BR>
&gt;&gt;&gt; DTN to<BR>
&gt;&gt;&gt; non-networking (and some networking) people as well as =
high-level<BR>
&gt;&gt;&gt; managers.&nbsp; Feel free to use it.&nbsp; If the DTN group =
wishes to<BR>
&gt;&gt; post it on<BR>
&gt;&gt;&gt; the DTN site for tutorial purposes, feel free.&nbsp; If =
someone wishes to<BR>
&gt;&gt;&gt; modify it, feel free to do that also.&nbsp; Wild West =
pictures<BR>
&gt;&gt; may not fit<BR>
&gt;&gt;&gt; your historical background and culture.<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; <A =
HREF=3D"http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt">http://ro=
land.grc.nasa.gov/~ivancic/shared/DTN-101.ppt</A><BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt;<BR>
&gt;&gt;&gt; Will<BR>
&gt;&gt;&gt; ******************************<BR>
&gt;&gt;&gt; _______________________________________________<BR>
&gt;&gt;&gt; dtn-interest mailing list<BR>
&gt;&gt;&gt; [email-masked]<BR>
&gt;&gt;&gt; <A =
HREF=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://ma=
ilman.dtnrg.org/mailman/listinfo/dtn-interest</A><BR>
&gt;&gt;&gt;<BR>
&gt;&gt;<BR>
&gt;&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dtn-interest mailing list<BR>
&gt; [email-masked]<BR>
&gt; <A =
HREF=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://ma=
ilman.dtnrg.org/mailman/listinfo/dtn-interest</A><BR>
&gt;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7D0C3.97D44159--

Cc: [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] DTN Basics (the very basics)
Date: Fri, 27 Jul 2007 11:25:19 -0700
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Sender: [email-masked]

I think I see.  I might make the point differently.  How about this:

may add significant unnecessary overhead for very simple network  
topologies/environments

- K

On Jul 27, 2007, at 11:19 AM@Jul 27, 2007, Ivancic, William D. (GRC- 
RCN0) wrote:

> Let's say we have a spacecraft at Saturn and ground infrastructure on
> the Earth and nothing else.  The system is highly scheduled.  DTN will
> work, but adds what might be considered significant overhead.  If I  
> know
> my source and destination and they never change, I can most certainly
> hard code stuff - a one off.  This has been done.  It is an  
> engineering
> and cost decision.  DTN may not be buying me a whole lot.
>
> If we oversell DTN as the best solution for all things (at least in  
> the
> NASA world), at some point it will come  back to haunt us.  Better  
> to be
> upfront on the pros and cons.  At least that has worked for me in the
> past.  Credibility if vital to establishing necessary relationships to
> obtain and maintain funding.  Not a technical thing, but without the
> money, it is hard to move the technology forward.
>
> Will
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Lab 216-433-2620
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>> -----Original Message-----
>> From: Kevin Fall [mailto:[email-masked]]
>> Sent: Friday, July 27, 2007 12:06 PM
>> To: Ivancic, William D. (GRC-RCN0)
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] DTN Basics (the very basics)
>>
>> One of your slides says this:
>>
>> Non-Optimal Solution for particular situations such as if
>> limited infrastructure exists
>>
>> Not sure I understand what you mean here.  How do you know
>> whether its optimal or not?  Is this related to packet
>> overhead or something else?
>>
>> - K
>>
>> On Jul 27, 2007, at 8:48 AM@Jul 27, 2007, Ivancic, William D. (GRC-
>> RCN0) wrote:
>>
>>>
>>> I put this simple presentation together with animation to explain
>>> DTN to
>>> non-networking (and some networking) people as well as high-level
>>> managers.  Feel free to use it.  If the DTN group wishes to
>> post it on
>>> the DTN site for tutorial purposes, feel free.  If someone wishes to
>>> modify it, feel free to do that also.  Wild West pictures
>> may not fit
>>> your historical background and culture.
>>>
>>> http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
>>>
>>>
>>>
>>> Will
>>> ******************************
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] DTN Basics (the very basics)
Date: Fri, 27 Jul 2007 13:19:00 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Kevin Fall" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Let's say we have a spacecraft at Saturn and ground infrastructure on
the Earth and nothing else.  The system is highly scheduled.  DTN will
work, but adds what might be considered significant overhead.  If I know
my source and destination and they never change, I can most certainly
hard code stuff - a one off.  This has been done.  It is an engineering
and cost decision.  DTN may not be buying me a whole lot.  

If we oversell DTN as the best solution for all things (at least in the
NASA world), at some point it will come  back to haunt us.  Better to be
upfront on the pros and cons.  At least that has worked for me in the
past.  Credibility if vital to establishing necessary relationships to
obtain and maintain funding.  Not a technical thing, but without the
money, it is hard to move the technology forward.

Will

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

> -----Original Message-----
> From: Kevin Fall [mailto:[email-masked]] 
> Sent: Friday, July 27, 2007 12:06 PM
> To: Ivancic, William D. (GRC-RCN0)
> Cc: [email-masked]
> Subject: Re: [dtn-interest] DTN Basics (the very basics)
> 
> One of your slides says this:
> 
> Non-Optimal Solution for particular situations such as if 
> limited infrastructure exists
> 
> Not sure I understand what you mean here.  How do you know 
> whether its optimal or not?  Is this related to packet 
> overhead or something else?
> 
> - K
> 
> On Jul 27, 2007, at 8:48 AM@Jul 27, 2007, Ivancic, William D. (GRC- 
> RCN0) wrote:
> 
> >
> > I put this simple presentation together with animation to explain  
> > DTN to
> > non-networking (and some networking) people as well as high-level
> > managers.  Feel free to use it.  If the DTN group wishes to 
> post it on
> > the DTN site for tutorial purposes, feel free.  If someone wishes to
> > modify it, feel free to do that also.  Wild West pictures 
> may not fit
> > your historical background and culture.
> >
> > http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
> >
> >
> >
> > Will
> > ******************************
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> 
> 

Subject: Re: [dtn-interest] DTN Basics (the very basics)
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Cc: [email-masked]
Organization: BBN Technologies
Date: Fri, 27 Jul 2007 13:11:56 -0400
Sender: [email-masked]

Will,

These are great slides.  Thanks for sharing them.

The DARPA WAND program has as a goal implementing DTN as a native
protocol rather than as an overlay as it is currently envisioned for the
most part.

Best Regards,
Rajesh

On Fri, 2007-07-27 at 10:48 -0500, Ivancic, William D. (GRC-RCN0) wrote:
> I put this simple presentation together with animation to explain DTN to
> non-networking (and some networking) people as well as high-level
> managers.  Feel free to use it.  If the DTN group wishes to post it on
> the DTN site for tutorial purposes, feel free.  If someone wishes to
> modify it, feel free to do that also.  Wild West pictures may not fit
> your historical background and culture.
> 
> http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
> 
> 
> 
> Will
> ******************************
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: "Lloyd Wood" <[email-masked]>, "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>
Date: Fri, 27 Jul 2007 12:57:33 -0400
Subject: [dtn-interest] Re(3): Integrity checksum capability
Sender: [email-masked]

Hi Susan,

my suggestion is indeed to have the new spec be *generally* conformant
with BSP, as well as BP of course.

By "generally conformant" I mean that the new ciphersuite would follow
the BSP rules etc but the implementation wouldn't [necessarily] include
the mandatory ciphersuites. I need to update BSP to no longer require this.

This gives the advantage of being able to leverage the block formats
etc, as Mike says. It also means that an intermediate node know how to
deal with it properly.

The new ciphersuite is free to use whatever algorithm etc it wants to
and can do canonicalization as it pleases - no restrictions.

I'm not correcting anything either you or Mike said, just confirming
that, yes, we *do* all understand one another correctly.

Cheers.....Peter

On Fri, Jul 27, 2007, Symington, Susan F. <[email-masked]> wrote:

>I'm not sure I fully understand what you mean, Stephen. (I'm not
>necessarily against it, I really just want to better-understand what
>you mean.)
>
>If the new integrity checksum ciphersuites are specified in some
>document other than the Bundle Security Protocol (BSP), then doesn't
>the checksum code have to conform to not only the BP and the new
>checksum document (as you say), but also to the BSP?  I would like to
>be convinced otherwise, but right now it seems to me that if the
>checksum ciphersuites are defined are for use with the BAB and the PSB,
>then any code implementing those ciphersuites would have to conform to
>the BSP (because the BSP is where the BAB and PSB are defined). Would
>it be acceptable to require conformance to only part of the BSP (for
>example, the BSP minus the mandatory ciphersuites)?  This seems to be
>what is needed in order to accommodate implementations that want
>integrity but not security capabilities and at the same time avoid
>opening up security holes. I guess I am wondering if it really would be
>acceptable to define conformance in this way.
>
>The beauty of defining the integrity checksum capability as a PSB
>ciphersuite, as Peter says, is that if a bundle contains a PSB using
>this ciphersuite and it is encrypted at a bastion gateway using the
>CB-RSA-AES128-PAYLOAD-PSB ciphersuite, we are assured that the
>integrity checksum will be encrypted along with the payload. 
>
>-susan
>*****************************************************************
>Susan Symington
>The MITRE Corporation
>[email-masked]
>703-983-7209 (voice)
>703-983-7142 (fax)
>******************************************************************
> 
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of 
>>Stephen Farrell
>>Sent: Wednesday, July 25, 2007 10:56 PM
>>To: Peter Lovell
>>Cc: Lloyd Wood; Darren Long; dtn interest
>>Subject: Re: [dtn-interest] New bundle internet draft and 
>>paper comparing protocols for reliability errored delivery.
>>
>>
>>
>>Peter Lovell wrote:
>>> The current problem is that if you touch BSP at all, then you *must*
>>> support the mandatory ciphersuites. 
>>
>>I don't think that that's necessary. All we have to do is document
>>the new ciphersuite separately with its own conformance statements
>>and then you're done. Your code simply conforms to a different pair
>>of RFCs (in that case the BP and checksum RFCs).
>>
>>You do still have to consider encryption of any checksum over the
>>plaintext, which is a pita.
>>
>>Even if it were done in a single document you could include two
>>profiles with seprate conformance statements though I dislike that
>>for various reasons.
>>
>>S.
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>

Cc: [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] DTN Basics (the very basics)
Date: Fri, 27 Jul 2007 09:06:13 -0700
To: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Sender: [email-masked]

One of your slides says this:

Non-Optimal Solution for particular situations such as if limited  
infrastructure exists

Not sure I understand what you mean here.  How do you know whether  
its optimal or not?  Is this related to packet overhead or something  
else?

- K

On Jul 27, 2007, at 8:48 AM@Jul 27, 2007, Ivancic, William D. (GRC- 
RCN0) wrote:

>
> I put this simple presentation together with animation to explain  
> DTN to
> non-networking (and some networking) people as well as high-level
> managers.  Feel free to use it.  If the DTN group wishes to post it on
> the DTN site for tutorial purposes, feel free.  If someone wishes to
> modify it, feel free to do that also.  Wild West pictures may not fit
> your historical background and culture.
>
> http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt
>
>
>
> Will
> ******************************
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Date: Fri, 27 Jul 2007 10:48:29 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] DTN Basics (the very basics)
Sender: [email-masked]

I put this simple presentation together with animation to explain DTN to
non-networking (and some networking) people as well as high-level
managers.  Feel free to use it.  If the DTN group wishes to post it on
the DTN site for tutorial purposes, feel free.  If someone wishes to
modify it, feel free to do that also.  Wild West pictures may not fit
your historical background and culture.

http://roland.grc.nasa.gov/~ivancic/shared/DTN-101.ppt

Will
******************************

Cc: Stephen Farrell <[email-masked]>, Peter Lovell <[email-masked]>, Lloyd Wood <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Integrity checksum capability
Date: Fri, 27 Jul 2007 08:30:47 -0700
To: "Symington, Susan F." <[email-masked]>
Sender: [email-masked]

I would say the point is that the new document can refer to the  
contents of the BSP specification, and thereby leverage its  
definitions for block formats, etc. But it doesn't therefore mean  
that any node which implements the checksum ciphersuite must  
necessarily implement the other ones.

In that way the node would be "conformant" with the new document, but  
not with the BSP, even though it uses part of the specification of  
the BSP to implement the new checksum feature.

Not to sound like a broken record, but I feel like there's not all  
that much value in all this discussion of conformance. If there's  
some situations in which it's useful to implement checksums but not  
the rest of the BSP, then people should go for it. This is a research  
group after all so we shouldn't be in the business of telling people  
what they can and can't do with the various specs.

-mike

On Jul 27, 2007, at 7:55 AM, Symington, Susan F. wrote:

> I'm not sure I fully understand what you mean, Stephen. (I'm not
> necessarily against it, I really just want to better-understand what
> you mean.)
>
> If the new integrity checksum ciphersuites are specified in some
> document other than the Bundle Security Protocol (BSP), then doesn't
> the checksum code have to conform to not only the BP and the new
> checksum document (as you say), but also to the BSP?  I would like to
> be convinced otherwise, but right now it seems to me that if the
> checksum ciphersuites are defined are for use with the BAB and the  
> PSB,
> then any code implementing those ciphersuites would have to conform to
> the BSP (because the BSP is where the BAB and PSB are defined). Would
> it be acceptable to require conformance to only part of the BSP (for
> example, the BSP minus the mandatory ciphersuites)?  This seems to be
> what is needed in order to accommodate implementations that want
> integrity but not security capabilities and at the same time avoid
> opening up security holes. I guess I am wondering if it really  
> would be
> acceptable to define conformance in this way.
>
> The beauty of defining the integrity checksum capability as a PSB
> ciphersuite, as Peter says, is that if a bundle contains a PSB using
> this ciphersuite and it is encrypted at a bastion gateway using the
> CB-RSA-AES128-PAYLOAD-PSB ciphersuite, we are assured that the
> integrity checksum will be encrypted along with the payload.
>
> -susan
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> Stephen Farrell
>> Sent: Wednesday, July 25, 2007 10:56 PM
>> To: Peter Lovell
>> Cc: Lloyd Wood; Darren Long; dtn interest
>> Subject: Re: [dtn-interest] New bundle internet draft and
>> paper comparing protocols for reliability errored delivery.
>>
>>
>>
>> Peter Lovell wrote:
>>> The current problem is that if you touch BSP at all, then you *must*
>>> support the mandatory ciphersuites.
>>
>> I don't think that that's necessary. All we have to do is document
>> the new ciphersuite separately with its own conformance statements
>> and then you're done. Your code simply conforms to a different pair
>> of RFCs (in that case the BP and checksum RFCs).
>>
>> You do still have to consider encryption of any checksum over the
>> plaintext, which is a pita.
>>
>> Even if it were done in a single document you could include two
>> profiles with seprate conformance statements though I dislike that
>> for various reasons.
>>
>> S.
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Fri, 27 Jul 2007 10:55:22 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: "Lloyd Wood" <[email-masked]>, "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: [dtn-interest] Integrity checksum capability
Sender: [email-masked]

I'm not sure I fully understand what you mean, Stephen. (I'm not
necessarily against it, I really just want to better-understand what
you mean.)

If the new integrity checksum ciphersuites are specified in some
document other than the Bundle Security Protocol (BSP), then doesn't
the checksum code have to conform to not only the BP and the new
checksum document (as you say), but also to the BSP?  I would like to
be convinced otherwise, but right now it seems to me that if the
checksum ciphersuites are defined are for use with the BAB and the PSB,
then any code implementing those ciphersuites would have to conform to
the BSP (because the BSP is where the BAB and PSB are defined). Would
it be acceptable to require conformance to only part of the BSP (for
example, the BSP minus the mandatory ciphersuites)?  This seems to be
what is needed in order to accommodate implementations that want
integrity but not security capabilities and at the same time avoid
opening up security holes. I guess I am wondering if it really would be
acceptable to define conformance in this way.

The beauty of defining the integrity checksum capability as a PSB
ciphersuite, as Peter says, is that if a bundle contains a PSB using
this ciphersuite and it is encrypted at a bastion gateway using the
CB-RSA-AES128-PAYLOAD-PSB ciphersuite, we are assured that the
integrity checksum will be encrypted along with the payload. 

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Stephen Farrell
>Sent: Wednesday, July 25, 2007 10:56 PM
>To: Peter Lovell
>Cc: Lloyd Wood; Darren Long; dtn interest
>Subject: Re: [dtn-interest] New bundle internet draft and 
>paper comparing protocols for reliability errored delivery.
>
>
>
>Peter Lovell wrote:
>> The current problem is that if you touch BSP at all, then you *must*
>> support the mandatory ciphersuites. 
>
>I don't think that that's necessary. All we have to do is document
>the new ciphersuite separately with its own conformance statements
>and then you're done. Your code simply conforms to a different pair
>of RFCs (in that case the BP and checksum RFCs).
>
>You do still have to consider encryption of any checksum over the
>plaintext, which is a pita.
>
>Even if it were done in a single document you could include two
>profiles with seprate conformance statements though I dislike that
>for various reasons.
>
>S.
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Thu, 26 Jul 2007 13:44:15 -0500
From: Joerg Ott <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] ACM MobiCom CHANTS 2007: Call for Posters
Sender: [email-masked]

Reminder:

                 CALL FOR POSTERS

Second Workshop on Challenged Networks (CHANTS) 2007
====================================================

Co-located with MobiCom 2007, 14 September 2007, Montreal, QC, Canada

http://chants-2007.netlab.tkk.fi/

Challenged networks are characterized by a heterogeneous mix of nodes
and widely varying network conditions. Nodes in today's challenged
networks often include mobile nodes, space-based nodes,
sensor/actuator nodes and other devices. Performance of the network
paths interconnecting such nodes can be highly varying in terms of
bandwidth, latency, disruption characteristics and security
requirements. Conventional Internet access in performance-limited
environments such as developing countries can also be regarded as
challenged networks as can be ad-hoc communication between personal
devices.

The Internet protocol architecture suffers some problems when used in
a challenged network setting. For example, when disconnection and
reconnection is common or link performance is highly variable or
extreme, one or more of the traditional Internet protocols do not work
well. In this workshop following CHANTS 2006 and WDTN 2005, we wish to
explore ongoing efforts in dealing with physical networks that operate
significantly differently from wired, connected networks and the
protocol architectures and algorithms used to deal with such
situations. Techniques for making applications tolerant to disruptions
and/or high delays are also in scope.

In addition to the workshop program consisting presentations and
demonstrations, we seek poster presentations discussing recent
(possibly early) research results.  Poster presentations with
accompanying demonstrations are encouraged.  Such demo proposals shall
present recent practical results from the area of challenged networks.
Demo proposals should include one additional page describing the
precise setup and requirements.

Poster and poster abstracts will be published on the CHANTS 2007 web
page.

Submission Format
-----------------

Poster abstracts must be at most 2 pages in size with a font size not
smaller than 10pt.

Please email the PDF version of your abstract to both co-chairs using
the subject "CHANTS poster submission":

     [email-masked]
     [email-masked]

Important Dates
---------------

Poster abstract submission:   2 August 2007 (23:59 GMT)
Notification of acceptance:  12 August 2007
Final abstract due:	      1 September 2007

Subject: Re: [dtn-interest] defining dtn:
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: Stephen Farrell <[email-masked]>
Cc: Michael Demmer <[email-masked]>, Prithwish Basu <[email-masked]>, DTN <[email-masked]>
Organization: BBN Technologies
Date: Thu, 26 Jul 2007 14:03:22 -0400
Sender: [email-masked]

Makes sense.  Folks at BBN would like to participate in this RFC, but
can do so better after September.

Best Regards,
Rajesh

On Thu, 2007-07-26 at 17:42 +0100, Stephen Farrell wrote:
> I don't think finishing this is very urgent, but as Kevin's
> messages implies, doing it fairly well is important. In
> fact, given that we could end up with things like "dtn:http:foo"
> I would expect this to take a while since we'll want to (and
> will certainly;-) get some comment from others as well.
> 
> Getting a concrete I-D to bat around in the next couple of
> months seems fine to me,
> S.
> 
> Rajesh Krishnan wrote:
> > Stephen,
> > 
> > How urgent is the I-D on DTN naming?   Can this happen, say, after
> > mid-September (when we have our big demo)?
> > 
> > Best Regards,
> > Rajesh
> > 
> > On Thu, 2007-07-26 at 08:06 -0700, Michael Demmer wrote:
> >> You're assuming that I have a writeup :-)
> >>
> >> I'm also too swamped to take the lead on this now, maybe in a couple  
> >> weeks I could do it.
> >>
> >> -m
> >>
> >> On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:
> >>
> >>> Hi Stephen,
> >>>
> >>> Sure, I can work with Mike to document the use case but  
> >>> unfortunately I am too swamped at the moment to take the lead on this.
> >>>
> >>> Mike, you can send me your writeup and I can add our use case to it.
> >>>
> >>> thanks,
> >>> -Prithwish
> >>>
> >>> Stephen Farrell wrote:
> >>>> Hi Prithwish,
> >>>>
> >>>> Sounds interesting. If you were willing to work with Mike
> >>>> to document your and his uses of dtn: (and others that turn
> >>>> up), that'd be great.
> >>>>
> >>>> That's probably not exactly the I-D you've been planning, but
> >>>> be great if you could help us make progress with this,
> >>>>
> >>>> Cheers,
> >>>> S.
> >>>>
> >>>> Prithwish Basu wrote:
> >>>>> Hi Stephen,
> >>>>>
> >>>>> We have been working on an intentional naming scheme for DTN as  
> >>>>> part of the DARPA DTN project. We plan to submit an Internet  
> >>>>> Draft about intentional names in a month or two but here is a  
> >>>>> quick summary which I thought may be relevant to this discussion  
> >>>>> (Mike knows a bit about this).
> >>>>>
> >>>>> We are planning to propose a subscheme for dtn: called  
> >>>>> "dtn:intent" which captures the intentional  name of a resource  
> >>>>> accessible over the DTN network. A name query is essentially a  
> >>>>> multicast or anycast address specified in the destination field  
> >>>>> of a bundle. Examples include:
> >>>>>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has  
> >>>>> semantics of "deliver bundle to ALL DTN nodes representing the 5  
> >>>>> nearest restaurants to Fenway Park
> >>>>>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has  
> >>>>> semantics of "deliver bundle to ANY of the DTN nodes representing  
> >>>>> the 5 nearest restaurants to Fenway Park"
> >>>>>
> >>>>> Note that these are valid URIs where the optional "//authority"  
> >>>>> part is not used but the "path" and "query" parts are used.  
> >>>>> (according to RFC 3986 jargon) The syntax of the query part of  
> >>>>> the intentional name is open. We are currently working with  
> >>>>> something that looks like Horn clause predicates or a sequence of  
> >>>>> attribute=value pairs.
> >>>>>
> >>>>> As an auxiliary note: the matching of registered endpoints to  
> >>>>> such intentionally named endpoints is different from what is  
> >>>>> currently done in DTN Ref Implementation (which is direct string  
> >>>>> matching or at most wildcard expansion). This is because it is  
> >>>>> unlikely that an application will register itself with the same  
> >>>>> EID as the intentionally named query. Instead the app will  
> >>>>> register itself with some other EID and a matching service  
> >>>>> (external or internal to the the BPA) will determine which  
> >>>>> registered apps on the current node match the incoming  
> >>>>> destination name query, and the BPA should deliver the bundle to  
> >>>>> those apps only. In order to perform this matching, one may have  
> >>>>> to look up knowledge bases or even perform non-trivial  
> >>>>> computations (as in case of the "nearest" example above).
> >>>>>
> >>>>> More details about the scheme and architecture will be available  
> >>>>> in the forthcoming Internet Draft submission but I thought that I  
> >>>>> should give the higher order bits here. Let me know if you or  
> >>>>> others have any questions or thoughts related to this.
> >>>>>
> >>>>> best regards,
> >>>>> -Prithwish
> >>>>>
> >>>>>
> >>>>> Stephen Farrell wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> As part of the BP spec review we've gotten a couple of
> >>>>>> requests for a formal definition of the dtn: URI scheme.
> >>>>>>
> >>>>>> Its not going to hold up the BP RFC, but would anyone
> >>>>>> take on the job of trying to write such a definition?
> >>>>>>
> >>>>>> To be honest, it might be a bit of work getting the
> >>>>>> definition into the right shape to keep all the various
> >>>>>> people here and in the URI-police happy, but if we
> >>>>>> don't do it, I guess we've a serious prospect of ending
> >>>>>> up with conflicting uses of dtn:<<foo>>
> >>>>>>
> >>>>>> S.
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> dtn-interest mailing list
> >>>>>> [email-masked]
> >>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>>>
> >>>>> _______________________________________________
> >>>>> dtn-interest mailing list
> >>>>> [email-masked]
> >>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>>
> >>> _______________________________________________
> >>> dtn-interest mailing list
> >>> [email-masked]
> >>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> > 
> > 

Date: Thu, 26 Jul 2007 17:42:15 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Michael Demmer <[email-masked]>, Prithwish Basu <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

I don't think finishing this is very urgent, but as Kevin's
messages implies, doing it fairly well is important. In
fact, given that we could end up with things like "dtn:http:foo"
I would expect this to take a while since we'll want to (and
will certainly;-) get some comment from others as well.

Getting a concrete I-D to bat around in the next couple of
months seems fine to me,
S.

Rajesh Krishnan wrote:
> Stephen,
> 
> How urgent is the I-D on DTN naming?   Can this happen, say, after
> mid-September (when we have our big demo)?
> 
> Best Regards,
> Rajesh
> 
> On Thu, 2007-07-26 at 08:06 -0700, Michael Demmer wrote:
>> You're assuming that I have a writeup :-)
>>
>> I'm also too swamped to take the lead on this now, maybe in a couple  
>> weeks I could do it.
>>
>> -m
>>
>> On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:
>>
>>> Hi Stephen,
>>>
>>> Sure, I can work with Mike to document the use case but  
>>> unfortunately I am too swamped at the moment to take the lead on this.
>>>
>>> Mike, you can send me your writeup and I can add our use case to it.
>>>
>>> thanks,
>>> -Prithwish
>>>
>>> Stephen Farrell wrote:
>>>> Hi Prithwish,
>>>>
>>>> Sounds interesting. If you were willing to work with Mike
>>>> to document your and his uses of dtn: (and others that turn
>>>> up), that'd be great.
>>>>
>>>> That's probably not exactly the I-D you've been planning, but
>>>> be great if you could help us make progress with this,
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> Prithwish Basu wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> We have been working on an intentional naming scheme for DTN as  
>>>>> part of the DARPA DTN project. We plan to submit an Internet  
>>>>> Draft about intentional names in a month or two but here is a  
>>>>> quick summary which I thought may be relevant to this discussion  
>>>>> (Mike knows a bit about this).
>>>>>
>>>>> We are planning to propose a subscheme for dtn: called  
>>>>> "dtn:intent" which captures the intentional  name of a resource  
>>>>> accessible over the DTN network. A name query is essentially a  
>>>>> multicast or anycast address specified in the destination field  
>>>>> of a bundle. Examples include:
>>>>>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has  
>>>>> semantics of "deliver bundle to ALL DTN nodes representing the 5  
>>>>> nearest restaurants to Fenway Park
>>>>>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has  
>>>>> semantics of "deliver bundle to ANY of the DTN nodes representing  
>>>>> the 5 nearest restaurants to Fenway Park"
>>>>>
>>>>> Note that these are valid URIs where the optional "//authority"  
>>>>> part is not used but the "path" and "query" parts are used.  
>>>>> (according to RFC 3986 jargon) The syntax of the query part of  
>>>>> the intentional name is open. We are currently working with  
>>>>> something that looks like Horn clause predicates or a sequence of  
>>>>> attribute=value pairs.
>>>>>
>>>>> As an auxiliary note: the matching of registered endpoints to  
>>>>> such intentionally named endpoints is different from what is  
>>>>> currently done in DTN Ref Implementation (which is direct string  
>>>>> matching or at most wildcard expansion). This is because it is  
>>>>> unlikely that an application will register itself with the same  
>>>>> EID as the intentionally named query. Instead the app will  
>>>>> register itself with some other EID and a matching service  
>>>>> (external or internal to the the BPA) will determine which  
>>>>> registered apps on the current node match the incoming  
>>>>> destination name query, and the BPA should deliver the bundle to  
>>>>> those apps only. In order to perform this matching, one may have  
>>>>> to look up knowledge bases or even perform non-trivial  
>>>>> computations (as in case of the "nearest" example above).
>>>>>
>>>>> More details about the scheme and architecture will be available  
>>>>> in the forthcoming Internet Draft submission but I thought that I  
>>>>> should give the higher order bits here. Let me know if you or  
>>>>> others have any questions or thoughts related to this.
>>>>>
>>>>> best regards,
>>>>> -Prithwish
>>>>>
>>>>>
>>>>> Stephen Farrell wrote:
>>>>>> Hi,
>>>>>>
>>>>>> As part of the BP spec review we've gotten a couple of
>>>>>> requests for a formal definition of the dtn: URI scheme.
>>>>>>
>>>>>> Its not going to hold up the BP RFC, but would anyone
>>>>>> take on the job of trying to write such a definition?
>>>>>>
>>>>>> To be honest, it might be a bit of work getting the
>>>>>> definition into the right shape to keep all the various
>>>>>> people here and in the URI-police happy, but if we
>>>>>> don't do it, I guess we've a serious prospect of ending
>>>>>> up with conflicting uses of dtn:<<foo>>
>>>>>>
>>>>>> S.
>>>>>>
>>>>>> _______________________________________________
>>>>>> dtn-interest mailing list
>>>>>> [email-masked]
>>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

Cc: [email-masked], Michael Demmer <[email-masked]>, Prithwish Basu <[email-masked]>, Stephen Farrell <[email-masked]>, DTN <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Date: Thu, 26 Jul 2007 08:48:54 -0700
To: Joerg Ott <[email-masked]>
Sender: [email-masked]

Yeah, I was going to suggest Joerg chime in here, based on what we  
heard in Dublin.

I'd also like to point out that whatever is decided on this mater  
could be rather important... given that there is significant interest  
in pub/sub and data-centric networking stuff, plus some notion that  
we probably want to interconnect dtn with the rest of the network and  
its services, we need to ensure the details of the scheme are  
amenable to those things.

Just to stir the pot-- for example, we could imagine that following  
"dtn:" you could have any other url.  So for example "dtn:http:// 
www.cnn.com" would mean you want the Internet cnn default web page,  
but you are willing to get it by any means DTN feels comfortable  
with.  [this is just a strawman; don't take it too seriously at this  
point].

- K

On Jul 26, 2007, at 8:25 AM@Jul 26, 2007, Joerg Ott wrote:

> Stephen,
>
> I should try to finally get our application draft submitted
> as this contains some additional discussion which could serve
> as input.
>
> Joerg
>
>> Stephen,
>> How urgent is the I-D on DTN naming?   Can this happen, say, after
>> mid-September (when we have our big demo)?
>> Best Regards,
>> Rajesh
>> On Thu, 2007-07-26 at 08:06 -0700, Michael Demmer wrote:
>>> You're assuming that I have a writeup :-)
>>>
>>> I'm also too swamped to take the lead on this now, maybe in a  
>>> couple  weeks I could do it.
>>>
>>> -m
>>>
>>> On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:
>>>
>>>
>>>> Hi Stephen,
>>>>
>>>> Sure, I can work with Mike to document the use case but   
>>>> unfortunately I am too swamped at the moment to take the lead on  
>>>> this.
>>>>
>>>> Mike, you can send me your writeup and I can add our use case to  
>>>> it.
>>>>
>>>> thanks,
>>>> -Prithwish
>>>>
>>>> Stephen Farrell wrote:
>>>>
>>>>> Hi Prithwish,
>>>>>
>>>>> Sounds interesting. If you were willing to work with Mike
>>>>> to document your and his uses of dtn: (and others that turn
>>>>> up), that'd be great.
>>>>>
>>>>> That's probably not exactly the I-D you've been planning, but
>>>>> be great if you could help us make progress with this,
>>>>>
>>>>> Cheers,
>>>>> S.
>>>>>
>>>>> Prithwish Basu wrote:
>>>>>
>>>>>> Hi Stephen,
>>>>>>
>>>>>> We have been working on an intentional naming scheme for DTN  
>>>>>> as  part of the DARPA DTN project. We plan to submit an  
>>>>>> Internet  Draft about intentional names in a month or two but  
>>>>>> here is a  quick summary which I thought may be relevant to  
>>>>>> this discussion  (Mike knows a bit about this).
>>>>>>
>>>>>> We are planning to propose a subscheme for dtn: called   
>>>>>> "dtn:intent" which captures the intentional  name of a  
>>>>>> resource  accessible over the DTN network. A name query is  
>>>>>> essentially a  multicast or anycast address specified in the  
>>>>>> destination field  of a bundle. Examples include:
>>>>>>   - dtn:intent:all?nearest(5,restaurant,FenwayPark) has   
>>>>>> semantics of "deliver bundle to ALL DTN nodes representing the  
>>>>>> 5  nearest restaurants to Fenway Park
>>>>>>   - dtn:intent:any?nearest(5,restaurant,FenwayPark) has   
>>>>>> semantics of "deliver bundle to ANY of the DTN nodes  
>>>>>> representing  the 5 nearest restaurants to Fenway Park"
>>>>>>
>>>>>> Note that these are valid URIs where the optional "// 
>>>>>> authority"  part is not used but the "path" and "query" parts  
>>>>>> are used.  (according to RFC 3986 jargon) The syntax of the  
>>>>>> query part of  the intentional name is open. We are currently  
>>>>>> working with  something that looks like Horn clause predicates  
>>>>>> or a sequence of  attribute=value pairs.
>>>>>>
>>>>>> As an auxiliary note: the matching of registered endpoints to   
>>>>>> such intentionally named endpoints is different from what is   
>>>>>> currently done in DTN Ref Implementation (which is direct  
>>>>>> string  matching or at most wildcard expansion). This is  
>>>>>> because it is  unlikely that an application will register  
>>>>>> itself with the same  EID as the intentionally named query.  
>>>>>> Instead the app will  register itself with some other EID and  
>>>>>> a matching service  (external or internal to the the BPA) will  
>>>>>> determine which  registered apps on the current node match the  
>>>>>> incoming  destination name query, and the BPA should deliver  
>>>>>> the bundle to  those apps only. In order to perform this  
>>>>>> matching, one may have  to look up knowledge bases or even  
>>>>>> perform non-trivial  computations (as in case of the "nearest"  
>>>>>> example above).
>>>>>>
>>>>>> More details about the scheme and architecture will be  
>>>>>> available  in the forthcoming Internet Draft submission but I  
>>>>>> thought that I  should give the higher order bits here. Let me  
>>>>>> know if you or  others have any questions or thoughts related  
>>>>>> to this.
>>>>>>
>>>>>> best regards,
>>>>>> -Prithwish
>>>>>>
>>>>>>
>>>>>> Stephen Farrell wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> As part of the BP spec review we've gotten a couple of
>>>>>>> requests for a formal definition of the dtn: URI scheme.
>>>>>>>
>>>>>>> Its not going to hold up the BP RFC, but would anyone
>>>>>>> take on the job of trying to write such a definition?
>>>>>>>
>>>>>>> To be honest, it might be a bit of work getting the
>>>>>>> definition into the right shape to keep all the various
>>>>>>> people here and in the URI-police happy, but if we
>>>>>>> don't do it, I guess we've a serious prospect of ending
>>>>>>> up with conflicting uses of dtn:<<foo>>
>>>>>>>
>>>>>>> S.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dtn-interest mailing list
>>>>>>> [email-masked]
>>>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dtn-interest mailing list
>>>>>> [email-masked]
>>>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Thu, 26 Jul 2007 10:25:21 -0500
From: Joerg Ott <[email-masked]>
To: [email-masked]
CC: Michael Demmer <[email-masked]>, Prithwish Basu <[email-masked]>, Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

Stephen,

I should try to finally get our application draft submitted
as this contains some additional discussion which could serve
as input.

Joerg

> Stephen,
> 
> How urgent is the I-D on DTN naming?   Can this happen, say, after
> mid-September (when we have our big demo)?
> 
> Best Regards,
> Rajesh
> 
> On Thu, 2007-07-26 at 08:06 -0700, Michael Demmer wrote:
> 
>>You're assuming that I have a writeup :-)
>>
>>I'm also too swamped to take the lead on this now, maybe in a couple  
>>weeks I could do it.
>>
>>-m
>>
>>On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:
>>
>>
>>>Hi Stephen,
>>>
>>>Sure, I can work with Mike to document the use case but  
>>>unfortunately I am too swamped at the moment to take the lead on this.
>>>
>>>Mike, you can send me your writeup and I can add our use case to it.
>>>
>>>thanks,
>>>-Prithwish
>>>
>>>Stephen Farrell wrote:
>>>
>>>>Hi Prithwish,
>>>>
>>>>Sounds interesting. If you were willing to work with Mike
>>>>to document your and his uses of dtn: (and others that turn
>>>>up), that'd be great.
>>>>
>>>>That's probably not exactly the I-D you've been planning, but
>>>>be great if you could help us make progress with this,
>>>>
>>>>Cheers,
>>>>S.
>>>>
>>>>Prithwish Basu wrote:
>>>>
>>>>>Hi Stephen,
>>>>>
>>>>>We have been working on an intentional naming scheme for DTN as  
>>>>>part of the DARPA DTN project. We plan to submit an Internet  
>>>>>Draft about intentional names in a month or two but here is a  
>>>>>quick summary which I thought may be relevant to this discussion  
>>>>>(Mike knows a bit about this).
>>>>>
>>>>>We are planning to propose a subscheme for dtn: called  
>>>>>"dtn:intent" which captures the intentional  name of a resource  
>>>>>accessible over the DTN network. A name query is essentially a  
>>>>>multicast or anycast address specified in the destination field  
>>>>>of a bundle. Examples include:
>>>>>   - dtn:intent:all?nearest(5,restaurant,FenwayPark) has  
>>>>>semantics of "deliver bundle to ALL DTN nodes representing the 5  
>>>>>nearest restaurants to Fenway Park
>>>>>   - dtn:intent:any?nearest(5,restaurant,FenwayPark) has  
>>>>>semantics of "deliver bundle to ANY of the DTN nodes representing  
>>>>>the 5 nearest restaurants to Fenway Park"
>>>>>
>>>>>Note that these are valid URIs where the optional "//authority"  
>>>>>part is not used but the "path" and "query" parts are used.  
>>>>>(according to RFC 3986 jargon) The syntax of the query part of  
>>>>>the intentional name is open. We are currently working with  
>>>>>something that looks like Horn clause predicates or a sequence of  
>>>>>attribute=value pairs.
>>>>>
>>>>>As an auxiliary note: the matching of registered endpoints to  
>>>>>such intentionally named endpoints is different from what is  
>>>>>currently done in DTN Ref Implementation (which is direct string  
>>>>>matching or at most wildcard expansion). This is because it is  
>>>>>unlikely that an application will register itself with the same  
>>>>>EID as the intentionally named query. Instead the app will  
>>>>>register itself with some other EID and a matching service  
>>>>>(external or internal to the the BPA) will determine which  
>>>>>registered apps on the current node match the incoming  
>>>>>destination name query, and the BPA should deliver the bundle to  
>>>>>those apps only. In order to perform this matching, one may have  
>>>>>to look up knowledge bases or even perform non-trivial  
>>>>>computations (as in case of the "nearest" example above).
>>>>>
>>>>>More details about the scheme and architecture will be available  
>>>>>in the forthcoming Internet Draft submission but I thought that I  
>>>>>should give the higher order bits here. Let me know if you or  
>>>>>others have any questions or thoughts related to this.
>>>>>
>>>>>best regards,
>>>>>-Prithwish
>>>>>
>>>>>
>>>>>Stephen Farrell wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>As part of the BP spec review we've gotten a couple of
>>>>>>requests for a formal definition of the dtn: URI scheme.
>>>>>>
>>>>>>Its not going to hold up the BP RFC, but would anyone
>>>>>>take on the job of trying to write such a definition?
>>>>>>
>>>>>>To be honest, it might be a bit of work getting the
>>>>>>definition into the right shape to keep all the various
>>>>>>people here and in the URI-police happy, but if we
>>>>>>don't do it, I guess we've a serious prospect of ending
>>>>>>up with conflicting uses of dtn:<<foo>>
>>>>>>
>>>>>>S.
>>>>>>
>>>>>>_______________________________________________
>>>>>>dtn-interest mailing list
>>>>>>[email-masked]
>>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>dtn-interest mailing list
>>>>>[email-masked]
>>>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>>
>>>>
>>>_______________________________________________
>>>dtn-interest mailing list
>>>[email-masked]
>>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Subject: Re: [dtn-interest] defining dtn:
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: Michael Demmer <[email-masked]>
Cc: Prithwish Basu <[email-masked]>, Stephen Farrell <[email-masked]>, DTN <[email-masked]>
Organization: BBN Technologies
Date: Thu, 26 Jul 2007 11:13:40 -0400
Sender: [email-masked]

Stephen,

How urgent is the I-D on DTN naming?   Can this happen, say, after
mid-September (when we have our big demo)?

Best Regards,
Rajesh

On Thu, 2007-07-26 at 08:06 -0700, Michael Demmer wrote:
> You're assuming that I have a writeup :-)
> 
> I'm also too swamped to take the lead on this now, maybe in a couple  
> weeks I could do it.
> 
> -m
> 
> On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:
> 
> > Hi Stephen,
> >
> > Sure, I can work with Mike to document the use case but  
> > unfortunately I am too swamped at the moment to take the lead on this.
> >
> > Mike, you can send me your writeup and I can add our use case to it.
> >
> > thanks,
> > -Prithwish
> >
> > Stephen Farrell wrote:
> >>
> >> Hi Prithwish,
> >>
> >> Sounds interesting. If you were willing to work with Mike
> >> to document your and his uses of dtn: (and others that turn
> >> up), that'd be great.
> >>
> >> That's probably not exactly the I-D you've been planning, but
> >> be great if you could help us make progress with this,
> >>
> >> Cheers,
> >> S.
> >>
> >> Prithwish Basu wrote:
> >>> Hi Stephen,
> >>>
> >>> We have been working on an intentional naming scheme for DTN as  
> >>> part of the DARPA DTN project. We plan to submit an Internet  
> >>> Draft about intentional names in a month or two but here is a  
> >>> quick summary which I thought may be relevant to this discussion  
> >>> (Mike knows a bit about this).
> >>>
> >>> We are planning to propose a subscheme for dtn: called  
> >>> "dtn:intent" which captures the intentional  name of a resource  
> >>> accessible over the DTN network. A name query is essentially a  
> >>> multicast or anycast address specified in the destination field  
> >>> of a bundle. Examples include:
> >>>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has  
> >>> semantics of "deliver bundle to ALL DTN nodes representing the 5  
> >>> nearest restaurants to Fenway Park
> >>>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has  
> >>> semantics of "deliver bundle to ANY of the DTN nodes representing  
> >>> the 5 nearest restaurants to Fenway Park"
> >>>
> >>> Note that these are valid URIs where the optional "//authority"  
> >>> part is not used but the "path" and "query" parts are used.  
> >>> (according to RFC 3986 jargon) The syntax of the query part of  
> >>> the intentional name is open. We are currently working with  
> >>> something that looks like Horn clause predicates or a sequence of  
> >>> attribute=value pairs.
> >>>
> >>> As an auxiliary note: the matching of registered endpoints to  
> >>> such intentionally named endpoints is different from what is  
> >>> currently done in DTN Ref Implementation (which is direct string  
> >>> matching or at most wildcard expansion). This is because it is  
> >>> unlikely that an application will register itself with the same  
> >>> EID as the intentionally named query. Instead the app will  
> >>> register itself with some other EID and a matching service  
> >>> (external or internal to the the BPA) will determine which  
> >>> registered apps on the current node match the incoming  
> >>> destination name query, and the BPA should deliver the bundle to  
> >>> those apps only. In order to perform this matching, one may have  
> >>> to look up knowledge bases or even perform non-trivial  
> >>> computations (as in case of the "nearest" example above).
> >>>
> >>> More details about the scheme and architecture will be available  
> >>> in the forthcoming Internet Draft submission but I thought that I  
> >>> should give the higher order bits here. Let me know if you or  
> >>> others have any questions or thoughts related to this.
> >>>
> >>> best regards,
> >>> -Prithwish
> >>>
> >>>
> >>> Stephen Farrell wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> As part of the BP spec review we've gotten a couple of
> >>>> requests for a formal definition of the dtn: URI scheme.
> >>>>
> >>>> Its not going to hold up the BP RFC, but would anyone
> >>>> take on the job of trying to write such a definition?
> >>>>
> >>>> To be honest, it might be a bit of work getting the
> >>>> definition into the right shape to keep all the various
> >>>> people here and in the URI-police happy, but if we
> >>>> don't do it, I guess we've a serious prospect of ending
> >>>> up with conflicting uses of dtn:<<foo>>
> >>>>
> >>>> S.
> >>>>
> >>>> _______________________________________________
> >>>> dtn-interest mailing list
> >>>> [email-masked]
> >>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>>
> >>>
> >>> _______________________________________________
> >>> dtn-interest mailing list
> >>> [email-masked]
> >>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >>>
> >>
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Cc: Stephen Farrell <[email-masked]>, DTN <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Date: Thu, 26 Jul 2007 08:06:35 -0700
To: Prithwish Basu <[email-masked]>
Sender: [email-masked]

You're assuming that I have a writeup :-)

I'm also too swamped to take the lead on this now, maybe in a couple  
weeks I could do it.

-m

On Jul 26, 2007, at 8:00 AM, Prithwish Basu wrote:

> Hi Stephen,
>
> Sure, I can work with Mike to document the use case but  
> unfortunately I am too swamped at the moment to take the lead on this.
>
> Mike, you can send me your writeup and I can add our use case to it.
>
> thanks,
> -Prithwish
>
> Stephen Farrell wrote:
>>
>> Hi Prithwish,
>>
>> Sounds interesting. If you were willing to work with Mike
>> to document your and his uses of dtn: (and others that turn
>> up), that'd be great.
>>
>> That's probably not exactly the I-D you've been planning, but
>> be great if you could help us make progress with this,
>>
>> Cheers,
>> S.
>>
>> Prithwish Basu wrote:
>>> Hi Stephen,
>>>
>>> We have been working on an intentional naming scheme for DTN as  
>>> part of the DARPA DTN project. We plan to submit an Internet  
>>> Draft about intentional names in a month or two but here is a  
>>> quick summary which I thought may be relevant to this discussion  
>>> (Mike knows a bit about this).
>>>
>>> We are planning to propose a subscheme for dtn: called  
>>> "dtn:intent" which captures the intentional  name of a resource  
>>> accessible over the DTN network. A name query is essentially a  
>>> multicast or anycast address specified in the destination field  
>>> of a bundle. Examples include:
>>>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has  
>>> semantics of "deliver bundle to ALL DTN nodes representing the 5  
>>> nearest restaurants to Fenway Park
>>>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has  
>>> semantics of "deliver bundle to ANY of the DTN nodes representing  
>>> the 5 nearest restaurants to Fenway Park"
>>>
>>> Note that these are valid URIs where the optional "//authority"  
>>> part is not used but the "path" and "query" parts are used.  
>>> (according to RFC 3986 jargon) The syntax of the query part of  
>>> the intentional name is open. We are currently working with  
>>> something that looks like Horn clause predicates or a sequence of  
>>> attribute=value pairs.
>>>
>>> As an auxiliary note: the matching of registered endpoints to  
>>> such intentionally named endpoints is different from what is  
>>> currently done in DTN Ref Implementation (which is direct string  
>>> matching or at most wildcard expansion). This is because it is  
>>> unlikely that an application will register itself with the same  
>>> EID as the intentionally named query. Instead the app will  
>>> register itself with some other EID and a matching service  
>>> (external or internal to the the BPA) will determine which  
>>> registered apps on the current node match the incoming  
>>> destination name query, and the BPA should deliver the bundle to  
>>> those apps only. In order to perform this matching, one may have  
>>> to look up knowledge bases or even perform non-trivial  
>>> computations (as in case of the "nearest" example above).
>>>
>>> More details about the scheme and architecture will be available  
>>> in the forthcoming Internet Draft submission but I thought that I  
>>> should give the higher order bits here. Let me know if you or  
>>> others have any questions or thoughts related to this.
>>>
>>> best regards,
>>> -Prithwish
>>>
>>>
>>> Stephen Farrell wrote:
>>>>
>>>> Hi,
>>>>
>>>> As part of the BP spec review we've gotten a couple of
>>>> requests for a formal definition of the dtn: URI scheme.
>>>>
>>>> Its not going to hold up the BP RFC, but would anyone
>>>> take on the job of trying to write such a definition?
>>>>
>>>> To be honest, it might be a bit of work getting the
>>>> definition into the right shape to keep all the various
>>>> people here and in the URI-police happy, but if we
>>>> don't do it, I guess we've a serious prospect of ending
>>>> up with conflicting uses of dtn:<<foo>>
>>>>
>>>> S.
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 26 Jul 2007 11:00:40 -0400
From: Prithwish Basu <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

Hi Stephen,

Sure, I can work with Mike to document the use case but unfortunately I 
am too swamped at the moment to take the lead on this.

Mike, you can send me your writeup and I can add our use case to it.

thanks,
-Prithwish

Stephen Farrell wrote:
>
> Hi Prithwish,
>
> Sounds interesting. If you were willing to work with Mike
> to document your and his uses of dtn: (and others that turn
> up), that'd be great.
>
> That's probably not exactly the I-D you've been planning, but
> be great if you could help us make progress with this,
>
> Cheers,
> S.
>
> Prithwish Basu wrote:
>> Hi Stephen,
>>
>> We have been working on an intentional naming scheme for DTN as part 
>> of the DARPA DTN project. We plan to submit an Internet Draft about 
>> intentional names in a month or two but here is a quick summary which 
>> I thought may be relevant to this discussion (Mike knows a bit about 
>> this).
>>
>> We are planning to propose a subscheme for dtn: called "dtn:intent" 
>> which captures the intentional  name of a resource accessible over 
>> the DTN network. A name query is essentially a multicast or anycast 
>> address specified in the destination field of a bundle. Examples 
>> include:
>>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has semantics of 
>> "deliver bundle to ALL DTN nodes representing the 5 nearest 
>> restaurants to Fenway Park
>>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has semantics of 
>> "deliver bundle to ANY of the DTN nodes representing the 5 nearest 
>> restaurants to Fenway Park"
>>
>> Note that these are valid URIs where the optional "//authority" part 
>> is not used but the "path" and "query" parts are used. (according to 
>> RFC 3986 jargon) The syntax of the query part of the intentional name 
>> is open. We are currently working with something that looks like Horn 
>> clause predicates or a sequence of attribute=value pairs.
>>
>> As an auxiliary note: the matching of registered endpoints to such 
>> intentionally named endpoints is different from what is currently 
>> done in DTN Ref Implementation (which is direct string matching or at 
>> most wildcard expansion). This is because it is unlikely that an 
>> application will register itself with the same EID as the 
>> intentionally named query. Instead the app will register itself with 
>> some other EID and a matching service (external or internal to the 
>> the BPA) will determine which registered apps on the current node 
>> match the incoming destination name query, and the BPA should deliver 
>> the bundle to those apps only. In order to perform this matching, one 
>> may have to look up knowledge bases or even perform non-trivial 
>> computations (as in case of the "nearest" example above).
>>
>> More details about the scheme and architecture will be available in 
>> the forthcoming Internet Draft submission but I thought that I should 
>> give the higher order bits here. Let me know if you or others have 
>> any questions or thoughts related to this.
>>
>> best regards,
>> -Prithwish
>>
>>
>> Stephen Farrell wrote:
>>>
>>> Hi,
>>>
>>> As part of the BP spec review we've gotten a couple of
>>> requests for a formal definition of the dtn: URI scheme.
>>>
>>> Its not going to hold up the BP RFC, but would anyone
>>> take on the job of trying to write such a definition?
>>>
>>> To be honest, it might be a bit of work getting the
>>> definition into the right shape to keep all the various
>>> people here and in the URI-police happy, but if we
>>> don't do it, I guess we've a serious prospect of ending
>>> up with conflicting uses of dtn:<<foo>>
>>>
>>> S.
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>

Cc: dtn-interest <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Re: comparing protocols for reliability etc.
Date: Thu, 26 Jul 2007 07:40:00 -0700
To: Darren Long <[email-masked]>
Sender: [email-masked]

My instinct is that since we're going ahead with a definition for a  
hop-by-hop checksum only bundle authentication block, then we don't  
_need_ additional convergence-layer specific mechanisms for data  
integrity beyond what's provided by the lower transport layers.

This saves us the trouble (and potential errors) of defining and  
implementing specific checksum algorithms for each convergence layer.

-mike

>> I posted a few days ago amongst the turmoil of the recent paper
>> regarding data integrity.  Curiously, there have been no responses.
>> Hasn't anyone any comments?  If I'm very off plot, I'd hope someone
>> would put me straight.  Otherwise, I'm hoping someone might agree.
>
> Darren - you're not off plot. Many of us have travelled to the IETF  
> in Chicago, so the stuff related to in-the-room discussion has  
> taken precedence.
>
> IP fragmentation is unlikely because these convergence layers are  
> usually only supposed to travel one hop across a local link, and in  
> those scenarios they will know and use the local link MTU.  
> (Protecting against errors in lower layers segmenting and  
> reassembling packets is something I would be concerned about.)  For  
> a convergence layer that can traverse the public Internet - TCP has  
> Path MTU discovery to avoid fragmentation. Also, intermediate  
> fragmentation is avoided in the IPv6 design. Weakness of the one's- 
> complement checksum with large MTUs (especially jumbograms) is  
> another issue.
>
> We've spent a lot of time on the list discussing reliability to  
> catch residual errors - I certainly think that if a convergence  
> layer is advertised as "reliable" it should at least make an  
> attempt to catch all errors - and that's why we added the MD5  
> integrity checksum in Saratoga, to provide an attempt at an e2e  
> checksum to help applications that don't check what they receive.  
> This means that Saratoga can provide a better, more reliable UDP- 
> based convergence layer.
>
> The bundle protocol should imo always be reliable in both framing  
> and payload content, which it currently isn't - something there has  
> been much discussion of here in Chicago, post our payload checksum  
> block draft.
>
> L.
>
> http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>
> ===
> Hi all,
>
> I find this to be an interesting topic of discussion, and I can't
> help but chip in with some comments of my own.
>
> One possible concern that isn't addresses in the paper is the degree
> of error detection capability in the implemented CLs in the DTN2
> reference implementation.  I'm thinking specifically of the TCP and
> UDP CLs.
>
> In the UDP CL implementation, bundles are accepted for transmission
> up to the maximum UDP datagram size (64kB).  With typical link MTU
> sizes, this bundle/datagram would undergo IP fragmentation, which is
> apparently to be considered "very harmful" to data integrity in the
> "right" circumstances.
>
> Is it the intention to resort to bundle protocol extensions to handle
> the detection of residual errors above the CL, or should there be
> strong enough mechanisms in the CL itself?
>
> Similarly, the TCP CL implementation provides no additional error
> detection mechanisms above TCP itself, which suffers from the same
> check-summing weakness as UDP.  My concern with the TCP CL relates to
> TCP operation over routes bisected with TCP PEPs.  There are PILC
> documents that describe the potential impact of TCP PEPs to the
> end-to-end assumption of TCP, and coupling this with the additional
> potential for the PEPs to inject errors undetectable by the TCP/IP
> stack suggest to me that additional integrity checking should be
> provided in the CL, where I believe more efficient recovery options
> are available.
>
> I wonder what others think?
>
> Cheers,
>
> Darren
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 26 Jul 2007 10:30:51 -0400
From: Wesley Eddy <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: Peter Lovell <[email-masked]>, Stephen Farrell <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: Re(2): [dtn-interest] New bundle internet draft and paper   comparing protocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Jul 26, 2007 at 05:29:48AM +0100, Lloyd Wood wrote:
> 
> IPsec encapsulating tunnels have to do this for all TCP/UDP and IP header checksums, SCTP CRCs... the list of checksums passing through encryption goes on. And, for link-level crypto, it's something that's pretty much unavoidable, as higher layers will have checksums for reliability.
> 
> Is this a real concern? (As in, are there known attacks on IPsec and tunnelled IP headers using the position of the header's one's-complement checksum? And are the one's-complement checksum's weaknesses - not detecting reordering - suddenly a strength in making attacks harder?)

The matter of distinction is whether the plaintext's checksums are
encapsulated within the confidentiality-protected bits or whether
they're retained in the clear, I believe.  This doesn't seem
unmanageable for bundle security.  In IPsec ESP tunnels the inner UDP
checksum (giving clues about the data) and the inner IP checksum (giving
traffic analysis clues) are both covered by the confidentiality
transform.  In transport-mode IPsec, the UDP checksum is within the
confidentiality transform.  The optional ICV transforms that can be used
with ESP are all keyed (MACs rather than simple checksums), to my
knowledge, so without the key, they couldn't reveal anything about the
protected data, AND they're specified to run over the already-encrypted
data anyways.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Cc: Lloyd Wood <[email-masked]>, Stephen Farrell <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: Re(2): [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Date: Thu, 26 Jul 2007 07:30:38 -0700
To: Peter Lovell <[email-masked]>
Sender: [email-masked]

>> I'm talking about a convergence-layer checksum over the whole bundle.
>> The convergence layer is the natural place to provide a hop-by-hop
>> checksum of a bundle -- particularly since the bundle contents can be
>> mutable with blocks added etc. at each hop.
>
> Well, this is just BundleAuthentication with a different algorithm
> instead of the HMAC defined for BA1. Nothing more. Since BA is always
> done last, by definition, the security-result won't be encrypted. This
> is a strictly hop-by-hop thing, as opposed to PS which can be end-to-
> end, or gateway-to-gateway etc.

When we were talking about this the other day, I remembered  
discussion of the need for two types of checksums.

An end-to-end checksum would cover the payload and non-mutable  
metadata, such as the source/destination/reply-to endpoint ids, the  
expiration time, class of service bits, etc. This would use the  
Payload Security Block mechanism as spec'd in the BSP. The payload  
would be checksummed exactly as it's supplied by the application,  
that is, in plaintext. This checksum would be validated by the bundle  
agent before delivering to the application, though it could also be  
supplied to the applications themselves so they could validate that  
the bundle agent to application interface didn't muck anything up.

Then there's also a need for a hop-by-hop checksum which would use  
the Bundle Authentication Block as you mentioned above.

Both features are optional, and both could be used independently or  
together in different deployment scenarios.

-mike

Date: Thu, 26 Jul 2007 10:10:35 -0400
From: Wesley Eddy <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Stephen Farrell <[email-masked]>, Lloyd Wood <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: Re(2): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 25, 2007 at 10:11:18PM -0400, Peter Lovell wrote:
> 
> For the new spec, assuming we make a BSP-lite change in the BSP spec
> itself, Wes can just define a PSB ciphersuite with a suitable checksum
> algorithm and mutable canonicalization. For example, the
> canonicalization suggested in the draft is just the payload - real simple. 
> 

This sounds like a good basis for moving forward to me.  Thanks for your
help.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: "Peter Lovell" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>, "Peter Lovell" <[email-masked]>
Subject: Re(3): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Date: Thu, 26 Jul 2007 08:28:46 -0400
Sender: [email-masked]

On Thu, Jul 26, 2007, Lloyd Wood <[email-masked]> wrote:

>At Wednesday 25/07/2007 22:26 -0400, Peter Lovell wrote:
>>On Thu, Jul 26, 2007, Lloyd Wood <[email-masked]> wrote:
>>[..]
>>>>Also, just occurs to me that the BP checksum should probably be
>>>>encrypted if the bundle is, right? 
>>>
>>>Susan has already raised much the same point in her email of Tuesday
>>>24th. The answer is no.
>>>
>>>You simply encrypt first, then checksum the encrypted content. This is
>>>also most easily done by the convergence layer, which only ever sees the
>>>encrypted output.
>>
>>That depends. In a hop-by-hop convergence-layer scheme,it's like BAB
>>(above). However, if the checksum is end-to-end then the sender would
>>create the checksum on the plaintext, and send the checksum and
>>plaintext data on its way. If the bundle passes through a gateway which
>>encrypts the data, unaware of the checksum, then you have encrypted
>>payload and a checksum of the plaintext. Not so good.
>
>IPsec encapsulating tunnels have to do this for all TCP/UDP and IP
>header checksums, SCTP CRCs... the list of checksums passing through
>encryption goes on. And, for link-level crypto, it's something that's
>pretty much unavoidable, as higher layers will have checksums for
reliability.
>
>Is this a real concern? (As in, are there known attacks on IPsec and
>tunnelled IP headers using the position of the header's one's-complement
>checksum? And are the one's-complement checksum's weaknesses - not
>detecting reordering - suddenly a strength in making attacks harder?)

Hi Lloyd,

There are known exploits against IPSec using position of certain fields
in the header. At present I don't recall it it's the checksum or not.

The recommendation is to encrypt first and then checksum the ciphertext,
which is what we do now for C3 (confidentiality ciphersuite #3, using
AES-GCM as we discussed in Dublin). 

If payload security is being done also, C3 encrypts the signature if
it's over the plaintext.

Regards.....Peter

Date: Thu, 26 Jul 2007 12:45:08 +0100
To: [email-masked], Stephen Farrell <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocolsforreliability errored delivery.
Cc: [email-masked]
Sender: [email-masked]

At Wednesday 25/07/2007 09:35 -0400, Wesley Eddy wrote:
>On Wed, Jul 25, 2007 at 02:14:50PM +0100, Stephen Farrell wrote:
>> >
>> >As for the text above "Choosing something with no claimed security 
>> >properties
>> >means you're declaring that you don't care."  YES!  We don't care; it's
>> >someone else's job!  Leave security services to the realm of the
>> >security services ... we were only setting the cross-hairs on catching
>> >innocent mistakes.
>> 
>> And making one in the process:-) Any use of MD5 creates a known
>> vulnerability that is avoided by a different alg (HMAC in this case)
>> and will at minimum allow people to create FUD. If you just pick
>> a CRC then you won't be criticised in that respect since you won't
>> be perceived to be making the mistake of choosing an algorithm with
>> known security deficiencies (since it makes no security claims).
>
>So the reasoning is psychological for the sake of reviewers rather than
>technological for the sake of the protocol and its implementations :).

...and, as such, is technically speaking bogus.

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

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

Date: Thu, 26 Jul 2007 06:28:26 +0100
From: Stephen Farrell <[email-masked]>
To: Prithwish Basu <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

Hi Prithwish,

Sounds interesting. If you were willing to work with Mike
to document your and his uses of dtn: (and others that turn
up), that'd be great.

That's probably not exactly the I-D you've been planning, but
be great if you could help us make progress with this,

Cheers,
S.

Prithwish Basu wrote:
> Hi Stephen,
> 
> We have been working on an intentional naming scheme for DTN as part of 
> the DARPA DTN project. We plan to submit an Internet Draft about 
> intentional names in a month or two but here is a quick summary which I 
> thought may be relevant to this discussion (Mike knows a bit about this).
> 
> We are planning to propose a subscheme for dtn: called "dtn:intent" 
> which captures the intentional  name of a resource accessible over the 
> DTN network. A name query is essentially a multicast or anycast address 
> specified in the destination field of a bundle. Examples include:
>    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has semantics of 
> "deliver bundle to ALL DTN nodes representing the 5 nearest restaurants 
> to Fenway Park
>    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has semantics of 
> "deliver bundle to ANY of the DTN nodes representing the 5 nearest 
> restaurants to Fenway Park"
> 
> Note that these are valid URIs where the optional "//authority" part is 
> not used but the "path" and "query" parts are used. (according to RFC 
> 3986 jargon) The syntax of the query part of the intentional name is 
> open. We are currently working with something that looks like Horn 
> clause predicates or a sequence of attribute=value pairs.
> 
> As an auxiliary note: the matching of registered endpoints to such 
> intentionally named endpoints is different from what is currently done 
> in DTN Ref Implementation (which is direct string matching or at most 
> wildcard expansion). This is because it is unlikely that an application 
> will register itself with the same EID as the intentionally named query. 
> Instead the app will register itself with some other EID and a matching 
> service (external or internal to the the BPA) will determine which 
> registered apps on the current node match the incoming destination name 
> query, and the BPA should deliver the bundle to those apps only. In 
> order to perform this matching, one may have to look up knowledge bases 
> or even perform non-trivial computations (as in case of the "nearest" 
> example above).
> 
> More details about the scheme and architecture will be available in the 
> forthcoming Internet Draft submission but I thought that I should give 
> the higher order bits here. Let me know if you or others have any 
> questions or thoughts related to this.
> 
> best regards,
> -Prithwish
> 
> 
> Stephen Farrell wrote:
>>
>> Hi,
>>
>> As part of the BP spec review we've gotten a couple of
>> requests for a formal definition of the dtn: URI scheme.
>>
>> Its not going to hold up the BP RFC, but would anyone
>> take on the job of trying to write such a definition?
>>
>> To be honest, it might be a bit of work getting the
>> definition into the right shape to keep all the various
>> people here and in the URI-police happy, but if we
>> don't do it, I guess we've a serious prospect of ending
>> up with conflicting uses of dtn:<<foo>>
>>
>> S.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Thu, 26 Jul 2007 01:10:29 -0400
From: Prithwish Basu <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

Hi Stephen,

We have been working on an intentional naming scheme for DTN as part of 
the DARPA DTN project. We plan to submit an Internet Draft about 
intentional names in a month or two but here is a quick summary which I 
thought may be relevant to this discussion (Mike knows a bit about this).

We are planning to propose a subscheme for dtn: called "dtn:intent" 
which captures the intentional  name of a resource accessible over the 
DTN network. A name query is essentially a multicast or anycast address 
specified in the destination field of a bundle. Examples include:
    - dtn:intent:all?nearest(5,restaurant,FenwayPark) has semantics of 
"deliver bundle to ALL DTN nodes representing the 5 nearest restaurants 
to Fenway Park
    - dtn:intent:any?nearest(5,restaurant,FenwayPark) has semantics of 
"deliver bundle to ANY of the DTN nodes representing the 5 nearest 
restaurants to Fenway Park"

Note that these are valid URIs where the optional "//authority" part is 
not used but the "path" and "query" parts are used. (according to RFC 
3986 jargon) The syntax of the query part of the intentional name is 
open. We are currently working with something that looks like Horn 
clause predicates or a sequence of attribute=value pairs.

As an auxiliary note: the matching of registered endpoints to such 
intentionally named endpoints is different from what is currently done 
in DTN Ref Implementation (which is direct string matching or at most 
wildcard expansion). This is because it is unlikely that an application 
will register itself with the same EID as the intentionally named query. 
Instead the app will register itself with some other EID and a matching 
service (external or internal to the the BPA) will determine which 
registered apps on the current node match the incoming destination name 
query, and the BPA should deliver the bundle to those apps only. In 
order to perform this matching, one may have to look up knowledge bases 
or even perform non-trivial computations (as in case of the "nearest" 
example above).

More details about the scheme and architecture will be available in the 
forthcoming Internet Draft submission but I thought that I should give 
the higher order bits here. Let me know if you or others have any 
questions or thoughts related to this.

best regards,
-Prithwish

Stephen Farrell wrote:
>
> Hi,
>
> As part of the BP spec review we've gotten a couple of
> requests for a formal definition of the dtn: URI scheme.
>
> Its not going to hold up the BP RFC, but would anyone
> take on the job of trying to write such a definition?
>
> To be honest, it might be a bit of work getting the
> definition into the right shape to keep all the various
> people here and in the URI-police happy, but if we
> don't do it, I guess we've a serious prospect of ending
> up with conflicting uses of dtn:<<foo>>
>
> S.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Thu, 26 Jul 2007 05:58:59 +0100
To: Stephen Farrell <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparing protocols for reliability errored delivery.
Cc: [email-masked]
Sender: [email-masked]

At Thursday 26/07/2007 03:52 +0100, Stephen Farrell wrote:

>Lloyd Wood wrote:
>>(It's possible to actually think about this stuff rationally without raising completely bogus security fears all the time, you know. You should try it.)
>
>Various people should try various things. I generally count
>politeness amongst them, you seemingly don't, so I discount
>lots of what you say.

Sorry, taking that position here is unfortunately incompatible with your responsibilities as workgroup chair.

On this list, I don't know how many times one can _politely_ say 'Read Saltzer's and Stone's papers' as various arguments for not needing end-to-end checks are brought up by others. Outside this list, I suppose I could wonder if you thought I was sufficiently polite when I explained how TCP _actually_ breaks... but the facts and the technical merits of the points made would, alas, remain unchanged by your opinion. (And, frankly, since such points about TCP are not at all security-related, they obviously hold no interest for you).

I believe that a workgroup chair should focus on the technical merits.

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

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

Date: Thu, 26 Jul 2007 05:29:48 +0100
To: "Peter Lovell" <[email-masked]>, "Stephen Farrell" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re(2): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Cc: "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>, "Peter Lovell" <[email-masked]>
Sender: [email-masked]

At Wednesday 25/07/2007 22:26 -0400, Peter Lovell wrote:
>On Thu, Jul 26, 2007, Lloyd Wood <[email-masked]> wrote:
>[..]
>>>Also, just occurs to me that the BP checksum should probably be
>>>encrypted if the bundle is, right? 
>>
>>Susan has already raised much the same point in her email of Tuesday
>>24th. The answer is no.
>>
>>You simply encrypt first, then checksum the encrypted content. This is
>>also most easily done by the convergence layer, which only ever sees the
>>encrypted output.
>
>That depends. In a hop-by-hop convergence-layer scheme,it's like BAB
>(above). However, if the checksum is end-to-end then the sender would
>create the checksum on the plaintext, and send the checksum and
>plaintext data on its way. If the bundle passes through a gateway which
>encrypts the data, unaware of the checksum, then you have encrypted
>payload and a checksum of the plaintext. Not so good.

IPsec encapsulating tunnels have to do this for all TCP/UDP and IP header checksums, SCTP CRCs... the list of checksums passing through encryption goes on. And, for link-level crypto, it's something that's pretty much unavoidable, as higher layers will have checksums for reliability.

Is this a real concern? (As in, are there known attacks on IPsec and tunnelled IP headers using the position of the header's one's-complement checksum? And are the one's-complement checksum's weaknesses - not detecting reordering - suddenly a strength in making attacks harder?)

thanks,

L. 

Date: Thu, 26 Jul 2007 03:55:58 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: Lloyd Wood <[email-masked]>, Darren Long <[email-masked]>, dtn interest <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

Peter Lovell wrote:
> The current problem is that if you touch BSP at all, then you *must*
> support the mandatory ciphersuites. 

I don't think that that's necessary. All we have to do is document
the new ciphersuite separately with its own conformance statements
and then you're done. Your code simply conforms to a different pair
of RFCs (in that case the BP and checksum RFCs).

You do still have to consider encryption of any checksum over the
plaintext, which is a pita.

Even if it were done in a single document you could include two
profiles with seprate conformance statements though I dislike that
for various reasons.

S.

Date: Thu, 26 Jul 2007 03:52:33 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparing protocols for reliability errored delivery.
Sender: [email-masked]

Lloyd Wood wrote:

> (It's possible to actually think about this stuff rationally without raising completely bogus security fears all the time, you know. You should try it.)

Various people should try various things. I generally count
politeness amongst them, you seemingly don't, so I discount
lots of what you say.

S.

From: "Peter Lovell" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>, "Peter Lovell" <[email-masked]>
Subject: Re(2): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Date: Wed, 25 Jul 2007 22:26:30 -0400
Sender: [email-masked]

On Thu, Jul 26, 2007, Lloyd Wood <[email-masked]> wrote:

>At Thursday 26/07/2007 01:21 +0100, Stephen Farrell wrote:
>>Lloyd Wood wrote:
>>>At Thursday 26/07/2007 00:53 +0100, Stephen Farrell wrote:
>>>>I guess a CL checksum will result in the errors being more quickly
>>>>detected in a few cases (e.g. with fragmentation) 
>>>As bundles are carried by hop-by-hop transfers, you'll know whether a
>bundle is corrupted at the receiving node or not. 
>>
>>If a bundle is reactively fragmented and if the BP checksum covers
>>all the payload of the original bundle then a CL checksum might
>>catch the error earlier.
>>
>>Or it might be better to do the BP checksum only hop-by-hop, or
>>have two (one e2e, one per-hop), I'm not sure what you intended.
>
>I'm talking about a convergence-layer checksum over the whole bundle.
>The convergence layer is the natural place to provide a hop-by-hop
>checksum of a bundle -- particularly since the bundle contents can be
>mutable with blocks added etc. at each hop.

Well, this is just BundleAuthentication with a different algorithm
instead of the HMAC defined for BA1. Nothing more. Since BA is always
done last, by definition, the security-result won't be encrypted. This
is a strictly hop-by-hop thing, as opposed to PS which can be end-to-
end, or gateway-to-gateway etc.

>>Also, just occurs to me that the BP checksum should probably be
>>encrypted if the bundle is, right? 
>
>Susan has already raised much the same point in her email of Tuesday
>24th. The answer is no.
>
>You simply encrypt first, then checksum the encrypted content. This is
>also most easily done by the convergence layer, which only ever sees the
>encrypted output.

That depends. In a hop-by-hop convergence-layer scheme,it's like BAB
(above). However, if the checksum is end-to-end then the sender would
create the checksum on the plaintext, and send the checksum and
plaintext data on its way. If the bundle passes through a gateway which
encrypts the data, unaware of the checksum, then you have encrypted
payload and a checksum of the plaintext. Not so good.

If we incorporate checksums under the *general* BSP umbrella (not the
specific ciphersuite #1/2/3 implementations) then this problem is
solved. The gateway knows about the checksum and encrypts it if needed.

>(It's possible to actually think about this stuff rationally without
>raising completely bogus security fears all the time, you know. You
>should try it.)

True. It's not the bogus ones that worry me, though.

Regards.....Peter

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Lloyd Wood" <[email-masked]>, "Peter Lovell" <[email-masked]>
Cc: "Darren Long" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Date: Wed, 25 Jul 2007 22:11:18 -0400
Sender: [email-masked]

On Thu, Jul 26, 2007, Stephen Farrell <[email-masked]> wrote:

>Also, just occurs to me that the BP checksum should probably be
>encrypted if the bundle is, right? Otherwise plaintext guessing
>works. So Wes might need to copy/reference some text from the
>BP security spec to cover that, as is done for a PSB. (Which
>sounds a bit naff editorial-wise... Pete - could we make that
>mechanism more easily re-usable or is it tied into the
>ciphersuite 3 text, can't recall now?)

The plaintext-guessing was exactly my point last week. That is why it is
vital that checksums are done in the *general* context of bundle
security. That is, BSP must know about them so that they can be
encrypted when needed.

OTOH, checksums don't need a lot of other stuff, to Lloyd's point. 

The current problem is that if you touch BSP at all, then you *must*
support the mandatory ciphersuites. As I understand it, that's the nub
of the issue. So maybe we should define BSP-lite with the BSP spec, so
that you don't need to implement ciphersuites #1/2/3 under certain
circumstances TBD. Then checksums could be under the BSP umbrella
without the downsides Lloyd mentioned.

I'm not overly concerned with a single node doing a simple checksum and
also confidentiality - that's just wrong. The real concern is an
originating node which does the simple checksum, and a bastion gateway
which does confidentiality processing, unaware of the checksum in the
bundle. That is quite bad, and is what I'm trying to avoid.

For the new spec, assuming we make a BSP-lite change in the BSP spec
itself, Wes can just define a PSB ciphersuite with a suitable checksum
algorithm and mutable canonicalization. For example, the
canonicalization suggested in the draft is just the payload - real simple. 

Cheers.....Peter

Date: Thu, 26 Jul 2007 01:42:21 +0100
To: Stephen Farrell <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Cc: Darren Long <[email-masked]>, [email-masked]
Sender: [email-masked]

At Thursday 26/07/2007 01:21 +0100, Stephen Farrell wrote:
>Lloyd Wood wrote:
>>At Thursday 26/07/2007 00:53 +0100, Stephen Farrell wrote:
>>>I guess a CL checksum will result in the errors being more quickly
>>>detected in a few cases (e.g. with fragmentation) 
>>As bundles are carried by hop-by-hop transfers, you'll know whether a bundle is corrupted at the receiving node or not. 
>
>If a bundle is reactively fragmented and if the BP checksum covers
>all the payload of the original bundle then a CL checksum might
>catch the error earlier.
>
>Or it might be better to do the BP checksum only hop-by-hop, or
>have two (one e2e, one per-hop), I'm not sure what you intended.

I'm talking about a convergence-layer checksum over the whole bundle. The convergence layer is the natural place to provide a hop-by-hop checksum of a bundle -- particularly since the bundle contents can be mutable with blocks added etc. at each hop.

>Also, just occurs to me that the BP checksum should probably be
>encrypted if the bundle is, right? 

Susan has already raised much the same point in her email of Tuesday 24th. The answer is no.

You simply encrypt first, then checksum the encrypted content. This is also most easily done by the convergence layer, which only ever sees the encrypted output.

(It's possible to actually think about this stuff rationally without raising completely bogus security fears all the time, you know. You should try it.)

L.

>Otherwise plaintext guessing
>works. So Wes might need to copy/reference some text from the
>BP security spec to cover that, as is done for a PSB. (Which
>sounds a bit naff editorial-wise... Pete - could we make that
>mechanism more easily re-usable or is it tied into the
>ciphersuite 3 text, can't recall now?)
>
>S.
>

Date: Thu, 26 Jul 2007 01:21:22 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: Darren Long <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

Lloyd Wood wrote:
> At Thursday 26/07/2007 00:53 +0100, Stephen Farrell wrote:
>> I guess a CL checksum will result in the errors being more quickly
>> detected in a few cases (e.g. with fragmentation) 
> 
> As bundles are carried by hop-by-hop transfers, you'll know whether a bundle is corrupted at the receiving node or not. 

If a bundle is reactively fragmented and if the BP checksum covers
all the payload of the original bundle then a CL checksum might
catch the error earlier.

Or it might be better to do the BP checksum only hop-by-hop, or
have two (one e2e, one per-hop), I'm not sure what you intended.

Also, just occurs to me that the BP checksum should probably be
encrypted if the bundle is, right? Otherwise plaintext guessing
works. So Wes might need to copy/reference some text from the
BP security spec to cover that, as is done for a PSB. (Which
sounds a bit naff editorial-wise... Pete - could we make that
mechanism more easily re-usable or is it tied into the
ciphersuite 3 text, can't recall now?)

S.

Date: Wed, 25 Jul 2007 20:05:42 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Darren Long <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparingprotocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Jul 26, 2007 at 12:53:03AM +0100, Stephen Farrell wrote:
> 
> I think Wes has agreed (modulo some checking) to transmute the
> current I-D to do that (and that should be draft-irtf-dtnrg-<<foo>>-00
> I guess), in which case we'll have an optional checksum in the BP
> itself.
> 

Yes, I'll start this next week.  I think there was a mail from Susan
that nicely explained how to do it.  I didn't get that mail for some
reason, but fortunately Lloyd did and forwarded it to me.  I would
assume it was a problem with our local email system rather than the
list.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Thu, 26 Jul 2007 01:08:14 +0100
To: Stephen Farrell <[email-masked]>, Darren Long <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Cc: [email-masked]
Sender: [email-masked]

At Thursday 26/07/2007 00:53 +0100, Stephen Farrell wrote:
>I guess a CL checksum will result in the errors being more quickly
>detected in a few cases (e.g. with fragmentation) 

As bundles are carried by hop-by-hop transfers, you'll know whether a bundle is corrupted at the receiving node or not. This is important for ALL custody transfer. Where is the error? Is it recoverable, or should it be discarded? Is the error in a block, or in the framing? Can the framing header information be trusted? etc.

L.

>but not sure if
>that would warrant doing a better CL-specific checksum for TCP/UDP
>myself. (How will our new BP checksum handle fragmentation btw?)
>
>S.
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 26 Jul 2007 00:53:49 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: DTN <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Sender: [email-masked]

Entirely predictable and entirely reasonable:-)

Any dedicated URI-criminals out there that could work with
Mike?

S.

Michael Demmer wrote:
> 
> I'd be willing to help out in this effort, to the extent that I can 
> document what the reference implementation does, kinda like what I did 
> in Dublin.
> 
> But I'm less inclined to cater to the URI-police folks, nor do I want to 
> be in charge of leading the effort :)
> 
> -mike
> 
> On Jul 25, 2007, at 7:35 AM, Stephen Farrell wrote:
> 
>>
>> Hi,
>>
>> As part of the BP spec review we've gotten a couple of
>> requests for a formal definition of the dtn: URI scheme.
>>
>> Its not going to hold up the BP RFC, but would anyone
>> take on the job of trying to write such a definition?
>>
>> To be honest, it might be a bit of work getting the
>> definition into the right shape to keep all the various
>> people here and in the URI-police happy, but if we
>> don't do it, I guess we've a serious prospect of ending
>> up with conflicting uses of dtn:<<foo>>
>>
>> S.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Thu, 26 Jul 2007 00:50:33 +0100
To: Darren Long <[email-masked]>, [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Re: comparing protocols for reliability etc.
Sender: [email-masked]

At Thursday 26/07/2007 00:07 +0100, Darren Long wrote:
>Hi all,
>
>I posted a few days ago amongst the turmoil of the recent paper  
>regarding data integrity.  Curiously, there have been no responses.   
>Hasn't anyone any comments?  If I'm very off plot, I'd hope someone  
>would put me straight.  Otherwise, I'm hoping someone might agree.

Darren - you're not off plot. Many of us have travelled to the IETF in Chicago, so the stuff related to in-the-room discussion has taken precedence.

IP fragmentation is unlikely because these convergence layers are usually only supposed to travel one hop across a local link, and in those scenarios they will know and use the local link MTU. (Protecting against errors in lower layers segmenting and reassembling packets is something I would be concerned about.)  For a convergence layer that can traverse the public Internet - TCP has Path MTU discovery to avoid fragmentation. Also, intermediate fragmentation is avoided in the IPv6 design. Weakness of the one's-complement checksum with large MTUs (especially jumbograms) is another issue.

We've spent a lot of time on the list discussing reliability to catch residual errors - I certainly think that if a convergence layer is advertised as "reliable" it should at least make an attempt to catch all errors - and that's why we added the MD5 integrity checksum in Saratoga, to provide an attempt at an e2e checksum to help applications that don't check what they receive. This means that Saratoga can provide a better, more reliable UDP-based convergence layer.

The bundle protocol should imo always be reliable in both framing and payload content, which it currently isn't - something there has been much discussion of here in Chicago, post our payload checksum block draft.

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ 

===
Hi all,

I find this to be an interesting topic of discussion, and I can't  
help but chip in with some comments of my own.

One possible concern that isn't addresses in the paper is the degree  
of error detection capability in the implemented CLs in the DTN2  
reference implementation.  I'm thinking specifically of the TCP and  
UDP CLs.

In the UDP CL implementation, bundles are accepted for transmission  
up to the maximum UDP datagram size (64kB).  With typical link MTU  
sizes, this bundle/datagram would undergo IP fragmentation, which is  
apparently to be considered "very harmful" to data integrity in the  
"right" circumstances.

Is it the intention to resort to bundle protocol extensions to handle  
the detection of residual errors above the CL, or should there be  
strong enough mechanisms in the CL itself?

Similarly, the TCP CL implementation provides no additional error  
detection mechanisms above TCP itself, which suffers from the same  
check-summing weakness as UDP.  My concern with the TCP CL relates to  
TCP operation over routes bisected with TCP PEPs.  There are PILC  
documents that describe the potential impact of TCP PEPs to the
end-to-end assumption of TCP, and coupling this with the additional  
potential for the PEPs to inject errors undetectable by the TCP/IP  
stack suggest to me that additional integrity checking should be  
provided in the CL, where I believe more efficient recovery options  
are available.

I wonder what others think?

Cheers,

Darren 

Date: Thu, 26 Jul 2007 00:53:03 +0100
From: Stephen Farrell <[email-masked]>
To: Darren Long <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Sender: [email-masked]

Hi Darren,

Sorry, think this got lost in the storm.

Darren Long wrote:
> Hi all,
> 
> I find this to be an interesting topic of discussion, and I can't help 
> but chip in with some comments of my own.
> 
> One possible concern that isn't addresses in the paper is the degree of 
> error detection capability in the implemented CLs in the DTN2 reference 
> implementation.  I'm thinking specifically of the TCP and UDP CLs.
> 
> In the UDP CL implementation, bundles are accepted for transmission up 
> to the maximum UDP datagram size (64kB).  With typical link MTU sizes, 
> this bundle/datagram would undergo IP fragmentation, which is apparently 
> to be considered "very harmful" to data integrity in the "right" 
> circumstances.
> 
> Is it the intention to resort to bundle protocol extensions to handle 
> the detection of residual errors above the CL, or should there be strong 
> enough mechanisms in the CL itself?
> 
> Similarly, the TCP CL implementation provides no additional error 
> detection mechanisms above TCP itself, which suffers from the same 
> check-summing weakness as UDP.  My concern with the TCP CL relates to 
> TCP operation over routes bisected with TCP PEPs.  There are PILC 
> documents that describe the potential impact of TCP PEPs to the 
> end-to-end assumption of TCP, and coupling this with the additional 
> potential for the PEPs to inject errors undetectable by the TCP/IP stack 
> suggest to me that additional integrity checking should be provided in 
> the CL, where I believe more efficient recovery options are available.
> 
> I wonder what others think?

I think Mike said something along those lines at the meeting, but
we also more-or-less agreed that defininng a new ciphersuite to do
BP keyless integrity in a new I-D was probably a good thing (tm).

I think Wes has agreed (modulo some checking) to transmute the
current I-D to do that (and that should be draft-irtf-dtnrg-<<foo>>-00
I guess), in which case we'll have an optional checksum in the BP
itself.

Not sure if we'd still want more that the "native" CL checksums
then, or do you think PEPs etc. would still make that worthwhile?

I guess a CL checksum will result in the errors being more quickly
detected in a few cases (e.g. with fragmentation) but not sure if
that would warrant doing a better CL-specific checksum for TCP/UDP
myself. (How will our new BP checksum handle fragmentation btw?)

S.

Cc: DTN <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] defining dtn:
Date: Wed, 25 Jul 2007 16:47:04 -0700
To: Stephen Farrell <[email-masked]>
Sender: [email-masked]

I'd be willing to help out in this effort, to the extent that I can  
document what the reference implementation does, kinda like what I  
did in Dublin.

But I'm less inclined to cater to the URI-police folks, nor do I want  
to be in charge of leading the effort :)

-mike

On Jul 25, 2007, at 7:35 AM, Stephen Farrell wrote:

>
> Hi,
>
> As part of the BP spec review we've gotten a couple of
> requests for a formal definition of the dtn: URI scheme.
>
> Its not going to hold up the BP RFC, but would anyone
> take on the job of trying to write such a definition?
>
> To be honest, it might be a bit of work getting the
> definition into the right shape to keep all the various
> people here and in the URI-police happy, but if we
> don't do it, I guess we've a serious prospect of ending
> up with conflicting uses of dtn:<<foo>>
>
> S.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Thu, 26 Jul 2007 00:07:48 +0100
Subject: [dtn-interest] Re: comparing protocols for reliability etc.
Sender: [email-masked]

Hi all,

I posted a few days ago amongst the turmoil of the recent paper  
regarding data integrity.  Curiously, there have been no responses.   
Hasn't anyone any comments?  If I'm very off plot, I'd hope someone  
would put me straight.  Otherwise, I'm hoping someone might agree.

Regards,

Darren Long

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] New bundle internet draft and paper  		comparingprotocolsfor reliability errored delivery.
Date: Wed, 25 Jul 2007 15:06:16 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Weiss, Howard" <[email-masked]>, "Stephen Farrell" <[email-masked]>, <[email-masked]>
Cc: "Lloyd Wood" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

That should have read FIPS 198-1....

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Weiss, Howard
> Sent: Wednesday, July 25, 2007 1:10 PM
> To: Stephen Farrell; [email-masked]
> Cc: Lloyd Wood; Scott Burleigh; [email-masked]
> Subject: RE: [dtn-interest] New bundle internet draft and paper
> comparingprotocolsfor reliability errored delivery.
> 
> One thing that should be observed regarding HMAC..... The latest draft
> version of FIPS 197-1 for HMAC has *removed* the (previously
mandatory)
> step to truncate the MD5 check word.  In the CCSDS Security WG, our
> integrity algorithm draft left the truncation as an option if a
mission
> had a narrow bandwidth pipe but otherwise did not encourage the
> truncation of the check word.
> 
> Also for some really interesting algorithm performance numbers see
> http://www.cryptopp.com/benchmarks.html
> 
> Howie
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:dtn-interest-
> > [email-masked]] On Behalf Of Stephen Farrell
> > Sent: Tuesday, July 24, 2007 2:39 PM
> > To: [email-masked]
> > Cc: Lloyd Wood; Scott Burleigh; [email-masked]
> > Subject: Re: [dtn-interest] New bundle internet draft and paper
> > comparingprotocolsfor reliability errored delivery.
> >
> >
> >
> > Wesley Eddy wrote:
> > > Just for the benefit of others: Stephen and I talked in the hall
> > today.
> > > I think we decided and agreed that HMAC-MD5 with a hardcoded key
> > would
> > > be reasonable.  Stephen: correct me if I'm wrong.
> >
> > Absolutely,
> > S.
> >
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] New bundle internet draft and paper  		comparingprotocolsfor reliability errored delivery.
Date: Wed, 25 Jul 2007 13:09:31 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, <[email-masked]>
Cc: "Lloyd Wood" <[email-masked]>, "Scott Burleigh" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

One thing that should be observed regarding HMAC..... The latest draft
version of FIPS 197-1 for HMAC has *removed* the (previously mandatory)
step to truncate the MD5 check word.  In the CCSDS Security WG, our
integrity algorithm draft left the truncation as an option if a mission
had a narrow bandwidth pipe but otherwise did not encourage the
truncation of the check word.  

Also for some really interesting algorithm performance numbers see
http://www.cryptopp.com/benchmarks.html

Howie

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Tuesday, July 24, 2007 2:39 PM
> To: [email-masked]
> Cc: Lloyd Wood; Scott Burleigh; [email-masked]
> Subject: Re: [dtn-interest] New bundle internet draft and paper
> comparingprotocolsfor reliability errored delivery.
> 
> 
> 
> Wesley Eddy wrote:
> > Just for the benefit of others: Stephen and I talked in the hall
> today.
> > I think we decided and agreed that HMAC-MD5 with a hardcoded key
> would
> > be reasonable.  Stephen: correct me if I'm wrong.
> 
> Absolutely,
> S.
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 25 Jul 2007 08:04:04 -0700
From: Scott Burleigh <[email-masked]>
To: Sally Floyd <[email-masked]>
CC: DTN <[email-masked]>, Internet Research Steering Group <[email-masked]>
Subject: [dtn-interest] Re: IRSG review of DNTRG's LTP-Specification draft
Sender: [email-masked]

Sally Floyd wrote:
> Scott -
>
> Something small that I didn't manage to put in my IRTF review.
>
> The abstract of the draft says the following:
>   "In an Interplanetary Internet setting deploying the Bundle protocol
>    being developed by the Delay Tolerant Networking Research Group, LTP
>    is intended to serve as a reliable convergence layer over single hop
>    deep-space RF links."
>
> I think it would be good to clarify, in the abstract, that LTP is *only*
> being specified for use over a single-hop point-to-point link that meets
> certain further restrictions (checksums and such).  Whether in
> the interplanetary Internet setting or some other one.
>
> (And if it is *only* being specified for an Interplanetary Internet 
> setting,
> the abstract should say that also.  And if not, then the abstract should
> specify any other restrictions.)
>
> This is from a long history of revising Abstracts for my own
> Experimental RFCs in the IETF:  RFC 4782, RFC 3649, RFC 4728, etc.
Thanks, Sally, a good catch.  We have started thinking about how to 
revise the abstract.

Scott

Date: Wed, 25 Jul 2007 15:35:24 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] defining dtn:
Sender: [email-masked]

Hi,

As part of the BP spec review we've gotten a couple of
requests for a formal definition of the dtn: URI scheme.

Its not going to hold up the BP RFC, but would anyone
take on the job of trying to write such a definition?

To be honest, it might be a bit of work getting the
definition into the right shape to keep all the various
people here and in the URI-police happy, but if we
don't do it, I guess we've a serious prospect of ending
up with conflicting uses of dtn:<<foo>>

S.

Date: Wed, 25 Jul 2007 09:35:32 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocolsforreliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 25, 2007 at 02:14:50PM +0100, Stephen Farrell wrote:
> >
> >As for the text above "Choosing something with no claimed security 
> >properties
> >means you're declaring that you don't care."  YES!  We don't care; it's
> >someone else's job!  Leave security services to the realm of the
> >security services ... we were only setting the cross-hairs on catching
> >innocent mistakes.
> 
> And making one in the process:-) Any use of MD5 creates a known
> vulnerability that is avoided by a different alg (HMAC in this case)
> and will at minimum allow people to create FUD. If you just pick
> a CRC then you won't be criticised in that respect since you won't
> be perceived to be making the mistake of choosing an algorithm with
> known security deficiencies (since it makes no security claims).
> 

So the reasoning is psychological for the sake of reviewers rather than
technological for the sake of the protocol and its implementations :).

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 25 Jul 2007 09:33:01 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocolsforreliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 25, 2007 at 02:14:50PM +0100, Stephen Farrell wrote:
> 
> Lastly, if it were me, I'd also investigate a bit further, since
> there may be even better than HMAC around, and I'd also do a bit
> of analysis to make sure that how I'm using HMAC is ok (e.g. most
> algs here have input size limits that saratoga's 128 bit pointers
> would perhaps breach). That last is about Saratoga though and
> not for the BP since it has a well developed model for plugging
> new ciphersuites. (I do agree that invesigating how the BP
> would work for v. large bundles is a good thing to do and might
> lead to new things being needed in the code or even the protocol.)
> 

Excellent point about the length.  I hadn't even considered it, and
we'll need to fix that.  Since we haven't generated objects big enough
to need the 128-bit pointers yet, we haven't had the calls to the hash
fail, but that failure is a certainty when/if we generate objects that
big.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 25 Jul 2007 14:14:50 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  		comparingprotocolsfor reliability errored delivery.
Sender: [email-masked]

Wesley Eddy wrote:
> This is an interesting discussion, and a few subtle points might be
> coming out.  

I think there were also some good points being made. If we can
separate those from the "mine's better than yours" aspects then
this will be a valuable dissussion. (And these last few mails
are examples of that separation.)

 > I hope we can continue it a little longer:
> 
> On Tue, Jul 24, 2007 at 06:04:16PM +0100, Stephen Farrell wrote:
>> Wesley Eddy wrote:
>>> On Tue, Jul 24, 2007 at 02:18:18PM +0100, Stephen Farrell wrote:
>>>> For Saratoga, the use of MD5 would be a killer as would the lack
>>>> of any security primitives.
>>> Why do you think IPsec is insufficient?
>> You're claiming that sha-1 is too hard for your CPU, but that
>> IPsec is ok?
> 
> 
> Let's distinguish Saratoga as it's used now in the limited hardware
> available (which cannot be changed) from Saratoga as we hope it to
> be deployed elsewhere.  

I think that's a good approach. But it also seems to me to be
the same general argument that Mike and Scott were making wrt
LTP's lack of a checksum. Its fair enough to argue that
e2e security and unkeyed-integrity are different, in terms of
which needs to be part of the protocol itself and which is
ok to layer upon, but I myself don't see that difference.

 > Presently, the hardware wouldn't be able to
> do much of any strong crypto and still saturate the downlink, but the
> SSDRs are being replaced by faster units in future satellites.  In any
> case, IPsec can be (and has been) used via the UK-DMC's onboard mobile
> router to protect traffic on the vulnerable RF link.  This is one of the
> nice things about IPsec, in that the security services can be offloaded
> or concentrated to some extent so that other specialized devices
> on-board a craft don't have to be burdened with them.  In future use of
> Saratoga on more capable hardware, if security is desired, IPsec is the
> tool of choice.  All of the computational burden of running it comes
> from using strong crypto, and doing that at any other layer is going to
> have the same computational burden (because you'll use the same
> algorithms), so there's absolutely no point in reinventing packet
> security hooks for Saratoga.

Don't agree about "absolutely no point" since IPsec deployment in
transport mode isn't at all easy even today and tunnel mode isn't
e2e (though is a greate tool to have in the toolbox). So, two things:

- to use IPsec in either mode, you need to check that the IKE stuff
is sufficiently reliable and performant in your environment and to
e.g. figure out how you'll handle the various policy settings
associated with layer3 security (e.g. will any non IKE, ESP traffic
at all be allowed? If so, what?) Router vendors have experienced
difficulties in scaling this in the core (I believe, but don't know
directly) when used e.g. to secure BGP, so there's non-trivial spec
and system engineering work to be done to use IPsec

- DTLS can sometimes be a better match, e.g. for RTP, so I'd also
encourage you to investigate that

Both approaches have been done elsewhere so there are models to
copy.

> 
>  
>>> handled separately from checksuming for error detection in both the case
>>> of Saratoga packets and files and DTN Bundles.  Let's not confuse the
>>> discussion with security business, because that's not what we're
>>> attempting to provide.
>> IMO choosing MD5 is exactly what would create that confusion. As I
>> said a while ago, chossing MD5 means you now have to worry. Choosing
>> sha-2 or hmac with a fixed key means you don't need to worry. Choosing
>> something with no claimed security properties means you're declaring
>> that you don't care. The first is not good, both of the others are ok.
> 
> 
> Although we did converge on HMAC-MD5 rather than MD5 yesterday, I still
> admit to being a little confused by the inconsistency of your arguments.
> You don't seem to be raising any concern with having Adler-32 as an
> option, for instance ...
> 
> As for the text above "Choosing something with no claimed security properties
> means you're declaring that you don't care."  YES!  We don't care; it's
> someone else's job!  Leave security services to the realm of the
> security services ... we were only setting the cross-hairs on catching
> innocent mistakes.

And making one in the process:-) Any use of MD5 creates a known
vulnerability that is avoided by a different alg (HMAC in this case)
and will at minimum allow people to create FUD. If you just pick
a CRC then you won't be criticised in that respect since you won't
be perceived to be making the mistake of choosing an algorithm with
known security deficiencies (since it makes no security claims).

Lastly, if it were me, I'd also investigate a bit further, since
there may be even better than HMAC around, and I'd also do a bit
of analysis to make sure that how I'm using HMAC is ok (e.g. most
algs here have input size limits that saratoga's 128 bit pointers
would perhaps breach). That last is about Saratoga though and
not for the BP since it has a well developed model for plugging
new ciphersuites. (I do agree that invesigating how the BP
would work for v. large bundles is a good thing to do and might
lead to new things being needed in the code or even the protocol.)

S.

Date: Wed, 25 Jul 2007 08:42:42 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocolsfor reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

This is an interesting discussion, and a few subtle points might be
coming out.  I hope we can continue it a little longer:

On Tue, Jul 24, 2007 at 06:04:16PM +0100, Stephen Farrell wrote:
> 
> Wesley Eddy wrote:
> >On Tue, Jul 24, 2007 at 02:18:18PM +0100, Stephen Farrell wrote:
> >>For Saratoga, the use of MD5 would be a killer as would the lack
> >>of any security primitives.
> >
> >Why do you think IPsec is insufficient?
> 
> You're claiming that sha-1 is too hard for your CPU, but that
> IPsec is ok?

Let's distinguish Saratoga as it's used now in the limited hardware
available (which cannot be changed) from Saratoga as we hope it to
be deployed elsewhere.  Presently, the hardware wouldn't be able to
do much of any strong crypto and still saturate the downlink, but the
SSDRs are being replaced by faster units in future satellites.  In any
case, IPsec can be (and has been) used via the UK-DMC's onboard mobile
router to protect traffic on the vulnerable RF link.  This is one of the
nice things about IPsec, in that the security services can be offloaded
or concentrated to some extent so that other specialized devices
on-board a craft don't have to be burdened with them.  In future use of
Saratoga on more capable hardware, if security is desired, IPsec is the
tool of choice.  All of the computational burden of running it comes
from using strong crypto, and doing that at any other layer is going to
have the same computational burden (because you'll use the same
algorithms), so there's absolutely no point in reinventing packet
security hooks for Saratoga.

> >handled separately from checksuming for error detection in both the case
> >of Saratoga packets and files and DTN Bundles.  Let's not confuse the
> >discussion with security business, because that's not what we're
> >attempting to provide.
> 
> IMO choosing MD5 is exactly what would create that confusion. As I
> said a while ago, chossing MD5 means you now have to worry. Choosing
> sha-2 or hmac with a fixed key means you don't need to worry. Choosing
> something with no claimed security properties means you're declaring
> that you don't care. The first is not good, both of the others are ok.

Although we did converge on HMAC-MD5 rather than MD5 yesterday, I still
admit to being a little confused by the inconsistency of your arguments.
You don't seem to be raising any concern with having Adler-32 as an
option, for instance ...

As for the text above "Choosing something with no claimed security properties
means you're declaring that you don't care."  YES!  We don't care; it's
someone else's job!  Leave security services to the realm of the
security services ... we were only setting the cross-hairs on catching
innocent mistakes.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Tue, 24 Jul 2007 19:39:12 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Lloyd Wood <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  		comparingprotocolsfor reliability errored delivery.
Sender: [email-masked]

Wesley Eddy wrote:
> Just for the benefit of others: Stephen and I talked in the hall today.
> I think we decided and agreed that HMAC-MD5 with a hardcoded key would
> be reasonable.  Stephen: correct me if I'm wrong.

Absolutely,
S.

Date: Tue, 24 Jul 2007 14:24:57 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Lloyd Wood <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocolsfor reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Jul 24, 2007 at 06:04:16PM +0100, Stephen Farrell wrote:
> >
> >I think security should stay OUT of the conversation here, as that's
> >handled separately from checksuming for error detection in both the case
> >of Saratoga packets and files and DTN Bundles.  Let's not confuse the
> >discussion with security business, because that's not what we're
> >attempting to provide.
> 
> IMO choosing MD5 is exactly what would create that confusion. As I
> said a while ago, chossing MD5 means you now have to worry. Choosing
> sha-2 or hmac with a fixed key means you don't need to worry. Choosing
> something with no claimed security properties means you're declaring
> that you don't care. The first is not good, both of the others are ok.

Just for the benefit of others: Stephen and I talked in the hall today.
I think we decided and agreed that HMAC-MD5 with a hardcoded key would
be reasonable.  Stephen: correct me if I'm wrong.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Tue, 24 Jul 2007 18:04:16 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: Lloyd Wood <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  	comparingprotocols for reliability errored delivery.
Sender: [email-masked]

Wesley Eddy wrote:
> On Tue, Jul 24, 2007 at 02:18:18PM +0100, Stephen Farrell wrote:
>> For Saratoga, the use of MD5 would be a killer as would the lack
>> of any security primitives.
> 
> Why do you think IPsec is insufficient?

You're claiming that sha-1 is too hard for your CPU, but that
IPsec is ok?

How would the IKE roundtrips work in the context of Saratoga?

How would ESP be affected by errored data?

What certificate profile would you choose?

Etc.

There's work to be done, either in Saratoga or else in terms of
how to layer it on IPsec (or perhaps better, DTLS).

> and:
> 
> When used *outside* of a security context, what's the problem with MD5?
> As far as I know, all of the issues are security related, and have
> nothing to do with using MD5 as a non-security-providing checksum for
> catching non-malicous errors.  It's certainly better at error-detection
> than 16-bit one's complement which seem to still be acceptable in TCP
> and UDP.
> 
> I think security should stay OUT of the conversation here, as that's
> handled separately from checksuming for error detection in both the case
> of Saratoga packets and files and DTN Bundles.  Let's not confuse the
> discussion with security business, because that's not what we're
> attempting to provide.

IMO choosing MD5 is exactly what would create that confusion. As I
said a while ago, chossing MD5 means you now have to worry. Choosing
sha-2 or hmac with a fixed key means you don't need to worry. Choosing
something with no claimed security properties means you're declaring
that you don't care. The first is not good, both of the others are ok.

S.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Date: Tue, 24 Jul 2007 12:52:12 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Lloyd Wood" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Wesley and Lloyd,

I think it's great that you are working on defining a mechanism to
enable payload checksums to be carried with the Bundle Protocol, and I
see your point that it would seem to be very useful to perform
integrity checks on bundles that are transferred custodially. 

I agree with Peter, however, that it would be ideal if any definition
of an integrity checksum mechanism for DTN would be defined as a new
PSB ciphersuite for use with the Bundle Security Protocol (BSP) rather
than as a separate mechanism that is independent of the BSP. For
example, you could get what you want by defining three new ciphersuites
for use with the BSP:
- PSB-IC-MD5-PAYLOAD (ciphersuite ID 0x004)
- PSB-IC-SHA1-PAYLOAD (ciphersuite ID ox005)
- PSB-IC-Adler32-PAYLOAD (ciphersuite ID 0x006)

And specifying the following for each:
- over what parts of the bundle (payload only rather than payload and
non-mutiable blocks, etc.) the integrity checksum is calculated
- what the ciphersuite parameters field contains, for example, it
should include the offset and length of the fragment that the checksum
covers (if it only covers a fragment)

I understand that your integrity checksum is not meant to be used in a
security context and therefore it is tempting to define it completely
independent of security, but as Peter pointed out, vulnerabilities can
be introduced if people were to start using the payload checksum block
and the CB-RSA-AES128-PAYLOAD-PSB ciphersuite in combination without
any understanding of how they interact. Also, an advantage to defining
the payload checksum cabability as ciphersuites for use with the PSB is
that simple variations on the above ciphersuites could easily address
header reliability as well as just payload reliability. 

If, on the other hand, you insist on defining an integrity checksum
mechanism that is independent of security and not aware of security,
then you will need to fix a few things in your draft. Here are the
first two that come to mind: (Again, I don't advocate this.)
- In the security considerations section, you would need to (at least)
mention the dangers of using this new payload checksum block in
combination with the CB-RSA-AES128-PAYLOAD-PSB ciphersuite. As Peter
pointed out, a vulnerability is introduced if a bundle with a payload
checksum block were to be encrypted, but the payload checksum block
were not encrypted. 
- Your mechanism for placing the Payload checksum block before or after
the payload depending on whether the checksum value covers the untire
payload or just the fragment may not work if a bundle is fragmented
more than once. (Suppose a 100-byte payload is fragmented into 1-50 and
51-100. Each of these fragments is given a Payload Checksum Block, so,
in the first fragment, that payload checksum block is placed after the
payload and it covers byes 1-50. Then this fragment is fragmented again
into bytes 1-20 and 21-50. The payload checksum block is placed in
bundle resulting from the second fragment (21-50) but it no longer has
the correct value. If you are planning on deleting this payload
checksum block and replacing it with a correct one then this needs to
be said. It is probably better to just have a field in the block that
specifies which bytes of the payload are covered (as is done in the
PSB-RSA-SHA256 ciphersuite defined in the PSB).  

I do hope you define your integrity checksums as ciphersuites for use
with the PSB. This would be a good contribution.

-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Peter
Lovell
>Sent: Monday, July 23, 2007 5:32 PM
>To: Lloyd Wood; [email-masked]
>Subject: Re: [dtn-interest] New bundle internet draft and 
>paper comparing protocols for reliability errored delivery.
>
>On Tue, Jul 17, 2007, Lloyd Wood <[email-masked]> wrote:
>
>>We have also done some work to address one of the areas of 
>weakness that
>>we have identified in that paper, by writing an internet-draft:
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/intern
>et-drafts/
>>draft-eddy-dtnrg-checksum/draft-eddy-dtnrg-checksum-00a.txt
>>The DTN Bundle Protocol Payload Checksum Block
>>Wesley M. Eddy and Lloyd Wood.
>>
>>Abstract -
>>   The Delay-Tolerant-Networking Bundle Protocol includes a custody
>>   transfer mechanism to provide acknowledgements of receipt for
>>   particular bundles.  No checksum is included in the basic 
>DTN Bundle
>>   Protocol, however, so it is not possible to verify that 
>bundles have
>>   been either forwarded or passed through various convergence layers
>>   without errors having been introduced.  This document partially
>>   rectifies the situation by defining a Bundle Protocol extension
for
>>   carrying payload checksums and describes how its use can be
>>   integrated with both custody transfer and fragmentation.
>>
>
>Hi all,
>
>it's true that the basic Bundle Protocol doesn't include an integrity
>mechanism, that being part of the Bundle Security Protocol BSP 
>extensions. 
>
>But this suggestion doesn't alter that fact, but provides a different
>extension scheme to achieve verification.
>
>There's nothing proposed here which can't be done within BSP. The only
>advantage is that the "mandatory ciphersuites" aren't present, which
>does lead to reduced footprint, an advantage for certain cases.
>
>I suggest that if we need a lightweight integrity protocol, we do it
in
>the context of bundle security protocol rather than creating something
>else to do essentially the same job. I *really* do not want to have
>integrity/security extensions which are separate from BSP as these
>create vulnerabilities. The obvious example is the checksum 
>[end-to-end]
>on a bundle which is encrypted at a gateway node. The bundle is
>encrypted but the checksum for the plaintext is not. Not good.
>
>Better to do this task with a BSP-aware protocol so that BSP knows how
>to protect things.
>
>In short, we can have additional security/integrity mechanisms but we
>should *not* have them outside the general umbrella of the 
>security spec.
>
>Regards.....Peter
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 24 Jul 2007 08:03:13 -0400
To: Lloyd Wood <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Routes to standards
Sender: [email-masked]

--=====================_81239625==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>At 09:48 AM 7/24/2007, Lloyd Wood wrote:
>my full question to Scott, which you have edited down, was:
>"Why isn't LTP being standardised in CCSDS, which specifies those 
>space links?"

Lloyd: because, right now, the IRTF provides a very useful forum for 
focusing the many energies and interests of the broad DTN community. 
As a convergence layer for DTN, it seems useful to keep LTP 
discussions active within that forum. However, let's be clear: 
anything that makes it to an RFC in the *IRTF* is merely an 
*Experimental* RFC and as such it has no formal significance as an 
accepted Internet Standard to the mainstream *IETF* community.  See 
<http://tools.ietf.org/html/rfc2026>RFC 2026.

CCSDS exists to create the specific set of standards that are 
recommended for use across the narrower space community, with a 
particular view towards implementing them into space mission support 
infrastructure via groups such as the IOAG: http://www.ioag.org/Overview.html.

CCSDS Recommended Standards ("Blue Books") are also usually processed 
by ISO/TC20/SC13 (Space Data and Information Transfer Systems) and 
become full International Standards:
http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?ICS1=49&ICS2=140&ICS3=&scopelist

At such time as there is a clear international consensus on the need 
for a Space DTN stack (and we think that time is getting close) then 
CCSDS will almost certainly undertake the international 
standardization of both Bundling and LTP.  It would be ideal if CCSDS 
could simply reference them in the formal 
<http://www.rfc-editor.org/rfcxx00.html>Official Internet Protocol 
Standards. but it is doubtful if even the wildest optimist on this 
list thinks that is going to happen any time soon.

Best regards
Adrian

Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)  
--=====================_81239625==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<blockquote type=cite class=cite cite="">At 09:48 AM 7/24/2007, Lloyd
Wood wrote:<br>
my full question to Scott, which you have edited down, was:<br>
&quot;Why isn't LTP being standardised in CCSDS, which specifies those
space links?&quot;</blockquote><br>
Lloyd: because, right now, the IRTF provides a very useful forum for
focusing the many energies and interests of the broad DTN community. As a
convergence layer for DTN, it seems useful to keep LTP discussions active
within that forum. However, let's be clear: anything that makes it to an
RFC in the *IRTF* is merely an *Experimental* RFC and as such it has no
formal significance as an accepted Internet Standard to the mainstream
*IETF* community.&nbsp; See
<a href="http://tools.ietf.org/html/rfc2026">RFC 2026</a>.<br><br>
CCSDS exists to create the specific set of standards that are recommended
for use across the narrower space community, with a particular view
towards implementing them into space mission support infrastructure via
groups such as the IOAG:
<a href="http://www.ioag.org/Overview.html" eudora="autourl">
http://www.ioag.org/Overview.html</a>. <br><br>
CCSDS Recommended Standards (&quot;Blue Books&quot;) are also usually
processed by ISO/TC20/SC13 (Space Data and Information Transfer Systems)
and become full International Standards:<br>
<a href="http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?ICS1=49&amp;ICS2=140&amp;ICS3=&amp;scopelist" eudora="autourl">
http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?ICS1=49&amp;ICS2=140&amp;ICS3=&amp;scopelist<br>
<br>
</a>At such time as there is a clear international consensus on the need
for a Space DTN stack (and we think that time is getting close) then
CCSDS will almost certainly undertake the international standardization
of both Bundling and LTP.&nbsp; It would be ideal if CCSDS could simply
reference them in the formal
<a href="http://www.rfc-editor.org/rfcxx00.html"><b>Official Internet
Protocol Standards</a>.</b> but it is doubtful if even the wildest
optimist on this list thinks that is going to happen any time
soon.<br><br>
Best regards<br>
Adrian<br>
<x-sigsep><p></x-sigsep>
<font size=2>Adrian J. Hooke<br>
Chairman, CCSDS Engineering Steering Group (CESG)</font> </body>
</html>

--=====================_81239625==.ALT--

Date: Tue, 24 Jul 2007 07:20:27 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

Stephen Farrell wrote:
> I honestly don't see any value in a p*&&ing competition here,
> other than to raise the temperature at DTNRG meetings which
> IMO provides *very* limited amusement,
Wups, sorry, I posted before I read this.  I agree and will desist.

Scott

Date: Tue, 24 Jul 2007 10:02:44 -0400
From: Wesley Eddy <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Lloyd Wood <[email-masked]>, Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper   comparingprotocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Tue, Jul 24, 2007 at 02:18:18PM +0100, Stephen Farrell wrote:
> 
> For Saratoga, the use of MD5 would be a killer as would the lack
> of any security primitives.

Why do you think IPsec is insufficient?

and:

When used *outside* of a security context, what's the problem with MD5?
As far as I know, all of the issues are security related, and have
nothing to do with using MD5 as a non-security-providing checksum for
catching non-malicous errors.  It's certainly better at error-detection
than 16-bit one's complement which seem to still be acceptable in TCP
and UDP.

I think security should stay OUT of the conversation here, as that's
handled separately from checksuming for error detection in both the case
of Saratoga packets and files and DTN Bundles.  Let's not confuse the
discussion with security business, because that's not what we're
attempting to provide.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Tue, 24 Jul 2007 14:48:34 +0100
To: Stephen Farrell <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Cc: Scott Burleigh <[email-masked]>, [email-masked]
Sender: [email-masked]

Stephen,

my full question to Scott, which you have edited down, was:
"Why isn't LTP being standardised in CCSDS, which specifies those space links?"
[..]
Again, if LTP is intended principally for deep space, why isn't it being specified in CCSDS, just as CFDP was?
[..]
Surely CCSDS is the best forum to make things clear to spacecraft communication engineers? Isn't LTP intended for more than just spacecraft?"

CCSDS is a subgroup of the ISO standards body, and produces eventual standards for the space communications community via a different route from the IETF/IRTF. That was not a comment on the IRTF/IETF experimental/standards process (and, incidentally, there's a well-worn path from experimental to standard in the IETF, though chartering an IETF wg to get something standards-track would be required eventually.). For example, CFDP is now a CCSDS blue book, or recommended CCSDS standard. LTP could easily follow that track if desired.

The scope of use of experimental RFCs can be specified based on the wording placed at the start - safe for use across the terrestrial Internet, or safe for use only in your own private networks. Saratoga and LTP can be expected to be the latter.

I agree that, for the current LTP specification, the LTP security extensions would likely need to be mandatory to get reliability in error-rejection as a side-effect.

For Saratoga's use of MD5 as a file/bundle integrity check, we've also discussed this - SHA1 is twice as slow as MD5 (important for low-end processors), and we're only using MD5 for an integrity check. Security attack concerns are separate. Also, because Saratoga runs over UDP/UDP-Lite and only over UDP/UDP-Lite, the full IPsec security suite is available for use by Saratoga, and can be leveraged to provide security. With link security, bundle security and IPsec, is another layer needed?

cheers,

L.

At Tuesday 24/07/2007 14:18 +0100, Stephen Farrell wrote:

>Lloyd Wood wrote:
>
>>Why isn't LTP being standardised...<elsewhere>
>
>Lloyd,
>
>The above is wrong. LTP, and presumably Saratoga, are being put
>forward as experimental RFCs. That is very different from being
>on the standards-track. Maybe you should re-read some of the IRTF
>and IETF process documents?
>
>IMO, as-is, neither protocol would pass muster for the standards
>track.
>
>For LTP, arguably the security extensions would have to be made
>mandatory to implement. I could well imagine that the red/green
>mechanism might change (e.g. to allow red segments to be
>interspersed anywhere in the block).
>
>For Saratoga, the use of MD5 would be a killer as would the lack
>of any security primitives.
>
>Both would fall over the lack of key management.
>
>Both would have to have a bunch of work done on fairness and
>all the other things that people care about for protocols that
>could be in widespread use over the Internet.
>
>I honestly don't see any value in a p*&&ing competition here,
>other than to raise the temperature at DTNRG meetings which
>IMO provides *very* limited amusement,
>
>S.

Date: Tue, 24 Jul 2007 15:35:41 +0200
From: "samet olfa" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] new DTN student
Sender: [email-masked]

------=_Part_110178_31176539.1185284141331
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I'm new in the DTN context. I'm triing to evaluate the performance of these
networks over satellite links. For that i thought to use the simulator NS 2

I have found an implementation for ns 2.27(
http://www.illuvatar.nu/ns-dtn/code/

but when i installed it i had the following error

[samet@cochise ns-2.27]$ ns dtn-demo-large.tcl
invalid command name "Agent/DTNAgent"
    while executing
"Agent/DTNAgent set custodian_ 1"

can someone help me please.
thanks
olfa

------=_Part_110178_31176539.1185284141331
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I&#39;m new in the DTN context. I&#39;m triing to evaluate the performance of
these networks over satellite links. For that i thought to use the
simulator NS 2 <br>
<pre><font size="4">I have found an implementation for ns 2.27(<br><a href="http://www.illuvatar.nu/ns-dtn/code/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.illuvatar.nu/ns-dtn/code/
</a></font></pre>
but when i installed it i had the following error <br>
<br>
[samet@cochise ns-2.27]$ ns dtn-demo-large.tcl<br>
invalid command name &quot;Agent/DTNAgent&quot;<br>
&nbsp;&nbsp;&nbsp; while executing<br>
&quot;Agent/DTNAgent set custodian_ 1&quot;<br>
<br>
can someone help me please. <br>
thanks <br><span class="sg">
olfa</span>

------=_Part_110178_31176539.1185284141331--

Date: Tue, 24 Jul 2007 06:24:22 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030305010806030104090009
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Lloyd Wood wrote:
> At Monday 23/07/2007 07:56 -0700, Scott Burleigh wrote:
>   
>> Lloyd Wood wrote:
>>     
>>> At Wednesday 18/07/2007 00:48 -0700, Scott Burleigh wrote:
>>>       
>>>> The very interesting and concisely introduced concept of errored
>>>> content was new to me, as it's a communication service that I can't
>>>> recall any deep space science mission ever asking for.
>>>>         
>>> Errored content is something that we normally strive to avoid, using
>>> checksums. Deliberately letting errors pass up the stack is
>>> relatively new, and worth examining. (I'm a little puzzled by the
>>> growing move to implement this support for allowing errors, though I
>>> can see the value for unidirectional broadcast and long-delay links,
>>> and also in saving unnecessary overlapping checksum computing effort
>>> throughout the network, which may become more important as MTU sizes
>>> rise.
>>>       
>> Yes, avoiding this sort of duplication of effort and unnecessary bandwidth consumption was one of the design considerations underlying omission of checksums from LTP, which is designed to run directly over single hop deep-space RF links that are already heavily coded.
>>     
> LTP is designed to run over deep-space links? And not anything else?
>   
Have you read, say, the Abstract to the LTP spec?
> Why isn't LTP being standardised in CCSDS, which specifies those space links?
>   
Do you think IETF is an inappropriate place to standardize communication 
protocols for use over space links?
>>>> Note that the last paragraph of section 5 of the LTP specification
>>>> says "The underlying data-link layer is required to never deliver
>>>> incompletely received LTP segments to LTP.  In the absence of the
>>>> use of LTP authentication [LTPEXT], LTP also requires the
>>>> underlying data-link layer to perform data integrity checking of
>>>> the segments received.  Specifically, the data-link layer is
>>>> expected to detect any corrupted segments received and to silently
>>>> discard them."
>>>>         
>>> Just specifying that does not make it reality
>>>       
>> Quite true, merely specifying something does not make it reality.  It provides guidance to those who implement and deploy the protocol and who wish it to provide satisfactory performance.
>>
>> Similarly, the TCP and UDP specifications assume that IP is used as the underlying protocol.  Using some other underlying protocol will violate the specification and probably result in unsatisfactory performance.
>>
>> The Saratoga specification requires that UDP checksums be turned on when the protocol is used over IPv4.  Using Saratoga over UDP/IPv4 with UDP checksums turned off will violate the specification and probably result in unsatisfactory performance.
>>     
> The nice thing about the specifications of Saratoga, TCP and UDP is that those protocols don't run over a vast range of other protocols. How they interface to the lower protocol that they do run over can be easily and completely specified as a result.
>   
And this would be the major deficiency of the IP spec?
>>> - that link-layer frame will always checksum the entire LTP packet
>>> robustly and detect ALL possible errors. This assumes that the
>>> checksums of all link layers are equivalent in protecting against
>>> errors, so that LTP packets are uniformly robust and equivalent in
>>> integrity no matter what link layer they have travelled over.
>>>       
>> No, it assumes that the checksum of the underlying link layer is strong enough to meet the requirement identified in the specification.
>>     
> I'm sorry, where in the LTP specification is the underlying checksum strength and level of error tolerance stated? There's no discussion of minimum strength of underlying link-layer checksums as a requirement.
>   
The requirement is simply to "detect any corrupted segments received and 
to silently discard them." That seems pretty clear. Selecting the 
appropriate mechanisms is a system engineering issue.
>>>> Summing up, I think you'll have a stronger paper if you simplyremove LTP from it altogether and stick to a survey of protocols
>>>> that deliver errored content.
>>>>         
>>> That's the second time you've brought that up. Scott, you're
>>> suggesting any and all analysis or criticism of LTP be removed from
>>> our paper -- and you're an author of the LTP specifications.
>>>       
>> No, I don't think I was doing that.  I was offering an observation that I thought might help you and your co-authors remove some errors from your paper, on the chance that the errors arose from an honest misreading of the LTP specification.
>>     
> Consider the possibility that our paper isn't errored in its discussion of LTP, because LTP can deliver errored content ('expected' is not a mandatory MUST, as we discussed, Stephen tells me that his LTP code can do this),that we discuss segmentation of LTP frames because we know that LTP-T explicitly permits fragmentation and that LTP can be carried over complex link layers that do segment packets, and that we discuss the negative effects of LTP's lack of a checksum or any self-checking for these reasons and because it's so unusual in a transport protocol.
>   
Now I'm confused. If you were writing about possible problems with LTP-T 
or to point out that some link-layer protocols are not suitable for use 
underneath LTP, why weren't these topics discussed in the paper? Are you 
saying that the motivation for this paper was to get the words "is 
expected to" changed to MUST in section 5 of the LTP spec?
>> You are of course free, Lloyd, to disregard that observation and publish whatever you feel like.  Obviously you are a man who is immune to embarrassment, for which I salute you.
>>     
> I note that you were very selective in the points that you replied to.
True; I was selective in this one as well, and for the same reasons. 
There was a good deal of repetition, there were some questions to which 
I felt the answers were too obvious to spend time on, and there were 
some points on which I figured there was simply no reason to say 
anything more. We all have other things to do.
> Again, what do you believe LTP green packets will be used for?
Section 3.3 ("partial reliability") of the Motivation draft discusses 
this. I am confident that you'll point out the bits that you find 
unclear or incomplete.
> What is the value in green packet erasures?
Saving the application the trouble of determining which received data 
are worth acting on and which are not. More or less like the value of 
UDP datagram erasures, perhaps.
> And why not also just mandate that the link-layer frame use available link ARQ for reliable delivery?
Because ARQ that works over links characterized by extremely long and/or 
variable delay is not available for all link protocols. Where 
sufficiently capable link-layer ARQ is indeed available, you can 
certainly use it as a convergence-layer protocol. Nobody says LTP has to 
be used everywhere. Or in fact anywhere; it's a tool that is designed to 
solve some specific problems, and if you don't have those problems then 
you don't need the tool.

Scott

--------------030305010806030104090009
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Lloyd Wood wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">At Monday 23/07/2007 07:56 -0700, Scott Burleigh wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Lloyd Wood wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">At Wednesday 18/07/2007 00:48 -0700, Scott Burleigh wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">The very interesting and concisely introduced concept of errored
content was new to me, as it&#8217;s a communication service that I can&#8217;t
recall any deep space science mission ever asking for.
        </pre>
      </blockquote>
      <pre wrap="">Errored content is something that we normally strive to avoid, using
checksums. Deliberately letting errors pass up the stack is
relatively new, and worth examining. (I'm a little puzzled by the
growing move to implement this support for allowing errors, though I
can see the value for unidirectional broadcast and long-delay links,
and also in saving unnecessary overlapping checksum computing effort
throughout the network, which may become more important as MTU sizes
rise.
      </pre>
    </blockquote>
    <pre wrap="">Yes, avoiding this sort of duplication of effort and unnecessary bandwidth consumption was one of the design considerations underlying omission of checksums from LTP, which is designed to run directly over single hop deep-space RF links that are already heavily coded.
    </pre>
  </blockquote>
  <pre wrap=""><!---->LTP is designed to run over deep-space links? And not anything else?
  </pre>
</blockquote>
Have you read, say, the Abstract to the LTP spec?<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">
Why isn't LTP being standardised in CCSDS, which specifies those space links?
  </pre>
</blockquote>
Do you think IETF is an inappropriate place to standardize
communication protocols for use over space links?<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Note that the last paragraph of section 5 of the LTP specification
says "The underlying data-link layer is required to never deliver
incompletely received LTP segments to LTP.  In the absence of the
use of LTP authentication [LTPEXT], LTP also requires the
underlying data-link layer to perform data integrity checking of
the segments received.  Specifically, the data-link layer is
expected to detect any corrupted segments received and to silently
discard them."
        </pre>
      </blockquote>
      <pre wrap="">Just specifying that does not make it reality
      </pre>
    </blockquote>
    <pre wrap="">Quite true, merely specifying something does not make it reality.  It provides guidance to those who implement and deploy the protocol and who wish it to provide satisfactory performance.

Similarly, the TCP and UDP specifications assume that IP is used as the underlying protocol.  Using some other underlying protocol will violate the specification and probably result in unsatisfactory performance.

The Saratoga specification requires that UDP checksums be turned on when the protocol is used over IPv4.  Using Saratoga over UDP/IPv4 with UDP checksums turned off will violate the specification and probably result in unsatisfactory performance.
    </pre>
  </blockquote>
  <pre wrap=""><!---->The nice thing about the specifications of Saratoga, TCP and UDP is that those protocols don't run over a vast range of other protocols. How they interface to the lower protocol that they do run over can be easily and completely specified as a result.
  </pre>
</blockquote>
And this would be the major deficiency of the IP spec?<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">- that link-layer frame will always checksum the entire LTP packet
robustly and detect ALL possible errors. This assumes that the
checksums of all link layers are equivalent in protecting against
errors, so that LTP packets are uniformly robust and equivalent in
integrity no matter what link layer they have travelled over.
      </pre>
    </blockquote>
    <pre wrap="">No, it assumes that the checksum of the underlying link layer is strong enough to meet the requirement identified in the specification.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I'm sorry, where in the LTP specification is the underlying checksum strength and level of error tolerance stated? There's no discussion of minimum strength of underlying link-layer checksums as a requirement.
  </pre>
</blockquote>
The requirement is simply to "detect any corrupted segments received
and to silently discard them."&nbsp; That seems pretty clear.&nbsp; Selecting the
appropriate mechanisms is a system engineering issue.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">Summing up, I think you&#8217;ll have a stronger paper if you simplyremove LTP from it altogether and stick to a survey of protocols
that deliver errored content.
        </pre>
      </blockquote>
      <pre wrap="">That's the second time you've brought that up. Scott, you're
suggesting any and all analysis or criticism of LTP be removed from
our paper -- and you're an author of the LTP specifications.
      </pre>
    </blockquote>
    <pre wrap="">No, I don't think I was doing that.  I was offering an observation that I thought might help you and your co-authors remove some errors from your paper, on the chance that the errors arose from an honest misreading of the LTP specification.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Consider the possibility that our paper isn't errored in its discussion of LTP, because LTP can deliver errored content ('expected' is not a mandatory MUST, as we discussed, Stephen tells me that his LTP code can do this),that we discuss segmentation of LTP frames because we know that LTP-T explicitly permits fragmentation and that LTP can be carried over complex link layers that do segment packets, and that we discuss the negative effects of LTP's lack of a checksum or any self-checking for these reasons and because it's so unusual in a transport protocol.
  </pre>
</blockquote>
Now I'm confused.&nbsp; If you were writing about possible problems with
LTP-T or to point out that some link-layer protocols are not suitable
for use underneath LTP, why weren't these topics discussed in the
paper?&nbsp; Are you saying that the motivation for this paper was to get
the words "is expected to" changed to MUST in section 5 of the LTP spec?<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">You are of course free, Lloyd, to disregard that observation and publish whatever you feel like.  Obviously you are a man who is immune to embarrassment, for which I salute you.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I note that you were very selective in the points that you replied to.</pre>
</blockquote>
True; I was selective in this one as well, and for the same reasons.&nbsp;
There was a good deal of repetition, there were some questions to which
I felt the answers were too obvious to spend time on, and there were
some points on which I figured there was simply no reason to say
anything more.&nbsp; We all have other things to do.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Again, what do you believe LTP green packets will be used for?</pre>
</blockquote>
Section 3.3 ("partial reliability") of the Motivation draft discusses
this.&nbsp; I am confident that you'll point out the bits that you find
unclear or incomplete.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">What is the value in green packet erasures?</pre>
</blockquote>
Saving the application the trouble of determining which received data
are worth acting on and which are not.&nbsp; More or less like the value of
UDP datagram erasures, perhaps.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">And why not also just mandate that the link-layer frame use available link ARQ for reliable delivery?</pre>
</blockquote>
Because ARQ that works over links characterized by extremely long
and/or variable delay is not available for all link protocols.&nbsp; Where
sufficiently capable link-layer ARQ is indeed available, you can
certainly use it as a convergence-layer protocol.&nbsp; Nobody says LTP has
to be used everywhere.&nbsp; Or in fact anywhere; it's a tool that is
designed to solve some specific problems, and if you don't have those
problems then you don't need the tool.<br>
<br>
Scott<br>
</body>
</html>

--------------030305010806030104090009--

Date: Tue, 24 Jul 2007 14:18:18 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: Scott Burleigh <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

Lloyd Wood wrote:

> Why isn't LTP being standardised...<elsewhere>

Lloyd,

The above is wrong. LTP, and presumably Saratoga, are being put
forward as experimental RFCs. That is very different from being
on the standards-track. Maybe you should re-read some of the IRTF
and IETF process documents?

IMO, as-is, neither protocol would pass muster for the standards
track.

For LTP, arguably the security extensions would have to be made
mandatory to implement. I could well imagine that the red/green
mechanism might change (e.g. to allow red segments to be
interspersed anywhere in the block).

For Saratoga, the use of MD5 would be a killer as would the lack
of any security primitives.

Both would fall over the lack of key management.

Both would have to have a bunch of work done on fairness and
all the other things that people care about for protocols that
could be in widespread use over the Internet.

I honestly don't see any value in a p*&&ing competition here,
other than to raise the temperature at DTNRG meetings which
IMO provides *very* limited amusement,

S.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Most of the meeting materials are now up...
Date: Tue, 24 Jul 2007 08:08:40 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Sender: [email-masked]

Audio will be up regardless, NO?  I have some people who may participate
after the fact.  That is they may listen to the audio archive.

I also may have some colleagues remoted in.  I will sign into Jabber to
see.

Will

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Stephen Farrell
> Sent: Tuesday, July 24, 2007 8:49 AM
> To: DTN
> Subject: [dtn-interest] Most of the meeting materials are now up...
> 
> 
> ...at [1], scroll down to dtnrg for links to the agenda and 
> presentations. The intro slide #1 contains all the relevant 
> URLs for jabber, audio etc.
> 
> I've still not heard anyone say they'll be a remote 
> participant, so if there's no-one in the jabber room and no 
> one mails to say they'll be the audio we'll probably run the 
> meeting as a purely local one.
> 
> If there are remote participants, then if you want someone to 
> channel a comment for you type your remark into the jabber 
> room prefaced by "MIC:", e.g.
> "MIC: I can't hear the audio, ask the speaker to use a mic" 
> or "MIC: that's crazy because of <foo>"
> If you're on the audio but can't jabber, you could try the 
> same via email, but it won't be as immediate.
> 
> Cheers,
> S.
> 
> [1] https://datatracker.ietf.org/meeting/69/materials.html
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 24 Jul 2007 13:48:37 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Most of the meeting materials are now up...
Sender: [email-masked]

...at [1], scroll down to dtnrg for links to the agenda
and presentations. The intro slide #1 contains all the
relevant URLs for jabber, audio etc.

I've still not heard anyone say they'll be a remote
participant, so if there's no-one in the jabber room
and no one mails to say they'll be the audio we'll
probably run the meeting as a purely local one.

If there are remote participants, then if you want
someone to channel a comment for you type your
remark into the jabber room prefaced by "MIC:", e.g.
"MIC: I can't hear the audio, ask the speaker to
use a mic" or "MIC: that's crazy because of <foo>"
If you're on the audio but can't jabber, you could
try the same via email, but it won't be as immediate.

Cheers,
S.

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

To: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Mon, 23 Jul 2007 22:50:55 -0700
Subject: [dtn-interest] tidbits around IETF
Sender: [email-masked]

For those of you at IETF, in the rtgarea session following the DTNRG  
session on tue, the last 45 mins will be the topic 'routing over low  
power and lossy networks', which I believe has come from the sensor  
network folk
(e.g., http://www.ietf.org/internet-drafts/draft-culler-rsn-routing- 
reqs-00.txt)

Some people might like to drop in and see what is up.

Also of possible interest to this community is some advancement of  
the following document on raptor codes:

http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-raptor- 
object-09.txt

cheers,
- K

Date: Tue, 24 Jul 2007 06:12:13 +0100
To: Scott Burleigh <[email-masked]>, [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Sender: [email-masked]

At Monday 23/07/2007 07:56 -0700, Scott Burleigh wrote:
>Lloyd Wood wrote:
>>At Wednesday 18/07/2007 00:48 -0700, Scott Burleigh wrote:
>>>The very interesting and concisely introduced concept of errored
>>>content was new to me, as it’s a communication service that I can’t
>>>recall any deep space science mission ever asking for.
>>Errored content is something that we normally strive to avoid, using
>>checksums. Deliberately letting errors pass up the stack is
>>relatively new, and worth examining. (I'm a little puzzled by the
>>growing move to implement this support for allowing errors, though I
>>can see the value for unidirectional broadcast and long-delay links,
>>and also in saving unnecessary overlapping checksum computing effort
>>throughout the network, which may become more important as MTU sizes
>>rise.
>
>Yes, avoiding this sort of duplication of effort and unnecessary bandwidth consumption was one of the design considerations underlying omission of checksums from LTP, which is designed to run directly over single hop deep-space RF links that are already heavily coded.

LTP is designed to run over deep-space links? And not anything else?

Why isn't LTP being standardised in CCSDS, which specifies those space links?

>>>LTP is not, as you state, a transport-layer protocol that permits
>>>delivery of errored payloads.
>>LTP propagates any errors in received payloads up the protocol stack
>>to the bundle layer, without any checksums to prevent that from
>>happening. That permits delivery of errored payloads.
>
>Not if errored payloads are never received, in compliance with section 5 of the LTP specification.

And, of course, the bundle protocol and the applications using bundles will also be just fine as errored payloads are never received. Reality suggests otherwise.

Please read Stone's papers on what happens in real implementations - and can even happen in this "deep space is special" case you keep bringing up.

>>>Note that the last paragraph of section 5 of the LTP specification
>>>says "The underlying data-link layer is required to never deliver
>>>incompletely received LTP segments to LTP.  In the absence of the
>>>use of LTP authentication [LTPEXT], LTP also requires the
>>>underlying data-link layer to perform data integrity checking of
>>>the segments received.  Specifically, the data-link layer is
>>>expected to detect any corrupted segments received and to silently
>>>discard them."
>>Just specifying that does not make it reality
>
>Quite true, merely specifying something does not make it reality.  It provides guidance to those who implement and deploy the protocol and who wish it to provide satisfactory performance.
>
>Similarly, the TCP and UDP specifications assume that IP is used as the underlying protocol.  Using some other underlying protocol will violate the specification and probably result in unsatisfactory performance.
>
>The Saratoga specification requires that UDP checksums be turned on when the protocol is used over IPv4.  Using Saratoga over UDP/IPv4 with UDP checksums turned off will violate the specification and probably result in unsatisfactory performance.

The nice thing about the specifications of Saratoga, TCP and UDP is that those protocols don't run over a vast range of other protocols. How they interface to the lower protocol that they do run over can be easily and completely specified as a result.

I gather LTP is meant to run over a vast range of unspecified link layers (which oddly, are all _deep space_ link layers, if I read you right), which will obviously bring very different behaviours and support to LTP. (Or is LTP meant to just be run solely over _homogenous_ deep space links?)

>>>the intent of the design is that each LTP segment is to occupy a
>>>single lower-layer frame (see section 4.1 of the spec), so that the
>>>checksumming in that lower-layer frame protects the integrity of
>>>the segment against errors caused by transmission noise.  A
>>>lower-layer checksum in a frame carrying an LTP segment is not just
>>>"desirable", it is explicitly mandatory.
>>That seems to be hoping for a bit much. If a lower-layer checksum is
>>mandatory, you would expect to see a MUST rather than "expected" in
>>the specification.
>
>A very constructive suggestion.  Using the word "MUST" in this context rather than "is expected to" would very likely improve the spec.

But the MUST needs to be worded as to be applied to LTP, not to the link-layer protocols that are not specified, e.g. "LTP *MUST* be used over link-layer protocols that provide strong checksums or CRC checks on their payloads to prevent passing errored content to LTP, as LTP does not check its own payloads or headers for robustness."

It also really needs to be in the abstract of the specification; it's a very important constraint on how LTP can be used, and makes LTP use more safe. (But not completely safe - the end-to-end principle again.)

>>But, as an eventual standards process point, such
>>a MUST/required is being applied not to LTP, but the universe of
>>link-layer protocols outside LTP and outside the IETF's control.
>
>No, it's being applied to conformant deployments of the LTP protocol, in exactly the same way that the requirement that UDP checksums be turned on over IPv4 (for example) applies to conformant deployments of the Saratoga protocol.

Not in the current wording. See above for a suggested improvement.

>>The assumptions in the LTP specification are that:
>>- an LTP packet will always fit into a single link-layer frame
>>without further segmentation. Given the vast number of possible link
>>layers for LTP, this is unlikely, as it rules out classes of link
>>layer, or mandates that LTP be must run over UDP/IP over that class
>>of link layer to get protection against bugs in reassembly of
>>segmented packets.
>
>Sure, it's possible that there are some underlying link-layer protocols for which LTP won't be suitable.  The deep-space link-layer protocols for which it is principally intended are fine, though.

Again, if LTP is intended principally for deep space, why isn't it being specified in CCSDS, just as CFDP was?

>>- that link-layer frame will always checksum the entire LTP packet
>>robustly and detect ALL possible errors. This assumes that the
>>checksums of all link layers are equivalent in protecting against
>>errors, so that LTP packets are uniformly robust and equivalent in
>>integrity no matter what link layer they have travelled over.
>
>No, it assumes that the checksum of the underlying link layer is strong enough to meet the requirement identified in the specification.

I'm sorry, where in the LTP specification is the underlying checksum strength and level of error tolerance stated? There's no discussion of minimum strength of underlying link-layer checksums as a requirement.

>That strength may differ in different environments, which may well be traversed using different link-layer protocols.

Yes, the quality of the link protocols and the error-rejection strength they offer varies. I think that's rather my point.

What strength (in terms of probability of errored bits being passed to LTP) is considered sufficient? As LTP has no checksum, there's no guaranteed minimum strength.

>>- there is no intermediate-processing corruption, after the link
>>checksum check has been carried out (though mandating single frames
>>reduces the amount of processing required, and the possibility of
>>corruption occurring).
>
>Yes, bugs in the implementation of the link-layer protocol will typically result in errors in data delivery; so will bugs in the implementation of LTP.  This is true of many protocols.

And this also needs to be guarded against - read Stone's papers. Where in the combined LTP/bundle stack are errors in payloads and headers detected to prevent errors going undetected?

>>- the link-layer frame will not be subject to reliable ARQ, as
>>deciding to do ARQ or not (for red/green packets) is solely LTP's
>>job.
>
>No, the LTP specification doesn't require that the link-layer protocol do -- or not do -- its own ARQ.  The additional ARQ would likely be a waste of cycles and bandwidth, but that's a system engineering issue; it will always be possible to include LTP in a protocol stack that is badly configured.

I'm sorry, I thought you were arguing that including LTP in a stack that is badly configured (say, with no link-layer checksums covering payloads) will never happen, because a) you'd specified it wouldn't b) LTP is only used in deep space, and the spacecraft designers will follow your requirements?

This is precisely why we can discuss error propagation of LTP and using LTP in a stack that is intended to propagate errors upwards.

LTP green packets would seem to expect the link ARQ not be done - otherwise they become equivalent to red packets.

Why is it that when you have both, the link-layer ARQ considered a waste of cycles and bandwidth, rather than LTP's ARQ being considered a waste of cycles and bandwidth? After all, LTP is implemented over a pre-existing link to fit LTP packets into single frames.

>>>A small number of undetected flipped bits in a set of engineering
>>>telemetry records or a multispectral image could induce people to
>>>make some expensive mistakes.
>>Yes. Good to see that you acknowledge the problem of undetected
>>flipped bits (whether from transmission or from processing/storage).
>>Perhaps you'd like to suggest how the LTP specification could be
>>improved to detect and prevent these?
>
>No, I prefer to make it clear to spacecraft communication engineers that the required design elements of LTP don't duplicate the detection and correction of corrupt data that is already accomplished by heavily encoded link-layer protocols and ECC memory.

The end-to-end principle tells us that error-checking in individual components can be necessary, but is not sufficient.

So, where in the LTP/bundle combination is the end-to-end principle followed? Where are errors protected against?

Surely CCSDS is the best forum to make things clear to spacecraft communication engineers? Isn't LTP intended for more than just spacecraft?

>>>Summing up, I think you’ll have a stronger paper if you simplyremove LTP from it altogether and stick to a survey of protocols
>>>that deliver errored content.
>>That's the second time you've brought that up. Scott, you're
>>suggesting any and all analysis or criticism of LTP be removed from
>>our paper -- and you're an author of the LTP specifications.
>
>No, I don't think I was doing that.  I was offering an observation that I thought might help you and your co-authors remove some errors from your paper, on the chance that the errors arose from an honest misreading of the LTP specification.

Consider the possibility that our paper isn't errored in its discussion of LTP, because LTP can deliver errored content ('expected' is not a mandatory MUST, as we discussed, Stephen tells me that his LTP code can do this), that we discuss segmentation of LTP frames because we know that LTP-T explicitly permits fragmentation and that LTP can be carried over complex link layers that do segment packets, and that we discuss the negative effects of LTP's lack of a checksum or any self-checking for these reasons and because it's so unusual in a transport protocol.

>You are of course free, Lloyd, to disregard that observation and publish whatever you feel like.  Obviously you are a man who is immune to embarrassment, for which I salute you.

I note that you were very selective in the points that you replied to. Again, what do you believe LTP green packets will be used for? What is the value in green packet erasures? And why not also just mandate that the link-layer frame use available link ARQ for reliable delivery?

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/ 

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

From: "Peter Lovell" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Date: Mon, 23 Jul 2007 17:32:23 -0400
Sender: [email-masked]

On Tue, Jul 17, 2007, Lloyd Wood <[email-masked]> wrote:

>We have also done some work to address one of the areas of weakness that
>we have identified in that paper, by writing an internet-draft:
>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/
>draft-eddy-dtnrg-checksum/draft-eddy-dtnrg-checksum-00a.txt
>The DTN Bundle Protocol Payload Checksum Block
>Wesley M. Eddy and Lloyd Wood.
>
>Abstract -
>   The Delay-Tolerant-Networking Bundle Protocol includes a custody
>   transfer mechanism to provide acknowledgements of receipt for
>   particular bundles.  No checksum is included in the basic DTN Bundle
>   Protocol, however, so it is not possible to verify that bundles have
>   been either forwarded or passed through various convergence layers
>   without errors having been introduced.  This document partially
>   rectifies the situation by defining a Bundle Protocol extension for
>   carrying payload checksums and describes how its use can be
>   integrated with both custody transfer and fragmentation.
>

Hi all,

it's true that the basic Bundle Protocol doesn't include an integrity
mechanism, that being part of the Bundle Security Protocol BSP extensions. 

But this suggestion doesn't alter that fact, but provides a different
extension scheme to achieve verification.

There's nothing proposed here which can't be done within BSP. The only
advantage is that the "mandatory ciphersuites" aren't present, which
does lead to reduced footprint, an advantage for certain cases.

I suggest that if we need a lightweight integrity protocol, we do it in
the context of bundle security protocol rather than creating something
else to do essentially the same job. I *really* do not want to have
integrity/security extensions which are separate from BSP as these
create vulnerabilities. The obvious example is the checksum [end-to-end]
on a bundle which is encrypted at a gateway node. The bundle is
encrypted but the checksum for the plaintext is not. Not good.

Better to do this task with a BSP-aware protocol so that BSP knows how
to protect things.

In short, we can have additional security/integrity mechanisms but we
should *not* have them outside the general umbrella of the security spec.

Regards.....Peter

Date: Mon, 23 Jul 2007 19:53:25 +0100
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
CC: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Agenda now in the right place...
Sender: [email-masked]

Peter Lovell wrote:
> Hi Stephen,
> 
> is there a plan for dial-in for this session?
> 

Unfortunately not. (In fact, we've tried that before and it
doesn't work well, maybe the rooms are just too big.)	

There is audio out [1] and jabber [2] (with a near-realtime
log [3]).

If people want, I'll try find a jabber scribe who can reflect
remote comments at the mic. Do you want that? (Anyone want to
volunteer to be jabber scribe?)

S.

[1] http://videolab.uoregon.edu/events/ietf/ietf693.m3u
[2] [email-masked]
[3] http://www.ietf.org/meetings/ietf-logs/dtnrg/

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re: [dtn-interest] Agenda now in the right place...
Date: Mon, 23 Jul 2007 14:37:12 -0400
Sender: [email-masked]

On Sun, Jul 22, 2007, Stephen Farrell <[email-masked]> wrote:

>
>...at [1], now that I've gotten my access sorted.
>
>If presenters could send me their slides in ppt or pdf
>before the session that'd be good.
>
>Sorry again about the delay,
>S.
>
>[1] http://www3.ietf.org/proceedings/07jul/agenda/DTNRG.html

Hi Stephen,

is there a plan for dial-in for this session?

THanks.....Peter

Date: Mon, 23 Jul 2007 07:56:18 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparing protocols for reliability errored delivery.
Sender: [email-masked]

Lloyd Wood wrote:
> At Wednesday 18/07/2007 00:48 -0700, Scott Burleigh wrote:
>> The very interesting and concisely introduced concept of errored
>> content was new to me, as it’s a communication service that I can’t
>> recall any deep space science mission ever asking for.
> 
> Errored content is something that we normally strive to avoid, using
> checksums. Deliberately letting errors pass up the stack is
> relatively new, and worth examining. (I'm a little puzzled by the
> growing move to implement this support for allowing errors, though I
> can see the value for unidirectional broadcast and long-delay links,
> and also in saving unnecessary overlapping checksum computing effort
> throughout the network, which may become more important as MTU sizes
> rise.

Yes, avoiding this sort of duplication of effort and unnecessary bandwidth consumption was one of the design considerations underlying omission of checksums from LTP, which is designed to run directly over single hop deep-space RF links that are already heavily coded.

>> LTP is not, as you state, a transport-layer protocol that permits
>> delivery of errored payloads.
> 
> LTP propagates any errors in received payloads up the protocol stack
> to the bundle layer, without any checksums to prevent that from
> happening. That permits delivery of errored payloads.

Not if errored payloads are never received, in compliance with section 5 of the LTP specification.

>> Note that the last paragraph of section 5 of the LTP specification
>> says "The underlying data-link layer is required to never deliver
>> incompletely received LTP segments to LTP.  In the absence of the
>> use of LTP authentication [LTPEXT], LTP also requires the
>> underlying data-link layer to perform data integrity checking of
>> the segments received.  Specifically, the data-link layer is
>> expected to detect any corrupted segments received and to silently
>> discard them."
> 
> Just specifying that does not make it reality

Quite true, merely specifying something does not make it reality.  It provides guidance to those who implement and deploy the protocol and who wish it to provide satisfactory performance.

Similarly, the TCP and UDP specifications assume that IP is used as the underlying protocol.  Using some other underlying protocol will violate the specification and probably result in unsatisfactory performance.

The Saratoga specification requires that UDP checksums be turned on when the protocol is used over IPv4.  Using Saratoga over UDP/IPv4 with UDP checksums turned off will violate the specification and probably result in unsatisfactory performance.

>> the intent of the design is that each LTP segment is to occupy a
>> single lower-layer frame (see section 4.1 of the spec), so that the
>> checksumming in that lower-layer frame protects the integrity of
>> the segment against errors caused by transmission noise.  A
>> lower-layer checksum in a frame carrying an LTP segment is not just
>> "desirable", it is explicitly mandatory.
> 
> That seems to be hoping for a bit much. If a lower-layer checksum is
> mandatory, you would expect to see a MUST rather than "expected" in
> the specification.

A very constructive suggestion.  Using the word "MUST" in this context rather than "is expected to" would very likely improve the spec.

> But, as an eventual standards process point, such
> a MUST/required is being applied not to LTP, but the universe of
> link-layer protocols outside LTP and outside the IETF's control.

No, it's being applied to conformant deployments of the LTP protocol, in exactly the same way that the requirement that UDP checksums be turned on over IPv4 (for example) applies to conformant deployments of the Saratoga protocol.

> The assumptions in the LTP specification are that:
> 
> - an LTP packet will always fit into a single link-layer frame
> without further segmentation. Given the vast number of possible link
> layers for LTP, this is unlikely, as it rules out classes of link
> layer, or mandates that LTP be must run over UDP/IP over that class
> of link layer to get protection against bugs in reassembly of
> segmented packets.

Sure, it's possible that there are some underlying link-layer protocols for which LTP won't be suitable.  The deep-space link-layer protocols for which it is principally intended are fine, though.

> - that link-layer frame will always checksum the entire LTP packet
> robustly and detect ALL possible errors. This assumes that the
> checksums of all link layers are equivalent in protecting against
> errors, so that LTP packets are uniformly robust and equivalent in
> integrity no matter what link layer they have travelled over.

No, it assumes that the checksum of the underlying link layer is strong enough to meet the requirement identified in the specification.  That strength may differ in different environments, which may well be traversed using different link-layer protocols.

> - there is no intermediate-processing corruption, after the link
> checksum check has been carried out (though mandating single frames
> reduces the amount of processing required, and the possibility of
> corruption occurring).

Yes, bugs in the implementation of the link-layer protocol will typically result in errors in data delivery; so will bugs in the implementation of LTP.  This is true of many protocols.

> - the link-layer frame will not be subject to reliable ARQ, as
> deciding to do ARQ or not (for red/green packets) is solely LTP's
> job.

No, the LTP specification doesn't require that the link-layer protocol do -- or not do -- its own ARQ.  The additional ARQ would likely be a waste of cycles and bandwidth, but that's a system engineering issue; it will always be possible to include LTP in a protocol stack that is badly configured.

>> A small number of undetected flipped bits in a set of engineering
>> telemetry records or a multispectral image could induce people to
>> make some expensive mistakes.
> 
> Yes. Good to see that you acknowledge the problem of undetected
> flipped bits (whether from transmission or from processing/storage).
> Perhaps you'd like to suggest how the LTP specification could be
> improved to detect and prevent these?

No, I prefer to make it clear to spacecraft communication engineers that the required design elements of LTP don't duplicate the detection and correction of corrupt data that is already accomplished by heavily encoded link-layer protocols and ECC memory.

>> Summing up, I think you’ll have a stronger paper if you simply
>> remove LTP from it altogether and stick to a survey of protocols
>> that deliver errored content.
> 
> That's the second time you've brought that up. Scott, you're
> suggesting any and all analysis or criticism of LTP be removed from
> our paper -- and you're an author of the LTP specifications.

No, I don't think I was doing that.  I was offering an observation that I thought might help you and your co-authors remove some errors from your paper, on the chance that the errors arose from an honest misreading of the LTP specification.

You are of course free, Lloyd, to disregard that observation and publish whatever you feel like.  Obviously you are a man who is immune to embarrassment, for which I salute you.

Scott

Date: Sun, 22 Jul 2007 21:31:50 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Agenda now in the right place...
Sender: [email-masked]

...at [1], now that I've gotten my access sorted.

If presenters could send me their slides in ppt or pdf
before the session that'd be good.

Sorry again about the delay,
S.

[1] http://www3.ietf.org/proceedings/07jul/agenda/DTNRG.html

To: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Sun, 22 Jul 2007 10:23:33 -0700
Subject: [dtn-interest] problems with the server yesterday
Sender: [email-masked]

Yesterday we had an A/C failure in our machine room, resulting in  
interruption to the DTN web page and mailing lists.  This is a test  
email to see if it is working better now....

- Kevin

From: Darren Long <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Date: Sun, 22 Jul 2007 12:31:36 +0100
To: [email-masked]
Sender: [email-masked]

Hi all,

I find this to be an interesting topic of discussion, and I can't  
help but chip in with some comments of my own.

One possible concern that isn't addresses in the paper is the degree  
of error detection capability in the implemented CLs in the DTN2  
reference implementation.  I'm thinking specifically of the TCP and  
UDP CLs.

In the UDP CL implementation, bundles are accepted for transmission  
up to the maximum UDP datagram size (64kB).  With typical link MTU  
sizes, this bundle/datagram would undergo IP fragmentation, which is  
apparently to be considered "very harmful" to data integrity in the  
"right" circumstances.

Is it the intention to resort to bundle protocol extensions to handle  
the detection of residual errors above the CL, or should there be  
strong enough mechanisms in the CL itself?

Similarly, the TCP CL implementation provides no additional error  
detection mechanisms above TCP itself, which suffers from the same  
check-summing weakness as UDP.  My concern with the TCP CL relates to  
TCP operation over routes bisected with TCP PEPs.  There are PILC  
documents that describe the potential impact of TCP PEPs to the end- 
to-end assumption of TCP, and coupling this with the additional  
potential for the PEPs to inject errors undetectable by the TCP/IP  
stack suggest to me that additional integrity checking should be  
provided in the CL, where I believe more efficient recovery options  
are available.

I wonder what others think?

Cheers,

Darren

Date: Sun, 22 Jul 2007 10:03:24 +0100
To: Scott Burleigh <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Cc: [email-masked]
Sender: [email-masked]

At Wednesday 18/07/2007 00:48 -0700, Scott Burleigh wrote:
>Lloyd Wood wrote:
>>We have written up a paper examining reliability in protocols, and
>>comparing four different transport protocols that offer delivery of
>>errored data to applications. The insights gained in this work allow
>>us to identify areas of the Licklider and bundle protocols where
>>reliability suffers and more design work is needed. This paper
>>fleshes out the ideas I expressed at the Dublin meet.
>>http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage-submitted.pdf
>> Checksum Coverage and Delivery of Errored Content
>>Lloyd Wood, Wesley M. Eddy, Jim McKim and Will Ivancic
>
>Lloyd, thanks for posting this. 

You're welcome.

(speaking solely for myself here. I really should let the paper stand for itself, but can't accept your comments or let them pass without responding.)

> I very much enjoyed the paper’s thorough explication of checksum coverage and your survey of the ways in which that protection is provided in widely used communication protocols.  

Thankyou.

>The very interesting and concisely introduced concept of errored content was new to me, as it’s a communication service that I can’t recall any deep space science mission ever asking for.

Errored content is something that we normally strive to avoid, using checksums. Deliberately letting errors pass up the stack is relatively new, and worth examining. (I'm a little puzzled by the growing move to implement this support for allowing errors, though I can see the value for unidirectional broadcast and long-delay links, and also in saving unnecessary overlapping checksum computing effort throughout the network, which may become more important as MTU sizes rise. It just seems like an edge case, of use to far too few applications and in far too few topologies to be generally worth bothering with, and a bad fit with existing network stacks, which overlap checksum coverage across multiple layers.)

>Something odd happens on page 7, when you start talking about LTP.  The appropriately dispassionate technical tone of the paper up to that point gives way to some surprisingly loaded language: LTP "claims" to permit carriage of reliable and partially reliable payloads,

LTP's "partially reliable" service is not SCTP's "partially reliable" service. SCTP packets are always checksummed with a strong CRC. LTP's packets are not, so the services are not equivalent. We indicate that the term "partially reliable" should not be taken at face value -- untangling the term and differentiating between repeatedness and integrity has taken me quite some time (had to write the paper as part of that process), and avoiding the confusion for others seems worthwhile. 

The term "reliable" conflates delivery and content, and is best qualified to indicate which is being referred to. If used unqualified, it's presumed that both reliable delivery of packets and reliable content in the delivered packets (for both payloads and headers) are provided, in the sense that TCP is 'reliable' - even though TCP's checksum is relatively weak, it's always there. When we say 'reliable', what do we really mean? Similarly, if one of these two properties is missing, the protocol must be unreliable.

> "one would hope" that its frames are checksummed, LTP "unlike many of the protocols described here, is clearly not robust or error-rejecting".

The paper defines robustness as the ability to self-check to ensure frame integrity. LTP does not detect or reject errors in its own headers or payloads (which would require checksum protection - the cross-hatched lines shown on the diagrams, which LTP lacks). However, LTP needs to do just that detection and rejection, since LTP can be run over a vast variety of link layers which may not provide adequate levels of protection (in coverage, or in strength of coverage) for LTP, or which may introduce packet corruption in passing their payloads to LTP.

>  The "Also of interest" paragraph on page 8 is especially puzzling, as it’s a discussion of the relative length and complexity of the LTP and Saratoga specifications, far removed from the subject of the paper.   

It's a simple observation that protocol reuse leads to simpler protocol specification, since you can build on what has gone before. As you say, it's a single paragraph - in a ten-page paper.

>A suspicious mind might speculate that this otherwise meticulously researched and scrupulously objective paper is merely a pretext for initiating a little hatchet job on LTP, for reasons that pass understanding.

We analyse protocols for checksums. In doing so, we point out that LTP has no checksum, and we explore the ramifications of that. (The ramifications of not having checksums are probably greater for Stephen's LTP-T.)

>But this is of no consequence, as I think you probably need to remove all mention of LTP from the paper anyway.  It is completely orthogonal to your subject.

Hardly. LTP permits delivery of errored content, just like UDP-Lite, Saratoga and DCCP. However, unlike UDP-Lite, Saratoga over UDP/UDP-Lite, and DCCP,  LTP does not limit where the errors can occur, and does not check the integrity of its own headers (or trailers) - that's rather rare in any transport protocol design, and that fact alone would be worthy of comment in itself. Examining the failure modes resulting from corruption of individual header/trailer fields would also be interesting.

LTP and the bundle protocol both show a failing to follow the simple principle of always checking that what is received is what was sent, or that integrity of content is always preserved. (That can only be achieved as a welcome unintentional side-effect of their optional security frameworks.) LTP's lack of robustness would matter less if the overlaying bundle protocol was always robust and implemented end-to-end integrity checks. A lot of reliance is placed on the LTP and bundle security frameworks to cover the headers and payloads and to address that shortcoming.

As it is, since LTP and the bundle protocol do not check the integrity of their payloads or headers, they push reliability checks down to the link layer (substituting for LTP) and up to the application for an end-to-end check (substituting for the bundle).

> LTP is not, as you state, a transport-layer protocol that permits delivery of errored payloads.  

LTP propagates any errors in received payloads up the protocol stack to the bundle layer, without any checksums to prevent that from happening. That permits delivery of errored payloads.

>There is nothing in the design of LTP that contemplates the delivery of data in which even a single bit is flipped, ever.  

Exactly. And that is the LTP design's greatest failing; the possibility that an LTP packet received may be corrupted in any way in its payload or headers/trailers is just not countenanced in its base design. LTP lives in a perfect world - yet the real world isn't perfect.

I suggest that the LTP designers read Stone's papers on observations on the occurrence of errors in real systems.

>Note that the last paragraph of section 5 of the LTP specification says "The underlying data-link layer is required to never deliver incompletely received LTP segments to LTP.  In the absence of the use of LTP authentication [LTPEXT], LTP also requires the underlying data-link layer to perform data integrity checking of the segments received.  Specifically, the data-link layer is expected to detect any corrupted segments received and to silently discard them."

Just specifying that does not make it reality - and, more importantly,  that expectation is not sufficient. That won't detect bugs in the data-link layer delivering packets to LTP, for example. The link-layer may receive a packet just fine, but a software bug could overwrite part of the packet after link-layer checking and before delivery to LTP. LTP (and the bundle layer above it, which doesn't implement a checksum either) may never know, because they don't test to find out -- they just presume all is fine in headers and data. Again, Stone (referenced in the paper) has covered this issue in real systems in some depth.

>That is, the premise on which all of section V.D is written is incorrect.  LTP is designed to be used directly over a variety of link protocols, exactly as you say on page 8.  It is not an end-to-end transport protocol that requires its own checksum to protect against errors in intermediate processing;

yet it relies on travelling over link layers that must implement protective checksum, and any errors introduced will be duplicated, hop by hop. (And LTP-T is intended as such a protocol, no?)

> the intent of the design is that each LTP segment is to occupy a single lower-layer frame (see section 4.1 of the spec), so that the checksumming in that lower-layer frame protects the integrity of the segment against errors caused by transmission noise.  A lower-layer checksum in a frame carrying an LTP segment is not just "desirable", it is explicitly mandatory.

That seems to be hoping for a bit much. If a lower-layer checksum is mandatory, you would expect to see a MUST rather than "expected" in the specification. But, as an eventual standards process point, such a MUST/required is being applied not to LTP, but the universe of link-layer protocols outside LTP and outside the IETF's control. Good luck with ever enforcing that "mandatory" requirement. And that requirement still won't help with overall system reliability, as Stone's work and the end-to-end principle point out.

(Since LTP packets are supposed to fit in individual link-layer frames, why not also mandate that the link-layer frame use available link ARQ for reliable delivery? That would remove the need for LTP to do ARQ, in much the same way that link checksums are thought to suffice for higher checksums. If the problem of ensuring reliable content is handed off to the link layer, the problem of ensuring reliable delivery across the link can certainly also be handed off to the link layer as well. And the link-layer ARQ mechanism should always be appropriate for the link.)

The assumptions in the LTP specification are that:

- an LTP packet will always fit into a single link-layer frame without further segmentation. Given the vast number of possible link layers for LTP, this is unlikely, as it rules out classes of link layer, or mandates that LTP be must run over UDP/IP over that class of link layer to get protection against bugs in reassembly of segmented packets. (I see Stephen relaxes this segmentation requirement for LTP-T, which will have greater reliability problems here.)

- that link-layer frame will always checksum the entire LTP packet robustly and detect ALL possible errors. This assumes that the checksums of all link layers are equivalent in protecting against errors, so that LTP packets are uniformly robust and equivalent in integrity no matter what link layer they have travelled over. All checksums are equivalently infinitely strong, leading to perfect LTP packets. In reality, LTP over different links becomes "variably reliable" - which is to say, unreliable. This means bundle contents are at the mercy of the least reliable link in the path, and that a single bad/buggy/weakly-checked link layer can corrupt LTP packets and bundles -- undetectably, if the security frameworks aren't in place.

- there is no intermediate-processing corruption, after the link checksum check has been carried out (though mandating single frames reduces the amount of processing required, and the possibility of corruption occurring).

- the link-layer frame will not be subject to reliable ARQ, as deciding to do ARQ or not (for red/green packets) is solely LTP's job.

Those assumptions cannot be guaranteed in reality.

LTP does not check for errors itself. LTP relies on a link-layer checksum to catch transmission errors. LTP also relies on a higher-layer end-to-end checksum to catch any processing errors (which the bundle format doesn't provide, so we've now proposed one in a draft to cover at least some of the bundle payload).

Given this, how can LTP be described as "a reliable convergence layer" when LTP clearly is not reliable? 'An unreliable convergence layer offering reliable or unreliable delivery" would be a more accurate description of LTP.

>Also, LTP’s "partial reliability" concept is carefully explained  or, if you prefer, "bounded"  in section 3.3 of the LTP Motivation draft: "
>LTP regards each block of data as comprising two parts: a 'red-part', whose delivery must be assured by acknowledgment and retransmission as necessary, and a 'green-part' whose delivery is attempted, but not assured."  Acknowledgment and retransmission, not checksum. 

...simply because there are no checksums in LTP, which is a rather interesting point worth making in a paper discussing checksum coverage and reliability in protocols, don't you think? (We make similar observations about the weaknesses of the IPv6 header design, which have to be compensated for by having every transport layer over IPv6 - even ICMP - include a pseudo-header checksum.)

> This is "reliability" in the sense of what you call "delivery" reliability in section I, the sense in which TCP is often characterized as a "reliable" protocol, not reliability in the sense of "being able to trust" the data in received packets (which, I agree, is a valuable and interesting distinction). 

It's not just necessary to know that you can trust and rely on the payload data - it's necessary to be able to trust and rely on the headers that frame that data for correct delivery of that data, too.

> It is in fact vaguely similar to the "partial reliability" extension for SCTP, which likewise identifies circumstances under which the rules on acknowledgment and retransmission of some part(s) of a data unit in transit may be set aside.  

"Vaguely similar" is too... vague. The SCTP partial reliability extension is concerned solely with varying acknowledgement repeat persistence, which it goes into in some detail.  SCTP is concerned solely with that persistence because SCTP packets are always checksummed with a strong CRC, so the other requirement for reliability - that of getting the same header and payload data that was sent - doesn't come into it. That SCTP checksum covers the payload and headers. LTP doesn't have that.

Yes, you could say that LTP's partially reliable service is just less reliable and simply "more partial" than SCTP's partially reliable service, as SCTP has both the checksums and limited persistence, while LTP green packets have no checksums and no persistence (unless, of course, the link ARQ gives green packets unwanted persistence anyway). But, instead of using the ambiguous term 'partial reliability', just use the word 'unreliable'. It's much clearer to the reader.

>Neither has anything to do with
>varying the portion of the data unit that is covered by the checksum, as in DCCP and UDP-Lite.

LTP packets are not checksummed and not reliable. Varying the portion of the data unit covered by the checksum simply can't be done in LTP  - simply because LTP has no checksum. As a transport protocol, LTP is basically equivalent to UDPv4 with checksums always turned off. You can probably get away with turning off UDP checksums if you run UDP over IPsec end-to-end to compensate; similarly, you can have LTP security and the NULL authentication sort-of compensate for the lack of LTP checksums. The problem here is that the NULL authentication and hardcoded key are entirely optional - just like having IPsec cover for turning off the shown-to-be-problematic UDPv4 checksum - which is why the UDPv6 checksum is mandatory. Integrity should be mandatory, or at least bounded - where you know you can trust the frame headers, but not the payload, say.

>Perhaps this clears up the paradox you encountered on determining that the full lower-layer checksum that is required for the protection of "red" segments prevents the use of "green" segments for delivery of errored content to the application: "green" LTP segments were never intended to be used for any such purpose, so there is no paradox.

Since LTP leaves out a checksum, the green segments can clearly be used for such a purpose - though they're clearly most useful for that purpose when the lower stack does not contain checksums that reject errored packets before they reach LTP and then bundles and the application, since otherwise only corruption due to processing (bugs, memory event upsets) is passed up.

So what do you believe green packets will be used for? The fact remains that LTP packets can be used for the delivery of errored payloads. (Though, given that the headers can be errored as well, delivery is less trustworthy than the other protocols we examine.)

Again, the paradox is this:
- a green packet is sent over a link layer that checks data integrity.
- the link layer detects a problem in receiving the packet, because say a single bit was flipped.
- the packet is not passed to LTP.

A bit flip is turned into a packet-length erasure; it might be simpler and more efficient to never send the green packets at all, since they're optional. But since a green packet is supposed to fit into a single link frame that can be ARQ'd with link ARQ, a 'partly unreliable' green frame can always arrive at the next hop, thanks to that ARQ mechanism. Another paradox - and one worth including in the paper.

>The reason for this, again, is that LTP was not designed for the delivery of errored payloads.  It was designed for reliable transmission over deep-space RF links.  

More accurate to say that LTP was not designed to protect against errored payloads. LTP's design and specification permits delivery of errored payloads as a consequence of not checking for payload (or header) errors.

"Reliability" encompasses content and delivery - delivery of all packets can lead to reliable content, but is not in itself sufficient. A protocol should include checks on the reliability of its headers and payloads. LTP doesn't do that. How can LTP be called reliable, when it doesn't check that it's reliable?

Let's look again at figure 1 of the paper. LTP doesn't check the integrity of its own headers or its payload. The bundle payload doesn't check the integrity of itself or its payload (but needs to, since LTP isn't endhost-to-endhost, unlike others transport protocols, so relying on the bundle and LTP code being colocated and hoping for the best, as e.g. web browsers do, doesn't suffice). The stack model followed is 1(d), where any checking is left solely to the link layer. That's not reliable.

The deep-space link is supposed to ensure reliability here by preventing all transmission errors before LTP sees them? Why does the link need LTP, then? It could use its own ARQ, which would suffice in the same way link checksums are said to suffice. Why does the bundle protocol need LTP, when it can just run direct over the link layer or over UDP/IP over that link layer?

(btw, "reliable transmission" conflates delivery and content - transmission of symbols. Not a good term imo.) 

>Such links are currently used only by spacecraft on scientific missions, and it has been our experience that neither spacecraft operators nor deep space mission scientists have much interest in errored data. 

I would think that spacecraft operators and deep space mission scientists have a _lot_ of interest in _preventing_ errored data.

> A small number of undetected flipped bits in a set of engineering telemetry records or a multispectral image could induce people to make some expensive mistakes.

Yes. Good to see that you acknowledge the problem of undetected flipped bits (whether from transmission or from processing/storage). Perhaps you'd like to suggest how the LTP specification could be improved to detect and prevent these?

LTP and the bundle protocol can give deep space mission designers errored content - and, as you say, they don't want it. You seriously expect spacecraft designers to use and rely on such unreliable protocols that can let errored data through? Really?

>  Moreover, in many cases the data from spacecraft are compressed to optimize bandwidth utilization, and bit errors in compressed data records tend to make recovery of the original uncompressed data difficult.

So they won't be sent using green packets, then. I think the LTP specification could be strengthened by removal of all "green" specification; the LTP specification is complex enough as is.

>So you are quite correct in saying that LTP not as capable as, say, Saratoga as a means of streaming "Everybody Loves Raymond" in high definition from low Earth orbit. 

I did not say that.

Are you saying that LTP green packets can't be used for streaming of, say, time-sensitive telemetry that is considered useless if it arrives too late? Time sensitivity and not requiring ARQ since the resend would miss its useful window, as in VoIP, is the only reason I can think of for using green packets - though that's not a good fit with bundle transfers, and LTP lacks the variable persistence of SCTP.

Speaking of things we say, Joab Jackson's IEEE Spectrum article has you on record as saying that LTP makes a link reliable. Really? It would seem that the link makes LTP reliable.

> It’s also not as capable as ibuprofen as a means of relieving headaches.  Neither fact is relevant.
>
>Summing up, I think you’ll have a stronger paper if you simply remove LTP from it altogether and stick to a survey of protocols that deliver errored content. 

That's the second time you've brought that up. Scott, you're suggesting any and all analysis or criticism of LTP be removed from our paper -- and you're an author of the LTP specifications. Do you realise what that attempt at suppression of criticism and discussion of LTP's problems looks like?

Comparisons made between other protocols and LTP are entirely valid. The LTP design permits delivery of errored content, and has no mechanisms to prevent that from occurring. Saying 'must be run over a link layer with a strong but unspecified checksum' is not much of a mechanism. Unlike many of the other protocols surveyed, LTP also does not check the integrity of its own headers or trailers, which is certainly worthy of note. (To give an example, unlike LTP, even ATM cells always check their headers to make sure the description of what they are carrying is accurate - and, unlike the bundle protocol, AAL5 frames' headers and trailers are always checksummed too.)

LTP can deliver errored content, because LTP does not check for errors. LTP simply delivers any errors to the application. LTP does not protect against errored content. LTP's design permits this.

Summing up, I think you'll have a stronger protocol that will be more reliable if you include a checksum (though making that optional NULL authentication mandatory might well work).

>Section VI of the paper seems like an excellent discussion of how to engineer an optimum stack along these lines.

Yes. Though whether this would really be worth doing for the set of applications that could usefully take advantage of it is worth asking.

>One last thought: I think your proposal to add a checksum block as a Bundle Protocol extension is excellent, for just the reasons you discuss in sections I and II.  

And in my opinion it's a shame that we had to write that draft. I personally view the lack of attention paid to reliability and the well-known lessons of the end-to-end principle in the designs of the LTP and bundle specifications as weaknesses in their designs. An attempt to address these engineering design failings should be made, and that's what we've expended time and effort to lead the way on.

As for "reasons that pass understanding" - if the reasons in sections I and II are new to you, I strongly recommend reading Saltzer's and Stone's papers, as referenced.

> I haven’t had time to read your draft yet, but I think the concept has a lot of merit.

Yes, reliability has merits. Perhaps a DTN reliability workshop would be a good idea? See you in Chicago.

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

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

Date: Sat, 21 Jul 2007 17:43:18 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Next week's agenda...
Sender: [email-masked]

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

Coulple of corrections in the attached.

- Fixed spelling of Jim's name
- Added Tom Henderson's ns-3 slot (that I'd forgotten:-)

Cheers,
S.

--------------000501010501090304020307
Content-Type: text/html; charset=ISO-8859-1;
 name="ChicagoAgenda.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ChicagoAgenda.html"

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
       "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
  <title>DTNRG Meeting Agenda and Logistics</title>
  <meta name="generator" content="amaya 9.2.1, see http://www.w3.org/Amaya/"
  />
</head>

<body>
<h1>DTNRG IETF-69 Meeting</h1>

<p>This file was last changed on 20070721.</p>

<p>The meeting will be in the IETF meeting hotel, in Salon 3 on Tuesday
0900-1130.</p>

<h2><a id="Agenda">Agenda</a></h2>

<table border="1">
  <tbody>
    <tr>
      <td>Time</td>
      <td>Topic</td>
      <td>Who</td>
    </tr>
    <tr>
      <td>0900-0905</td>
      <td>Welcome &amp; agenda bash</td>
      <td>Chairs</td>
    </tr>
    <tr>
      <td>0905-0930</td>
      <td>DTNRG document status/news</td>
      <td>Chairs</td>
    </tr>
    <tr>
      <td>0930-0940</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-farrell-dtnrg-km-00.txt">Key
        management requirements</a></td>
      <td>Stephen Farrell (TCD)</td>
    </tr>
    <tr>
      <td>0940-0950</td>
      <td>DTN reference code</td>
      <td>Mike Demmer (Berkeley)</td>
    </tr>
    <tr>
      <td>0950-1010</td>
      <td>DTN simulation: ns-3</td>
      <td>Tom Henderson (Boeing)</td>
    </tr>
    <tr>
      <td>1010-1030</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-wood-dtnrg-saratoga-01.txt">Saratoga</a></td>
      <td>Lloyd Wood (Cisco)</td>
    </tr>
    <tr>
      <td>1030-1120</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-wyllie-dtnrg-badisc-00.txt">Node
        discovery</a></td>
      <td>Jim Wyllie (Ohio U.)</td>
    </tr>
    <tr>
      <td></td>
      <td>AOB</td>
      <td></td>
    </tr>
  </tbody>
</table>
</body>
</html>

--------------000501010501090304020307--

Date: Sat, 21 Jul 2007 14:01:24 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Next week's agenda...
Sender: [email-masked]

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

...attached.

Still room for a few more small slots, just mail Kevin and I
if you want one, saying what its about and how long you'd
like,

Cheers,
S.

PS: Kevin - can you post this to the meeting materials page,
still doesn't work for me.

--------------060608020506030903070702
Content-Type: text/html; charset=ISO-8859-1;
 name="ChicagoAgenda.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ChicagoAgenda.html"

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
       "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
  <title>DTNRG Meeting Agenda and Logistics</title>
  <meta name="generator" content="amaya 9.2.1, see http://www.w3.org/Amaya/"
  />
</head>

<body>
<h1>DTNRG IETF-69 Meeting </h1>

<p>This file was last changed on 20070721.</p>

<p>The meeting will be in the IETF meeting hotel, in Salon 3 on Tuesday
0900-1130.</p>

<h2><a id="Agenda">Agenda</a></h2>

<table border="1">
  <tbody>
    <tr>
      <td>Time</td>
      <td>Topic</td>
      <td>Who</td>
    </tr>
    <tr>
      <td>0900-0905</td>
      <td>Welcome &amp; agenda bash</td>
      <td>Chairs</td>
    </tr>
    <tr>
      <td>0905-0930</td>
      <td>DTNRG document status/news</td>
      <td>Chairs</td>
    </tr>
    <tr>
      <td>0930-0940</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-farrell-dtnrg-km-00.txt">Key
        management requirements</a></td>
      <td>Stephen Farrell (TCD)</td>
    </tr>
    <tr>
      <td>0940-0950</td>
      <td>DTN reference code</td>
      <td>Mike Demmer (Berkeley)</td>
    </tr>
    <tr>
      <td>0950-1010</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-wood-dtnrg-saratoga-01.txt">Saratoga</a></td>
      <td>Lloyd Wood (Cisco)</td>
    </tr>
    <tr>
      <td>1010-1100</td>
      <td><a
        href="http://www.ietf.org/internet-drafts/draft-wyllie-dtnrg-badisc-00.txt">Node
        discovery</a></td>
      <td>Jim Wylie (Ohio U.)</td>
    </tr>
    <tr>
      <td></td>
      <td>AOB</td>
      <td></td>
    </tr>
  </tbody>
</table>
</body>
</html>

--------------060608020506030903070702--

Date: Sat, 21 Jul 2007 13:59:18 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Agenda for DTN meeting?
Sender: [email-masked]

Thanks for the subtle and friendly reminder;-)

I assume the Satatoga presentation will be different from
the one you gave in Dublin.

S.

Cc: [email-masked], [email-masked], [email-masked]
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] Agenda for DTN meeting?
Date: Fri, 20 Jul 2007 20:11:02 -0700
To: Lloyd Wood <[email-masked]>
Sender: [email-masked]

there was some issue with the data tracker... it should be up tomorrow.

- K

On Jul 20, 2007, at 1:09 PM@Jul 20, 2007, Lloyd Wood wrote:

> http://www.ietf.org/meetings/69-cutoff_dates.html
> says:
> July 11, Wednesday - Draft Working Group agendas due by 17:00 ET  
> (21:00 UTC/GMT), upload using <https://datatracker.ietf.org/cgi-bin/ 
> wg/wg_proceedings.cgi>IETF Meeting Materials Management Tool.
> [..]
> July 16, Monday - Revised Working Group agendas due by 12:00 ET  
> (16:00 UTC/GMT), upload using <https://datatracker.ietf.org/cgi-bin/ 
> wg/wg_proceedings.cgi>IETF Meeting Materials Management Tool.
>
>
> The agenda for next week's DTNRG meeting hasn't been issued yet -  
> unlike the agendas of almost all other meetings.
> https://datatracker.ietf.org/meeting/69/agenda.html
>
> It appears that, once again, a set deadline (actually, TWO set  
> deadlines...) has been missed by the chairs.
> http://mailman.dtnrg.org/pipermail/dtn-interest/2007-May/002715.html
>
> Please fix asap.
>
> (as a reminder, I requested a 20-minute slot on Saratoga from Kevin  
> back at the start of June.
> http://tools.ietf.org/id/draft-wood-dtnrg-saratoga-01.txt  )
>
> L.
>
> http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
>
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

To: [email-masked], [email-masked], DTN dev <[email-masked]>, [email-masked]
From: "S. Keshav" <[email-masked]>
Date: Fri, 20 Jul 2007 16:32:35 -0400
Subject: [dtn-interest] KioskNet system release
Sender: [email-masked]

We are pleased to announce the availability of the KioskNet system  
[1] developed by the Tetherless Computing Research Group at the  
University of Waterloo, Canada.

Rural Internet kiosks in developing countries provide a variety of  
services such as birth, marriage, and death certificates, land  
records, and consulting on medical and agricultural problems.  
Fundamental to a kiosk's operation are the robustness of the kiosk  
computer and its connection to the Internet.  Unfortunately, most  
existing solutions do not reflect the underlying constraints, leading  
to  widespread failure [2]. We address these issues in KioskNet,  
which builds on two key ideas:

    1. Using a single-board-computer-based, low-cost, low-power  
‘kiosk controller’ at each kiosk. The controller communicates  
wirelessly with another single-board computer mounted on a vehicle  
(as was pioneered by Daknet). These vehicles carry data to and from a  
gateway, where data is exchanged with the Internet. This 'mechanical  
backhaul' avoids the cost of trenches, towers, and satellite dishes.

    2. Allowing refurbished PCs to boot an OS from a kiosk  
controller. Kiosk controllers are tamper-proof so they offer reliable  
virus-free boot images and binaries. By avoiding the use of the hard  
disk of the PC, hard disk failures or viruses on the disk do not  
affect users. Moreover refurbished PCs are cheap and spare parts are  
widely available.

Besides:

     * Our code is free and open-source with no patent, copyright or  
intellectual property restrictions, under the Apache license.

     * The system is low cost and economically viable: we estimate  
that our system requires a capex of ~$100 - $700/kiosk, depending on  
the configuration, and an opex of ~$70/kiosk/month, including the  
cost of field technicians and capital depreciation [3].

     * The solution is rapidly deployable: we successfully installed  
a prototype in Anandapuram village, Vishakapatnam district, AP, in  
two days during May 2006 [4].

     * It is easy to remotely manage a kiosk, so a kiosk operator  
requires little or no IT expertise.

     * Kiosk controllers are low-power (6-8W), so they can be run off  
a solar panel.

     * Recycled PCs can run either the (Linux) binaries that are  
packaged with the kiosk controller, which are guaranteed to be virus  
free, or can boot into an existing operating system (typically  
Windows) from their hard drive for stand-alone computing.

   *  Our software is shipped in the form of a LiveCD that can be  
booted on any Windows or Linux PC and used to burn OS images directly  
onto hard drives, that are then installed in single-board computers.

We have developed a comprehensive deployment guide [5] to plan,  
purchase, deploy, and operate a KioskNet installation. Please feel  
free to contact [email-masked] with any questions or comments.

Sincerely,

S. Keshav

Associate Professor
School of Computer Science
University of Waterloo, Waterloo, ON, Canada
http://www.cs.uwaterloo.ca/~keshav

------

[1] http://blizzard.cs.uwaterloo.ca/tetherless/index.php/KioskNet
[2] http://blizzard.cs.uwaterloo.ca/tetherless/index.php/Why_Kiosks_Fail
[3] http://blizzard.cs.uwaterloo.ca/tetherless/index.php/ 
Details_of_cost_structure
[4] http://blizzard.cs.uwaterloo.ca/tetherless/index.php/ 
Installed_a_prototype_in_Anandapuram_village
[5] http://blizzard.cs.uwaterloo.ca/tetherless/index.php/ 
Deployment_guide

Date: Fri, 20 Jul 2007 21:09:54 +0100
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [dtn-interest] Agenda for DTN meeting?
Sender: [email-masked]

http://www.ietf.org/meetings/69-cutoff_dates.html
says:
July 11, Wednesday - Draft Working Group agendas due by 17:00 ET (21:00 UTC/GMT), upload using <https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi>IETF Meeting Materials Management Tool. 
[..]
July 16, Monday - Revised Working Group agendas due by 12:00 ET (16:00 UTC/GMT), upload using <https://datatracker.ietf.org/cgi-bin/wg/wg_proceedings.cgi>IETF Meeting Materials Management Tool. 

The agenda for next week's DTNRG meeting hasn't been issued yet - unlike the agendas of almost all other meetings.
https://datatracker.ietf.org/meeting/69/agenda.html

It appears that, once again, a set deadline (actually, TWO set deadlines...) has been missed by the chairs.
http://mailman.dtnrg.org/pipermail/dtn-interest/2007-May/002715.html

Please fix asap.

(as a reminder, I requested a 20-minute slot on Saratoga from Kevin back at the start of June.
http://tools.ietf.org/id/draft-wood-dtnrg-saratoga-01.txt  )

L.

http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/

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

To: [email-masked]
From: Raffaele Bruno <[email-masked]>
Date: Fri, 20 Jul 2007 14:52:42 +0200
Subject: [dtn-interest] CFP: Special Issue of Pervasive and Mobile Computing Journal (PMC) on Homeland and Global Security
Sender: [email-masked]

Our apologies if you receive multiple copies of this message
------------------------------------------------------------------------ 
-----------

          Call for Papers

Pervasive and Mobile Computing Journal

Special Issue on Homeland and Global Security

The development, deployment and coordination of pervasive and mobile  
computing (PMC) has been studied for a number of years, and much of  
this research is beginning to transition into real solutions for a  
variety of domains. One domain that is ripe for PMC research and  
development is homeland and global security. Much of the security  
mission involves the monitoring of various environments (e.g., ports,  
borders, mass transit hubs, financial centers, power grids, the  
Internet) and the prediction and detection of threats to these  
environments. PMC represents a general solution to maintaining  
security in these environments. In this special issue we seek  
contributions representing the state-of-the-art in PMC research and  
technology targeted toward homeland and global security. Components  
of such approaches include novel sensor and sensor systems for the  
detection of various threats, efficient and effective deployment of  
mobile devices and sensors in such environments, heterogeneous  
systems for surveillance and threat detection, secure and fault  
tolerant coordination and communication of sensors in homeland and  
global security environments, information fusion for prediction and  
detection of threats, integration and registration of data from  
multiple sources, and effective decision-making in dynamic  
environments. And since the nature of the challenge restricts in situ  
testing of the various approaches, high-fidelity simulation and  
modeling of such systems is necessary, including the mobile devices  
and sensors, their communication, the data produced, the  
characteristics of potential threats, and the temporal interaction in  
response to the sequence of events leading up to the threat.

The objective of this special issue is to gather high quality  
research papers that address PMC applied to the challenges of  
homeland and global security. Prospective authors are invited to  
submit manuscripts containing original research in this area. Topics  
on integrated and demonstrated systems and experiments with real- 
world data and involving users are highly encouraged. Topics of  
interests include, but are not limited to:

·    Sensors and sensor networks for threat detection
·    RFID-based tracking
·    Biometric devices
·    Biological/chemical sensors
·    Screening devices
·    Deployment of mobile devices and sensors
·    Secure and fault tolerant coordination and communication
·    Sensor data and information fusion
·    Decision-making in dynamic security environments
·    Command and control software systems
·    Testing and evaluation methodologies
·    Simulation and modeling of security domains and systems
·    Secure smart environments
·    Learning and training systems
·    Disaster mitigation and emergency response

Manuscripts must not have been previously published or currently  
under consideration for publication elsewhere.  The manuscript should  
be at least 1.5 spaced and must not exceed 30 pages (all inclusive.)  
If the paper was published in a conference, the submitted manuscript  
should be a significantly enhanced version. Authors are also required  
to submit their published conference articles and a summary document  
explaining the enhancements made in the journal version. The  
manuscript preparation guidelines can be obtained from the PMC  
Journal's web page (http://www.elsevier.com/locate/pmc).

Important Dates:    Deadline for submission: September 15, 2007
Author Notification: December 1, 2007
Revisions Due: February 1, 2008
Final Decision: March 15, 2008

Authors should submit their full manuscripts to the PMC Special  
Issues Editor-in-Chief, Behrooz Shirazi, using the Elsevier online  
Editorial System (EES) at http://www.elsevier.com/locate/pmc

Guest Editors:
Larry Holder, Mohan Kumar and  Raffaele Bruno

---------------------------------------------------------
Raffaele Bruno, Ph.D., Researcher
Pervasive Computing & Networking Lab. (PerLab)

IIT Institute - Italian National Research Council (CNR)
Via G. Moruzzi 1, 56124 Pisa, ITALY
Tel.: +39 050 315 3078 (direct)
Fax.: +39 050 315 2593 (institute)
Email: [email-masked]
Website: bruno1.iit.cnr.it/~bruno/

Cc: [email-masked]
From: Marshall Eubanks <[email-masked]>
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Date: Wed, 18 Jul 2007 11:42:31 -0400
To: Scott Burleigh <[email-masked]>
Sender: [email-masked]

On Jul 18, 2007, at 3:48 AM, Scott Burleigh wrote:

> Lloyd Wood wrote:
>> We have written up a paper examining reliability in protocols, and
>> comparing four different transport protocols that offer delivery of
>> errored data to applications. The insights gained in this work allow
>> us to identify areas of the Licklider and bundle protocols where
>> reliability suffers and more design work is needed. This paper
>> fleshes out the ideas I expressed at the Dublin meet.
>> http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet- 
>> drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage- 
>> submitted.pdf
>>  Checksum Coverage and Delivery of Errored Content Lloyd Wood, Wesley
>> M. Eddy, Jim McKim and Will Ivancic
>
> Lloyd, thanks for posting this.  I very much enjoyed the paper’s  
> thorough explication of checksum coverage and your survey of the  
> ways in which that protection is provided in widely used  
> communication protocols.  The very interesting and concisely  
> introduced concept of errored content was new to me, as it’s a  
> communication service that I can’t recall any deep space science  
> mission ever asking for.

The use I have heard of this is with mobile devices / cell phones,  
where both bandwidth and processing power
for FEC is extremely limited (and, of course, where bit errors are to  
be expected).

I frankly think that applying this to HDTV is problematic. True, in  
many cases you could drop a bit without much
trouble, but in other cases you might mess up the entire GOP.

Regards
Marshall

>
> Something odd happens on page 7, when you start talking about LTP.   
> The appropriately dispassionate technical tone of the paper up to  
> that point gives way to some surprisingly loaded language: LTP  
> "claims" to permit carriage of reliable and partially reliable  
> payloads, "one would hope" that its frames are checksummed, LTP  
> "unlike many of the protocols described here, is clearly not robust  
> or error-rejecting".  The "Also of interest" paragraph on page 8 is  
> especially puzzling, as it’s a discussion of the relative length  
> and complexity of the LTP and Saratoga specifications, far removed  
> from the subject of the paper.   A suspicious mind might speculate  
> that this otherwise meticulously researched and scrupulously  
> objective paper is merely a pretext for initiating a little hatchet  
> job on LTP, for reasons that pass understanding.
>
> But this is of no consequence, as I think you probably need to  
> remove all mention of LTP from the paper anyway.  It is completely  
> orthogonal to your subject.  LTP is not, as you state, a transport- 
> layer protocol that permits delivery of errored payloads.  There is  
> nothing in the design of LTP that contemplates the delivery of data  
> in which even a single bit is flipped, ever.  Note that the last  
> paragraph of section 5 of the LTP specification says "The  
> underlying data-link layer is required to never deliver  
> incompletely received LTP segments to LTP.  In the absence of the  
> use of LTP authentication [LTPEXT], LTP also requires the  
> underlying data-link layer to perform data integrity checking of  
> the segments received.  Specifically, the data-link layer is  
> expected to detect any corrupted segments received and to silently  
> discard them."
>
> That is, the premise on which all of section V.D is written is  
> incorrect.  LTP is designed to be used directly over a variety of  
> link protocols, exactly as you say on page 8.  It is not an end-to- 
> end transport protocol that requires its own checksum to protect  
> against errors in intermediate processing; the intent of the design  
> is that each LTP segment is to occupy a single lower-layer frame  
> (see section 4.1 of the spec), so that the checksumming in that  
> lower-layer frame protects the integrity of the segment against  
> errors caused by transmission noise.  A lower-layer checksum in a  
> frame carrying an LTP segment is not just "desirable", it is  
> explicitly mandatory.
>
> Also, LTP’s "partial reliability" concept is carefully explained –  
> or, if you prefer, "bounded" – in section 3.3 of the LTP Motivation  
> draft: "LTP regards each block of data as comprising two parts: a  
> 'red-part', whose delivery must be assured by acknowledgment and  
> retransmission as necessary, and a 'green-part' whose delivery is  
> attempted, but not assured."  Acknowledgment and retransmission,  
> not checksum.  This is "reliability" in the sense of what you call  
> "delivery" reliability in section I, the sense in which TCP is  
> often characterized as a "reliable" protocol, not reliability in  
> the sense of "being able to  trust" the data in received packets  
> (which, I agree, is a valuable and interesting distinction).  It is  
> in fact vaguely similar to the "partial reliability" extension for  
> SCTP, which likewise identifies circumstances under which the rules  
> on acknowledgment and retransmission of some part(s) of a data unit  
> in transit may be set aside.  Neither has anything to do with
> varying the portion of the data unit that is covered by the  
> checksum, as in DCCP and UDP-Lite.
>
> Perhaps this clears up the paradox you encountered on determining  
> that the full lower-layer checksum that is required for the  
> protection of "red" segments prevents the use of "green" segments  
> for delivery of errored content to the application: "green" LTP  
> segments were never intended to be used for any such purpose, so  
> there is no paradox.
>
> The reason for this, again, is that LTP was not designed for the  
> delivery of errored payloads.  It was designed for reliable  
> transmission over deep-space RF links.  Such links are currently  
> used only by spacecraft on scientific missions, and it has been our  
> experience that neither spacecraft operators nor deep space mission  
> scientists have much interest in errored data.  A small number of  
> undetected flipped bits in a set of engineering telemetry records  
> or a multispectral image could induce people to make some expensive  
> mistakes.  Moreover, in many cases the data from spacecraft are  
> compressed to optimize bandwidth utilization, and bit errors in  
> compressed data records tend to make recovery of the original  
> uncompressed data difficult.
>
> So you are quite correct in saying that LTP not as capable as, say,  
> Saratoga as a means of streaming "Everybody Loves Raymond" in high  
> definition from low Earth orbit.  It’s also not as capable as  
> ibuprofen as a means of relieving headaches.  Neither fact is  
> relevant.
>
> Summing up, I think you’ll have a stronger paper if you simply  
> remove LTP from it altogether and stick to a survey of protocols  
> that deliver errored content.  Section VI of the paper seems like  
> an excellent discussion of how to engineer an optimum stack along  
> these lines.
>
> One last thought: I think your proposal to add a checksum block as  
> a Bundle Protocol extension is excellent, for just the reasons you  
> discuss in sections I and II.  I haven’t had time to read your  
> draft yet, but I think the concept has a lot of merit.
>
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 18 Jul 2007 08:42:39 -0400
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper  comparingprotocols for reliability errored delivery.
Reply-To: [email-masked]
Sender: [email-masked]

On Wed, Jul 18, 2007 at 12:48:39AM -0700, Scott Burleigh wrote:
> 
> One last thought: I think your proposal to add a checksum block as a Bundle 
> Protocol extension is excellent, for just the reasons you discuss in 
> sections I and II.  I haven?t had time to read your draft yet, but I think 
> the concept has a lot of merit.

Good!  One important facet of our current proposal is that it only
provides coverage of bundle payloads, not other blocks within bundles.
This means a correct payload can still, in theory, be delivered to an
incorrect destination if a bit-flip hits the destination EID offsets
or dictionary bytes (among other odd situations like when a bit-flip
hits the custodian EID, block type, etc).

So, in the longer-term, if/when we try and put Bundle Protocol on the
standards track, an initial item of business should be to consider
putting a CRC into the canonical block format (perhaps as an optional
field whose presence is signalled in the block flags), and making sure
BAs update it if they modify a block or dictionary in-transit.  I don't
think this is needed for Experimental, because in the experiments
everyone is doing, the EIDs being intelligible ASCII strings means the
odds of a bit-flip causing mis-delivery are pretty low, as it's more
likely to flip to a non-existant host or something.  If people start
using HITs or some other binary EID format, the danger grows.

Just to reiterate: we see this as a future work item; NOT something
to be dealt with in the current spec that we want to see published
as Experimental pronto! :)

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Wed, 18 Jul 2007 00:48:39 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Sender: [email-masked]

Lloyd Wood wrote:
> We have written up a paper examining reliability in protocols, and
> comparing four different transport protocols that offer delivery of
> errored data to applications. The insights gained in this work allow
> us to identify areas of the Licklider and bundle protocols where
> reliability suffers and more design work is needed. This paper
> fleshes out the ideas I expressed at the Dublin meet.
> 
> http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage-submitted.pdf
>  Checksum Coverage and Delivery of Errored Content Lloyd Wood, Wesley
> M. Eddy, Jim McKim and Will Ivancic

Lloyd, thanks for posting this.  I very much enjoyed the paper’s thorough explication of checksum coverage and your survey of the ways in which that protection is provided in widely used communication protocols.  The very interesting and concisely introduced concept of errored content was new to me, as it’s a communication service that I can’t recall any deep space science mission ever asking for.

Something odd happens on page 7, when you start talking about LTP.  The appropriately dispassionate technical tone of the paper up to that point gives way to some surprisingly loaded language: LTP "claims" to permit carriage of reliable and partially reliable payloads, "one would hope" that its frames are checksummed, LTP "unlike many of the protocols described here, is clearly not robust or error-rejecting".  The "Also of interest" paragraph on page 8 is especially puzzling, as it’s a discussion of the relative length and complexity of the LTP and Saratoga specifications, far removed from the subject of the paper.   A suspicious mind might speculate that this otherwise meticulously researched and scrupulously objective paper is merely a pretext for initiating a little hatchet job on LTP, for reasons that pass understanding.

But this is of no consequence, as I think you probably need to remove all mention of LTP from the paper anyway.  It is completely orthogonal to your subject.  LTP is not, as you state, a transport-layer protocol that permits delivery of errored payloads.  There is nothing in the design of LTP that contemplates the delivery of data in which even a single bit is flipped, ever.  Note that the last paragraph of section 5 of the LTP specification says "The underlying data-link layer is required to never deliver incompletely received LTP segments to LTP.  In the absence of the use of LTP authentication [LTPEXT], LTP also requires the underlying data-link layer to perform data integrity checking of the segments received.  Specifically, the data-link layer is expected to detect any corrupted segments received and to silently discard them."

That is, the premise on which all of section V.D is written is incorrect.  LTP is designed to be used directly over a variety of link protocols, exactly as you say on page 8.  It is not an end-to-end transport protocol that requires its own checksum to protect against errors in intermediate processing; the intent of the design is that each LTP segment is to occupy a single lower-layer frame (see section 4.1 of the spec), so that the checksumming in that lower-layer frame protects the integrity of the segment against errors caused by transmission noise.  A lower-layer checksum in a frame carrying an LTP segment is not just "desirable", it is explicitly mandatory.

Also, LTP’s "partial reliability" concept is carefully explained – or, if you prefer, "bounded" – in section 3.3 of the LTP Motivation draft: "LTP regards each block of data as comprising two parts: a 'red-part', whose delivery must be assured by acknowledgment and retransmission as necessary, and a 'green-part' whose delivery is attempted, but not assured."  Acknowledgment and retransmission, not checksum.  This is "reliability" in the sense of what you call "delivery" reliability in section I, the sense in which TCP is often characterized as a "reliable" protocol, not reliability in the sense of "being able to  trust" the data in received packets (which, I agree, is a valuable and interesting distinction).  It is in fact vaguely similar to the "partial reliability" extension for SCTP, which likewise identifies circumstances under which the rules on acknowledgment and retransmission of some part(s) of a data unit in transit may be set aside.  Neither has anything to do with
 varying the portion of the data unit that is covered by the checksum, as in DCCP and UDP-Lite.

Perhaps this clears up the paradox you encountered on determining that the full lower-layer checksum that is required for the protection of "red" segments prevents the use of "green" segments for delivery of errored content to the application: "green" LTP segments were never intended to be used for any such purpose, so there is no paradox.

The reason for this, again, is that LTP was not designed for the delivery of errored payloads.  It was designed for reliable transmission over deep-space RF links.  Such links are currently used only by spacecraft on scientific missions, and it has been our experience that neither spacecraft operators nor deep space mission scientists have much interest in errored data.  A small number of undetected flipped bits in a set of engineering telemetry records or a multispectral image could induce people to make some expensive mistakes.  Moreover, in many cases the data from spacecraft are compressed to optimize bandwidth utilization, and bit errors in compressed data records tend to make recovery of the original uncompressed data difficult.

So you are quite correct in saying that LTP not as capable as, say, Saratoga as a means of streaming "Everybody Loves Raymond" in high definition from low Earth orbit.  It’s also not as capable as ibuprofen as a means of relieving headaches.  Neither fact is relevant.

Summing up, I think you’ll have a stronger paper if you simply remove LTP from it altogether and stick to a survey of protocols that deliver errored content.  Section VI of the paper seems like an excellent discussion of how to engineer an optimum stack along these lines.

One last thought: I think your proposal to add a checksum block as a Bundle Protocol extension is excellent, for just the reasons you discuss in sections I and II.  I haven’t had time to read your draft yet, but I think the concept has a lot of merit.

Scott

Date: Tue, 17 Jul 2007 21:35:54 +0100
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] New bundle internet draft and paper comparing protocols for reliability errored delivery.
Sender: [email-masked]

We have written up a paper examining reliability in protocols, and comparing four different transport protocols that offer delivery of errored data to applications. The insights gained in this work allow us to identify areas of the Licklider and bundle protocols where reliability suffers and more design work is needed. This paper fleshes out the ideas I expressed at the Dublin meet.

http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-saratoga/wood-eddy-checksum-coverage-submitted.pdf
Checksum Coverage and Delivery of Errored Content
Lloyd Wood, Wesley M. Eddy, Jim McKim and Will Ivancic

Abstract -
   We examine how the overall reliability of network
   protocol stacks is affected by the use of error-detecting
   checksums and Cyclic Redundancy Checks at each protocol
   layer. How these checksums cover their frames and payloads can
   affect the reliability of the rest of the stack, particularly higher
   layers, and the resulting delivery of data. We then apply insights
   gained to a comparison of new protocols promising delivery of
   packets with payload errors, to determine how well those
   protocols achieve that goal when used in realistic stacks.

The above paper has been submitted to ACM Computer Communications Review for review by the Review.

We have also done some work to address one of the areas of weakness that we have identified in that paper, by writing an internet-draft:
http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-eddy-dtnrg-checksum/draft-eddy-dtnrg-checksum-00a.txt
The DTN Bundle Protocol Payload Checksum Block
Wesley M. Eddy and Lloyd Wood.

Abstract -
   The Delay-Tolerant-Networking Bundle Protocol includes a custody
   transfer mechanism to provide acknowledgements of receipt for
   particular bundles.  No checksum is included in the basic DTN Bundle
   Protocol, however, so it is not possible to verify that bundles have
   been either forwarded or passed through various convergence layers
   without errors having been introduced.  This document partially
   rectifies the situation by defining a Bundle Protocol extension for
   carrying payload checksums and describes how its use can be
   integrated with both custody transfer and fragmentation.

This draft is currently pre-submission, as the drafts archive is not accepting submissions until after next week's IETF meet. Once the archive reopens, we will submit -00.

Enjoy! See you in Chicago.

L.

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

Cc: dtn-interest <[email-masked]>, [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] DTN2 reference implementation release 2.4.0
Date: Tue, 17 Jul 2007 10:47:17 -0700
To: Eric Coe <[email-masked]>
Sender: [email-masked]

Strange -- I had written the updates and thought I committed them to  
the wiki, however apparently I didn't.

In any event, I've now updated the wiki so the links are correct.

-mike

On Jul 17, 2007, at 9:50 AM, Eric Coe wrote:

> Until the wiki is updated here is a direct link to the 2.4.0 code:
>
> http://www.dtnrg.org/docs/code/dtn_2.4.0.tgz
>
>
> -eric
>
>
> Michael Demmer wrote:
>> Hi all,
>> I'm pleased to announce the 2.4.0 release of the DTN2 reference  
>> implementation. The most recent excerpt from the RELEASE-NOTES is  
>> included below.
>> As always, this release is available at http://www.dtnrg.org/wiki/ 
>> Code.
>> Happy bundling!
>> -mike
>> ---
>> 2.4.0 (July 2007)
>> -----------------
>> - BBN updated the protocol implementation to conform to BP spec
>>   version 10, implementing bundle protocol version 5, converting most
>>   fixed-length fields to SDNVs and several other changes.
>> - BBN added support for external convergence layers and data stores,
>>   matching the DTN reference architecture specification, as well as
>>   support for deleting links.
>> - BBN added support for the metadata extension block and improved
>>   fragmentation handling.
>> - Added a new router implementation called DTLSR (Delay Tolerant Link
>>   State Routing) intended for environments where the inter-node
>>   relationships are fairly stable, but links may go up and down.
>> - Added support for forwarding a bundle with a wildcard  
>> destination to
>>   multiple next-hops, which can be used to implement simple or
>>   constrained flooding even with the static router.
>> - Significantly improved the DTN simulator environment including
>>   adding support for bandwidth and storage limits on nodes, a
>>   structured output format for better post-processing of simulation
>>   results, and an internal restructuring making the simulation
>>   environment match the real-world environment much more closely.
>> - Reworked the internal class used to represent bundle payloads so
>>   that the router can now support fully in-memory bundles which can
>>   safely contain binary data in all cases.
>> - Jeff Wilson did a complete rewrite of the Prophet router
>>   implementation.
>> - Changed the API to include bundle creation timestamp when receiving
>>   a bundle so that it's available to applications that may need it.
>> - Added support for neighbor discovery that uses multicast dns (aka
>>   Apple's Bonjour protocol). Reworked the internal structure of the
>>   neighbor discovery subsystem.
>> - Made optimizations to the table based routers (including the  
>> default
>>   static router) to be more efficient when links are coming up and
>>   down.
>> - Updated the dtntunnel application to support tunnelling protocols
>>   where the server side is the first to send data. Reworked command
>>   line arguments to be more intuitive (and similar to ssh tunnels).
>> - Added a dtntraceroute application that sends a single bundle,  
>> with a
>>   bunch of status report flags turned on and prints out the times
>>   embedded in the status reports that come back.
>> - Modified the build environment to enable liboasys and libdtnapi to
>>   be built as shared libraries, and thereby used via SWIG export to
>>   other programming languages.
>> - Resurrected the Cygwin build though it's not yet back to full
>>   functionality.
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Tue, 17 Jul 2007 09:50:47 -0700
From: Eric Coe <[email-masked]>
Subject: Re: [dtn-interest] DTN2 reference implementation release 2.4.0
To: Michael Demmer <[email-masked]>
Cc: dtn-interest <[email-masked]>, [email-masked]
Sender: [email-masked]

Until the wiki is updated here is a direct link to the 2.4.0 code:

http://www.dtnrg.org/docs/code/dtn_2.4.0.tgz

-eric

Michael Demmer wrote:
> Hi all,
> 
> I'm pleased to announce the 2.4.0 release of the DTN2 reference 
> implementation. The most recent excerpt from the RELEASE-NOTES is 
> included below.
> 
> As always, this release is available at http://www.dtnrg.org/wiki/Code.
> 
> Happy bundling!
> -mike
> 
> ---
> 
> 2.4.0 (July 2007)
> -----------------
> 
> - BBN updated the protocol implementation to conform to BP spec
>   version 10, implementing bundle protocol version 5, converting most
>   fixed-length fields to SDNVs and several other changes.
> 
> - BBN added support for external convergence layers and data stores,
>   matching the DTN reference architecture specification, as well as
>   support for deleting links.
> 
> - BBN added support for the metadata extension block and improved
>   fragmentation handling.
> 
> - Added a new router implementation called DTLSR (Delay Tolerant Link
>   State Routing) intended for environments where the inter-node
>   relationships are fairly stable, but links may go up and down.
> 
> - Added support for forwarding a bundle with a wildcard destination to
>   multiple next-hops, which can be used to implement simple or
>   constrained flooding even with the static router.
> 
> - Significantly improved the DTN simulator environment including
>   adding support for bandwidth and storage limits on nodes, a
>   structured output format for better post-processing of simulation
>   results, and an internal restructuring making the simulation
>   environment match the real-world environment much more closely.
> 
> - Reworked the internal class used to represent bundle payloads so
>   that the router can now support fully in-memory bundles which can
>   safely contain binary data in all cases.
> 
> - Jeff Wilson did a complete rewrite of the Prophet router
>   implementation.
> 
> - Changed the API to include bundle creation timestamp when receiving
>   a bundle so that it's available to applications that may need it.
> 
> - Added support for neighbor discovery that uses multicast dns (aka
>   Apple's Bonjour protocol). Reworked the internal structure of the
>   neighbor discovery subsystem.
> 
> - Made optimizations to the table based routers (including the default
>   static router) to be more efficient when links are coming up and
>   down.
> 
> - Updated the dtntunnel application to support tunnelling protocols
>   where the server side is the first to send data. Reworked command
>   line arguments to be more intuitive (and similar to ssh tunnels).
> 
> - Added a dtntraceroute application that sends a single bundle, with a
>   bunch of status report flags turned on and prints out the times
>   embedded in the status reports that come back.
> 
> - Modified the build environment to enable liboasys and libdtnapi to
>   be built as shared libraries, and thereby used via SWIG export to
>   other programming languages.
> 
> - Resurrected the Cygwin build though it's not yet back to full
>   functionality.
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Mon, 16 Jul 2007 14:18:19 -0700
From: Scott Burleigh <[email-masked]>
To: Sally Floyd <[email-masked]>
CC: DTN <[email-masked]>, Internet Research Steering Group <[email-masked]>, Stephen Farrell <[email-masked]>, [email-masked]
Subject: [dtn-interest] Re: IRSG review of DNTRG's LTP-Specification draft
Sender: [email-masked]

Sally Floyd wrote:
> This is an IRSG reivew of DTNRG's Licklider Transmission Protocol
> - Specification, draft-irtf-dtnrg-ltp-06.txt.  This review was
> performed based on the text in Section 5.2.2 of:
> http://www.irtf.org/chairfiles/draft-irtf-rfcs-01d.html.
>
> Overall, I believe this document is "ready to publish",
>
> The writing is clear and consistent.  It is not a fun read, but
> there might not be much to do for that.  (Most of the good stuff
> is in the introductory draft, Licklider Transmission Protocol -
> Motivation, draft-irtf-dtnrg-ltp-motivation-04.txt.)  I think the
> Specification document is sufficiently accessible to those who
> aren't subject matter experts.
>
> There seems to have been sufficient editorial and technical
> review; a number of research group members (and perhaps others)
> are listed in the acknowledgements section.
>
> There is a minimal list of citations, but I don't know off-hand of
> any citations that have been missed.  The document is strictly a
> specification document; there is nothing in the document about
> motivation, why particular design decisions were made, the TCP/IP
> vs. non-TCP/IP debate, etc.  Most of this is in the Motivation
> document, which is fine.  However, it is odd to review the Specification
> document separate from the Motivation document.  Because the
> Motivation document is listed as a Normative Reference for the
> Specification document, I assume that the Specification document
> can't become an RFC until the Motivation document makes that step
> also.
>
> A reference on the TCP/IP vs. non-TCP/IP debate for deep space
> protocols, just FYI: "J. Jackson, "The Interplanetary Internet",
> IEEE Spectrum, August 2005, URL 
> "http://www.spectrum.ieee.org/print/1700",
> with a subcaption of "NASA researchers quarrel over how to network
> outer space".  Is that quarrel now over?  Or should it be referred
> to in the Motivation document?
Sally, thanks very much for your close and thoughtful review of the 
spec.  Just in answer to this one point: on August 24 of 2005 a letter 
to the editor from Vint Cerf (JPL) and Dave Israel (Goddard Space Flight 
Center) was posted to IEEE Spectrum Online in hopes of clearing this 
up.  There is now -- and was as of almost two years ago -- agreement 
within NASA that the Delay-Tolerant Networking architecture and the 
Internet architecture are complementary, not contradictory.  To whatever 
extent a real quarrel existed, I believe it's now long past.

Scott

Date: Mon, 16 Jul 2007 19:37:40 +0300
From: =?unknown-8bit?Q?J=F6rg?= Ott <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CHANTS 2007: Call for Posters
Sender: [email-masked]

                CALL FOR POSTERS

Second Workshop on Challenged Networks (CHANTS) 2007
====================================================

Co-located with Mobicom 2007, 14 September 2007, Montreal, QC, Canada

http://chants-2007.netlab.tkk.fi/

Challenged networks are characterized by a heterogeneous mix of nodes
and widely varying network conditions. Nodes in today's challenged
networks often include mobile nodes, space-based nodes,
sensor/actuator nodes and other devices. Performance of the network
paths interconnecting such nodes can be highly varying in terms of
bandwidth, latency, disruption characteristics and security
requirements. Conventional Internet access in performance-limited
environments such as developing countries can also be regarded as
challenged networks as can be ad-hoc communication between personal
devices.

The Internet protocol architecture suffers some problems when used in
a challenged network setting. For example, when disconnection and
reconnection is common or link performance is highly variable or
extreme, one or more of the traditional Internet protocols do not work
well. In this workshop following CHANTS 2006 and WDTN 2005, we wish to
explore ongoing efforts in dealing with physical networks that operate
significantly differently from wired, connected networks and the
protocol architectures and algorithms used to deal with such
situations. Techniques for making applications tolerant to disruptions
and/or high delays are also in scope.

In addition to the workshop program consisting presentations and
demonstrations, we seek poster presentations discussing recent
(possibly early) research results.  Poster presentations with
accompanying demonstrations are encouraged.  Such demo proposals shall
present recent practical results from the area of challenged networks.
Demo proposals should include one additional page describing the
precise setup and requirements.

Poster and poster abstracts will be published on the CHANTS 2007 web
page.

Submission Format
-----------------

Poster abstracts must be at most 2 pages in size with a font size not
smaller than 10pt.

Please email the PDF version of your abstract to both co-chairs using
the subject "CHANTS poster submission":

    [email-masked]
    [email-masked]

Important Dates
---------------

Poster abstract submission:   2 August 2007 (23:59 GMT)
Notification of acceptance:  12 August 2007
Final abstract due:           1 September 2007

Reply-To: <[email-masked]>
From: "Eiko Yoneki" <[email-masked]>
To: <[email-masked]>
Date: Sat, 14 Jul 2007 20:56:43 +0100
Organization: University of Cambridge
Subject: [dtn-interest] OTM RDDS 2007: Deadline Extension
Sender: [email-masked]

[Our apologies for possible duplicates of this message]

***** PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO *****
	           July 26, 2007 

**************** CALL FOR PAPERS *************************

Second International Workshop on Reliability in Decentralized Distributed
Systems (RDDS'07) http://www.cs.rmit.edu.au/fedconf/rdds2007cfp.html

ON THE MOVE FEDERATED CONFERENCES 2007 (OTM'07)
http://www.cs.rmit.edu.au/fedconf

Vilamoura, Algarve, Portugal, Nov 25 - 30, 2007 Proceedings will be
published by Springer Verlag

*************************************************************
WORKSHOP THEME

Middleware has become a popular technology for building distributed systems
from tiny sensor networks to large scale peer-to-peer (P2P) networks.
Support such as asynchronous and multipoint communication is well suited for
constructing reactive distributed computing applications over wired and
wireless networks environments. While middleware infrastructures exhibit
attractive features from an application development perspective (e.g.,
portability, interoperability, adaptability etc.), they are often lacking in
robustness and reliability. Distributed systems become increasingly large
and complex, thereby compounding many reliability problems that necessitate
different strategies and solutions. 

For example, in the inherently distributed nature of P2P networks, the most
common solution to reliability is to take advantage of redundancy. The same
task can be initially assigned to multiple peers. In file sharing
applications, data can be replicated across many peers. In messaging
applications, messages can be simultaneously sent along multiple paths.
Redundancy may not be appropriate, however, in resource-constrained
environments such as wireless ad hoc networks where more lightweight
alternatives are needed. Some systems even rely on autonomic management
technologies inspired by nature and biological organisms to cope with the
challenges of scale, complexity, heterogeneity and unpredictability. In any
case, the system model (e.g., communication, failures) and application
requirements are key factors in the design of reliably mechanisms. 

Among different aspects of reliability issues, this workshop focuses on
reliability in decentralized distributed systems. While decentralized
architectures are gaining adoption is most application domains, there is
still some reluctance in deploying them in systems with high dependability
requirements. This has led, over the past few years, to several academic and
industrial research efforts aimed at correcting this deficiency. For the
most part, these research efforts have been independent of each other, and
have often focused on specific pieces of the dependability puzzle. Our aim,
in this Workshop, is to bring researchers and practitioners together, to
further our insights on reliable decentralized architectures and to
investigate collectively the challenges that remain. 

GOALS

The purpose of the RDDS 2007 workshop on Reliability in Distributed
Decentralized Systems is to bring together researchers from diverse
communities who are interested in building dependable reliable distributed
systems in decentralized form, to explore ways of making today's middleware
technologies more robust, and to discuss and exchange experimental or
theoretical results, novel design, work-in-progress, experience, case study,
and trend-setting ideas. We seek contributions from researchers of all
backgrounds, in particular peer-to-peer systems, messaging, ad hoc
communication, middleware and distributed systems, and autonomic management
systems.

TOPICS OF INTEREST 

- The Workshop solicits contributions on topics related to, but not limited
to, the following: 
- Reliable communication, architectures and algorithms
- Lessons learned in building/using dependable middleware: what works, what
doesn't? 
- Integrating dependable embedded and enterprise middleware systems
- Trade-offs in adding other "-ilities" (survivability, adaptability,
scalability, availability, mobility, security, real-time, etc.) to reliable
middleware infrastructures
- Integration of dependability into formal distributed object models
- Shaping/enhancing standards for reliable middleware
- Evaluating dependability for middleware applications
- Limitations of existing fault tolerance technologies in the context of
middleware applications
- Metrics, benchmarks and performance studies in evaluating reliability for
middleware applications
- Combining different dependability strategies, e.g., replication with
transactions
- Self-healing, self-protecting systems
- Autonomic system management
- Reliability measurement, modelling and evaluation
- Tools for design and evaluation of reliable systems
- Application-specific reliable system (e.g., embedded systems, Web,
databases)
- Enabling technologies for self-managing systems and networks
- Economic, biological and social models used for autonomic communications
- Timeliness and availability in support of reliability
- QoS for reliable systems 

IMPORTANT DATES 
 
	Abstract Submission Deadline		July 20, 2007 (extended)

 	Paper Submission Deadline	 	July 26, 2007 (extended)

 	Acceptance Notification	 	      September 1, 2007	   
 	Camera Ready Due	 	            September 10, 2007	   
 	Registration Due	 	            September 10, 2007	   
 	OTM Conferences	 	            November 25 - 30, 2007	 

SUBMISSION GUIDELINES 

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, clarity of expression, and relevance to
IFIP WG 2.12 & WG 12.4. All submissions must be in English, and will be
refereed by a program committee comprising members of the Working Group.
Research submissions must not exceed 10 pages following the Springer format.
Submissions should be made in PDF format. Detailed formatting instructions
can be found at:
http://www.springer.de/comp/lncs/authors.html 
The final proceedings will be published by Springer Verlag as LNCS. Failure
to commit to presentation at the conference automatically excludes a paper
from the proceedings. 
The paper submission site will be announced shortly.
Accepted workshop contributions will be published by Springer-Verlag as LNCS
(Lecture Notes in Computer Science) as a part of the workshop proceedings of
the 2007 International On The Move Federated Conferences (OTM). Registering
to the OTM conference and RDDS workshop is a prerequisite for the paper to
be published. 
Failure to commit to presentation at the conference automatically excludes a
paper from the proceedings. 

ORGANISATION COMMITTEE 

Pascal Felber
Dependable and Distributed Computing Group
Université de Neuchâtel 
Institut d'informatique
CH-2007 Neuchâtel
Switzerland
Phone: (+41) 32 728 2709
Email: [email-masked]

Eiko Yoneki
Computer Laboratory
University of Cambridge 
Cambridge, CB3 0FD
United Kingdom
Phone: (+44) 1223 763743
Email: [email-masked]

Program Committee Members

Licia Capra - University College of London, UK 
Paolo Costa - Vrije Universiteit Amsterdam, Netherlands 
Simon Courtenage - University of Westminster, UK 
Patrick Eugster - Purdue University, USA 
Ludger Fiege - Siemens Research, Germany 
Christos Gkantsidis - Microsoft Research, UK 
Michael Kounavis - Intel Research, USA 
Marco Mamei - Università di Modena, Italy 
Gero Muehl - TU Berlin, Germany 
Jonathan Munson - IBM T J Watson Research Center, USA 
Maziar Nekovee - BT Research and University College of London, UK 
Andrea Passarella - IIT-CNR, Italy 
Peter Pietzuch - Imperial College London, UK 
Matthieu Roy - LAAS-CNRS, France 
Francois Taiani - Lancaster University, UK 
Einar Vollset - Cornell University, USA  

Reply-To: <[email-masked]>
From: "Eiko Yoneki" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sat, 14 Jul 2007 20:31:34 +0100
Organization: University of Cambridge
Subject: [dtn-interest] OTM RDDS 2007: Deadline Extension
Sender: [email-masked]

[Our apologies for possible duplicates of this message]

***** PAPER SUBMISSION DEADLINE HAS BEEN EXTENDED TO *****
	           July 26, 2007 

**************** CALL FOR PAPERS *************************

Second International Workshop on Reliability in Decentralized Distributed
Systems (RDDS'07) http://www.cs.rmit.edu.au/fedconf/rdds2007cfp.html

ON THE MOVE FEDERATED CONFERENCES 2007 (OTM'07)
http://www.cs.rmit.edu.au/fedconf

Vilamoura, Algarve, Portugal, Nov 25 - 30, 2007 Proceedings will be
published by Springer Verlag

*************************************************************
WORKSHOP THEME

Middleware has become a popular technology for building distributed systems
from tiny sensor networks to large scale peer-to-peer (P2P) networks.
Support such as asynchronous and multipoint communication is well suited for
constructing reactive distributed computing applications over wired and
wireless networks environments. While middleware infrastructures exhibit
attractive features from an application development perspective (e.g.,
portability, interoperability, adaptability etc.), they are often lacking in
robustness and reliability. Distributed systems become increasingly large
and complex, thereby compounding many reliability problems that necessitate
different strategies and solutions. 

For example, in the inherently distributed nature of P2P networks, the most
common solution to reliability is to take advantage of redundancy. The same
task can be initially assigned to multiple peers. In file sharing
applications, data can be replicated across many peers. In messaging
applications, messages can be simultaneously sent along multiple paths.
Redundancy may not be appropriate, however, in resource-constrained
environments such as wireless ad hoc networks where more lightweight
alternatives are needed. Some systems even rely on autonomic management
technologies inspired by nature and biological organisms to cope with the
challenges of scale, complexity, heterogeneity and unpredictability. In any
case, the system model (e.g., communication, failures) and application
requirements are key factors in the design of reliably mechanisms. 

Among different aspects of reliability issues, this workshop focuses on
reliability in decentralized distributed systems. While decentralized
architectures are gaining adoption is most application domains, there is
still some reluctance in deploying them in systems with high dependability
requirements. This has led, over the past few years, to several academic and
industrial research efforts aimed at correcting this deficiency. For the
most part, these research efforts have been independent of each other, and
have often focused on specific pieces of the dependability puzzle. Our aim,
in this Workshop, is to bring researchers and practitioners together, to
further our insights on reliable decentralized architectures and to
investigate collectively the challenges that remain. 

GOALS

The purpose of the RDDS 2007 workshop on Reliability in Distributed
Decentralized Systems is to bring together researchers from diverse
communities who are interested in building dependable reliable distributed
systems in decentralized form, to explore ways of making today's middleware
technologies more robust, and to discuss and exchange experimental or
theoretical results, novel design, work-in-progress, experience, case study,
and trend-setting ideas. We seek contributions from researchers of all
backgrounds, in particular peer-to-peer systems, messaging, ad hoc
communication, middleware and distributed systems, and autonomic management
systems.

TOPICS OF INTEREST 

- The Workshop solicits contributions on topics related to, but not limited
to, the following: 
- Reliable communication, architectures and algorithms
- Lessons learned in building/using dependable middleware: what works, what
doesn't? 
- Integrating dependable embedded and enterprise middleware systems
- Trade-offs in adding other "-ilities" (survivability, adaptability,
scalability, availability, mobility, security, real-time, etc.) to reliable
middleware infrastructures
- Integration of dependability into formal distributed object models
- Shaping/enhancing standards for reliable middleware
- Evaluating dependability for middleware applications
- Limitations of existing fault tolerance technologies in the context of
middleware applications
- Metrics, benchmarks and performance studies in evaluating reliability for
middleware applications
- Combining different dependability strategies, e.g., replication with
transactions
- Self-healing, self-protecting systems
- Autonomic system management
- Reliability measurement, modelling and evaluation
- Tools for design and evaluation of reliable systems
- Application-specific reliable system (e.g., embedded systems, Web,
databases)
- Enabling technologies for self-managing systems and networks
- Economic, biological and social models used for autonomic communications
- Timeliness and availability in support of reliability
- QoS for reliable systems 

IMPORTANT DATES 
 
	Abstract Submission Deadline		July 20, 2007 (extended)

 	Paper Submission Deadline	 	July 26, 2007 (extended)

 	Acceptance Notification	 	      September 1, 2007	   
 	Camera Ready Due	 	            September 10, 2007	   
 	Registration Due	 	            September 10, 2007	   
 	OTM Conferences	 	            November 25 - 30, 2007	 

SUBMISSION GUIDELINES 

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, clarity of expression, and relevance to
IFIP WG 2.12 & WG 12.4. All submissions must be in English, and will be
refereed by a program committee comprising members of the Working Group.
Research submissions must not exceed 10 pages following the Springer format.
Submissions should be made in PDF format. Detailed formatting instructions
can be found at:
http://www.springer.de/comp/lncs/authors.html 
The final proceedings will be published by Springer Verlag as LNCS. Failure
to commit to presentation at the conference automatically excludes a paper
from the proceedings. 
The paper submission site will be announced shortly.
Accepted workshop contributions will be published by Springer-Verlag as LNCS
(Lecture Notes in Computer Science) as a part of the workshop proceedings of
the 2007 International On The Move Federated Conferences (OTM). Registering
to the OTM conference and RDDS workshop is a prerequisite for the paper to
be published. 
Failure to commit to presentation at the conference automatically excludes a
paper from the proceedings. 

ORGANISATION COMMITTEE 

Pascal Felber
Dependable and Distributed Computing Group
Université de Neuchâtel 
Institut d'informatique
CH-2007 Neuchâtel
Switzerland
Phone: (+41) 32 728 2709
Email: [email-masked]

Eiko Yoneki
Computer Laboratory
University of Cambridge 
Cambridge, CB3 0FD
United Kingdom
Phone: (+44) 1223 763743
Email: [email-masked]

Program Committee Members

Licia Capra - University College of London, UK 
Paolo Costa - Vrije Universiteit Amsterdam, Netherlands 
Simon Courtenage - University of Westminster, UK 
Patrick Eugster - Purdue University, USA 
Ludger Fiege - Siemens Research, Germany 
Christos Gkantsidis - Microsoft Research, UK 
Michael Kounavis - Intel Research, USA 
Marco Mamei - Università di Modena, Italy 
Gero Muehl - TU Berlin, Germany 
Jonathan Munson - IBM T J Watson Research Center, USA 
Maziar Nekovee - BT Research and University College of London, UK 
Andrea Passarella - IIT-CNR, Italy 
Peter Pietzuch - Imperial College London, UK 
Matthieu Roy - LAAS-CNRS, France 
Francois Taiani - Lancaster University, UK 
Einar Vollset - Cornell University, USA  

From: Michael Demmer <[email-masked]>
Date: Fri, 13 Jul 2007 15:30:27 -0700
To: dtn-interest <[email-masked]>, [email-masked]
Subject: [dtn-interest] DTN2 reference implementation release 2.4.0
Sender: [email-masked]

Hi all,

I'm pleased to announce the 2.4.0 release of the DTN2 reference  
implementation. The most recent excerpt from the RELEASE-NOTES is  
included below.

As always, this release is available at http://www.dtnrg.org/wiki/Code.

Happy bundling!
-mike

---

2.4.0 (July 2007)
-----------------

- BBN updated the protocol implementation to conform to BP spec
   version 10, implementing bundle protocol version 5, converting most
   fixed-length fields to SDNVs and several other changes.

- BBN added support for external convergence layers and data stores,
   matching the DTN reference architecture specification, as well as
   support for deleting links.

- BBN added support for the metadata extension block and improved
   fragmentation handling.

- Added a new router implementation called DTLSR (Delay Tolerant Link
   State Routing) intended for environments where the inter-node
   relationships are fairly stable, but links may go up and down.

- Added support for forwarding a bundle with a wildcard destination to
   multiple next-hops, which can be used to implement simple or
   constrained flooding even with the static router.

- Significantly improved the DTN simulator environment including
   adding support for bandwidth and storage limits on nodes, a
   structured output format for better post-processing of simulation
   results, and an internal restructuring making the simulation
   environment match the real-world environment much more closely.

- Reworked the internal class used to represent bundle payloads so
   that the router can now support fully in-memory bundles which can
   safely contain binary data in all cases.

- Jeff Wilson did a complete rewrite of the Prophet router
   implementation.

- Changed the API to include bundle creation timestamp when receiving
   a bundle so that it's available to applications that may need it.

- Added support for neighbor discovery that uses multicast dns (aka
   Apple's Bonjour protocol). Reworked the internal structure of the
   neighbor discovery subsystem.

- Made optimizations to the table based routers (including the default
   static router) to be more efficient when links are coming up and
   down.

- Updated the dtntunnel application to support tunnelling protocols
   where the server side is the first to send data. Reworked command
   line arguments to be more intuitive (and similar to ssh tunnels).

- Added a dtntraceroute application that sends a single bundle, with a
   bunch of status report flags turned on and prints out the times
   embedded in the status reports that come back.

- Modified the build environment to enable liboasys and libdtnapi to
   be built as shared libraries, and thereby used via SWIG export to
   other programming languages.

- Resurrected the Cygwin build though it's not yet back to full
   functionality.

Date: Fri, 13 Jul 2007 02:49:20 -0500 (CDT)
From: Ajay Kshemkalyani <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] ICDCN 2008 Call for Papers
Sender: [email-masked]

*********************************************************************

                       CALL FOR PAPERS
9th International Conference on Distributed Computing and Networking
                        (ICDCN 2008)

                      January 5-8, 2008
              Jadavpur University, Kolkata, India
                    http://www.icdcn.org
*********************************************************************

The 9th International Conference on Distributed Computing and Networking,
ICDCN 2008, will be held at Jadavpur University, Kolkata, India, during
January  5-8, 2008. Over the years, ICDCN (formerly known as IWDC) has
become a leading  forum  for disseminating the latest research results
in distributed computing and networks. Jadavpur University
(http://www.jadavpur.edu), which hosts ICDCN 2008, is one of the premier
universities in India with faculties in Arts, Sciences, Engineering and
Technology, and is located in the  historic and glorious city of Kolkata,
where tradition and modernity blend in harmony.

SCOPE:
-----

Technical papers describing original, previously unpublished results are
solicited in all areas of theory and practice of distributed systems and
networking.  ICDCN 2008 will be organized in two tracks - Distributed
Computing and Networking.  Topics of interest include, but are not
limited to:

Distributed Computing Track:

     1. Communication and Synchronization Protocols
     2. Distributed Algorithms and Architectures, their
        Analysis and  Complexity
     3. Distributed Operating Systems, Middleware, Databases
     4. Experiments and Performance Measurements in Distributed Systems
     5. Fault-tolerance and Self-stabilization
     6. High Performance, Cluster and Grid Computing
     7. Mutiprocessor and Multicore Architectures and Algorithms
     8. Security in Distributed Systems
     9. Shared and Transactional Memory, Concurrent Programming
    10. Specification and Verification of Distributed Systems

Networking Track:

     1. Wireless Networks - Cellular, Ad hoc, Wireless LANs
     2. Sensor Networks
     3. Mobile, Pervasive and Autonomic Computing
     4. Optical, Overlay and Peer-to-Peer Networks
     5. Integration of Heterogeneous Wireless and Wireline Networks
     6. Internetworking Protocols and Internet Applications
     7. Network Reliability, Security and Privacy
     8. Resource Management and Quality of Service
     9. Performance Modeling and Evaluation
    10. Traffic Engineering, Pricing, Capacity Planning and Network 
Management

PAPER SUBMISSION:
----------------

A submission should report on original research that did not previously
appear in a journal or a conference proceedings and has not been 
concurrently
submitted to any other conference or journal.  Papers should not exceed
twelve single-spaced pages using at least 11-point font and one inch
margins on all sides on A4/Letter size pages, including references, 
figures,
tables etc. All papers must be submitted electronically through the
submissions link in the conference website.  Accepted papers will appear 
in
a printed proceedings published by Springer-Verlag in the LNCS series. 
Some
papers that are judged to have limited merit may be accepted as short 
papers,
with up to six pages in the proceedings. At the time of submission, 
authors
should indicate if they wish to have their paper considered as a short 
paper
if it is not accepted as a full paper. At least one author of each 
accepted
paper must register and attend the conference.

BEST PAPER AWARD:
----------------

Starting this year, a prize will be given to the paper that is judged by
the Program Committee to be the best on the basis of its content and
presentation. The Program Committee may decline to make the award or 
decide
to split it.

TUTORIALS AND KEYNOTE TALKS:
---------------------------

There will be a full day of tutorials on the first day of the conference.
The conference will also feature keynote talks from leading researchers
in the field. Details of the tutorials and the keynote talks will be
announced in the conference website (http://www.icdcn.org) later.

IMPORTANT DATES
----------------------------------------------------
Paper Submission Deadline:      July 25, 2007
Notification of Acceptance:     September 21, 2007
Camera-ready Paper Due:         October 12, 2007
Conference:                     January 5-8, 2008
----------------------------------------------------

STEERING COMMITTEE CHAIR:
------------------------
Sukumar Ghosh, University of Iowa, Iowa City, USA

GENERAL CHAIRS:
--------------
Marco Conti, CNR, Italy
Pradip K. Das, Jadavpur University, India
Nicola Santoro, Carleton University, Canada

PROGRAM CHAIRS:
--------------
Prasad Jayanti, Dartmouth College, USA (Distributed Computing Track)
C. Siva Ram Murthy, IIT Madras, India (Networking Track)
Mainak Chatterjee, Univ. of Central Florida, USA (Vice-Chair, Networking 
Track)

KEYNOTE CHAIR:
-------------
Sajal Das, University of Texas at Arlington, USA

TUTORIAL CHAIRS:
---------------
Sajal Das, University of Texas at Arlington, USA
Sarmistha Neogy, Jadavpur University, India

ORGANIZING CHAIR:
----------------
Atal Chaudhuri, Jadavpur University, India

PROGRAM COMMITTEE:
-----------------

Distributed Computing Track
---------------------------
Marcos Aguilera, HP Lab, USA
Lorenzo Alvisi, University of Texas at Austin, USA
Soma Chaudhuri, Iowa State University, USA
Nabanita Das, ISI, Kolkata, India
Vijay Garg, University of Texas at Austin, USA
Ratan Ghosh, IIT Kanpur, India
Sukumar Ghosh, University of Iowa, USA
Rachid Guerraoui, EPFL, Switzerland
Arobinda Gupta, IIT Kharagpur, India
Danny Hendler, Ben-Gurion University, Israel
Maurice Herlihy, Brown University, USA
Prasad Jayanti, Dartmouth College, USA
Kamal Karlapalem, IIIT Hyderabad, India
Rastislav Kralovic, Comenius University, Bratislava, Slovakia
Victor Luchangco, Sun Labs, USA
Keith Marzullo, University of California, San Diego, USA
Yoram Moses, Technion, Israel
Alessandro Panconesi, University of Rome, Italy
Sriram Pemmaraju, University of Iowa, USA
Srdjan Petrovic, Google, USA
Sergio Rajsbaum, UNAM, Mexico
R. Ramanujam, Institute of Mathematical Sciences, Chennai, India
Shrisha Rao, IIIT Bangalore, India
Kannan Srinathan, IIIT Hyderabad, India
Sam Toueg, University of Toronto, Canada
Srikantha Tirthapura, Iowa State University, USA
Krishnamurthy Vidyasankar, Memorial University of New Foundland, Canada

Networking Track
----------------
Debopam Acharya, Georgia Southern University, USA
Dharma P. Agrawal, University of Cincinnati, USA
Arzad Alam, IIT Delhi, India
Amiya Bhattacharya, New Mexico State University, USA
Saad Biaz, Auburn University, USA
Azzedine  Boukerche, University of Ottawa, Canada
Mainak Chatterjee, University of Central Florida, USA
Carla-Fabiana Chiasserini, Polytechnic of Turin, Italy
Samir R. Das,  SUNY at Stony Brook, USA
Kartik Gopalan, State University of New York at Binghamton, USA
Isabelle Guerin-Lassous, INRIA, France
Ashwin Gumaste, IIT Bombay, India
Sridhar Iyer, IIT Bombay, India
Holger Karl, University of Paderborn, Germany
Taskin Kocak, University of Bristol, UK
Rajeev Kumar, IIT Kharagpur, India
Kevin Kwiat, Air Force Research Lab, USA
Yonghe Liu, University of Texas at Arlington, USA
D. Majunath, IIT Bombay, India
B. S. Manoj, University of California, San Diego, USA
Mahesh Marina, The University of Edinburgh, UK
Ravi R. Mazumdar, University of Waterloo, Canada
Prasant Mohapatra, University of California, Davis, USA
Sukumar Nandi, IIT Guwahati, India
Asis Nasipuri, University of North Carolina, USA
Lionel Ni, Hong Kong Univ. of Science & Technology
Marius Portmann, The University of Queensland, Australia
Ramachandran Ramjee, Microsoft Research, Bangalore, India
Manivasakan R., IIT Madras, India
Romit Roy Choudhury, Duke University, USA
Rajarshi Roy, IIT Kharagpur, India
Pavan S. N., Indian Institute of Science, Bangalore, India
Vinod Sharma, Indian Institute of Science, Bangalore, India
C. Siva Ram Murthy, IIT Madras, India
Vikram Srinivasan, National University of Singapore
Pallapa Venkataram, Indian Institute of Science, Bangalore, India
******************************************************************************

Date: Tue, 10 Jul 2007 20:38:45 +0200
From: Dirk Kutscher <[email-masked]>
Organization: TZI, =?ISO-8859-1?Q?Universit=E4t_Bremen?=
To: [email-masked]
CC: Janico Greifenberg <[email-masked]>
Subject: [dtn-interest] RDTN -- a DTN bundle router implementation in Ruby
Sender: [email-masked]

Hi,

we have been working on a DTN bundle router implementation in native 
Ruby that we hope to be of interest to this community:

RDTN is a DTN bundle router implementation written in Ruby. RDTN is 
intended to become a light-weight, flexible DTN implementation that can 
be used in DTN application and protocol development. RDTN currently 
implements the following DTN convergence layers: UDP, TCP and Uni-DTN 
(FLUTE) and has been tested under Linux with ruby-1.8.5 and ruby-1.8.6 
(more platforms to follow).

RDTN is free software distributed under the GPL.

http://dev.tzi.org/retrospectiva/projects/rdtn/

Please bear in mind that RDTN is WORK IN PROGRESS. We are looking 
forward to feedback & contributions.

Cheers,

Janico & Dirk

Date: Mon, 09 Jul 2007 14:25:28 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig89633A5C5AE71DE5CDABC889
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> If Jim and Joe agree, I'm happy to operate under the assumption that th=
e
> -01 version will be fully payload / application-based then.

I think it's the right idea; I agree with the assumption.

> This seems
> like the only "big" decision that will significantly affect code, and I=

> recognize that the fully-payload approach can accomodate less-ugly
> implementation.  Even though I still think the fully-payload approach
> has worse failure modes, I don't think it's important enough to waste
> energy or stall progress debating on.  Let's move it all to a payload,
> define a special dtn:discovery (multicast?) EID and steam full-speed
> ahead on code.

Sounds good -- any complaints?
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enig89633A5C5AE71DE5CDABC889
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig89633A5C5AE71DE5CDABC889--

Date: Mon, 09 Jul 2007 08:33:50 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Stephen Farrell wrote:
> Scott Burleigh wrote:
>> Jim Wyllie wrote:
>>>>> However, to handle environments in which that information is not
>>>>> useful, how about we take bit 3 from the Autodiscovery Flags field 
>>>>> and
>>>>> use it to convey whether or not there is a capabilities bit vector?
>>>> Great idea.
>>> Well, if we expand the capabilities and then give an all-or-nothing 
>>> bit,
>>> that could be something of a waste.  I imagine no one needs all the
>>> listed capabilities and few people need none of them: the sensible 
>>> thing
>>> is to then always include it, use the pieces you need, and chalk the
>>> rest up to overhead.  I think we could probably do better as you both
>>> hinted; I'll give it a bit of thought.
>> Maybe you're right; it's not a huge amount of data in any case.  
>> Let's think about it some more.
>>
>> Meanwhile, another thought: historically, bit efficiency has mattered 
>> quite a lot in the environments I'm looking at, so I need to be able 
>> to have the EID(s) in this structure CBHE-encoded (just two SDNVs per 
>> EID, element number and service number; the scheme number in the 
>> primary header would apply to both).  So how about using one of the 
>> bits in the Autodiscovery Flags field to indicate this?
> Personally, I'd rather we spent some more time thinking about what
> we want to send before doing the bit fiddling. I'd also like whatever
> we do send to also work (perhaps differently) for terrestrial use
> cases (e.g. sensor networks, data-mule cases etc),
>
> This seems like a v. useful topic to spend time on in Chicago.
I agree.  It's important, but it's not so time-critical that we can't 
afford a bit of open discussion before we settle on a spec.  Chicago 
will be a great opportunity for that.

Scott

Date: Sat, 7 Jul 2007 15:29:22 -0400
From: Wesley Eddy <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: Jim Wyllie <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, Jul 06, 2007 at 04:04:58PM -0700, Michael Demmer wrote:
> >
> >>-    If Autodiscovery data were in the payload -- i.e., if  
> >>Autodiscovery
> >>were a DTN-application-layer protocol -- then you'd be able to use  
> >>the
> >>destination EID to control exactly where it goes.  I think this would
> >>give the Autodiscovery implementer a good deal more flexibility,  
> >>without
> >>ever requiring modification of the BP implementation.
> >
> >Unless I'm missing something or misread your statement, we could do  
> >this
> >having it both as a block or as data in the payload: in either  
> >case, we
> >would likely refer to a dictionary entry for 3rd-party authentication.

If Jim and Joe agree, I'm happy to operate under the assumption that the
-01 version will be fully payload / application-based then.  This seems
like the only "big" decision that will significantly affect code, and I
recognize that the fully-payload approach can accomodate less-ugly
implementation.  Even though I still think the fully-payload approach
has worse failure modes, I don't think it's important enough to waste
energy or stall progress debating on.  Let's move it all to a payload,
define a special dtn:discovery (multicast?) EID and steam full-speed
ahead on code.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Sat, 7 Jul 2007 15:19:02 -0400
From: Wesley Eddy <[email-masked]>
To: Jim Wyllie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Reply-To: [email-masked]
Sender: [email-masked]

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 07, 2007 at 12:30:13AM -0400, Jim Wyllie wrote:
> >> However, to handle environments in which that information is not
> >> useful, how about we take bit 3 from the Autodiscovery Flags field and
> >> use it to convey whether or not there is a capabilities bit vector?
> > Great idea.
>=20
> Well, if we expand the capabilities and then give an all-or-nothing bit,
> that could be something of a waste.  I imagine no one needs all the
> listed capabilities and few people need none of them: the sensible thing
> is to then always include it, use the pieces you need, and chalk the
> rest up to overhead.  I think we could probably do better as you both
> hinted; I'll give it a bit of thought.

Here's an idea that might be either good or terrible; we can split the
single capabilities SNDV into multiple SDNVs of similar information,
and have Flags bits indicate whether each of them is or is not present.
For instance, there could be separate SDNVs for:

Supported EID Schemes
Supported Security Mechanisms
Forwarding Capabilities
Supported Convergence Layers
Miscellaneous Capabilities (max parseable SDNV sizes, etc.)

I guess in some cases this could reduce overhead, whereas in others it
would increase it.  If there are going to be a lot of capabilities that
nodes need to advertise, then it seems prudent to wrestle them into
some kind of taxonomy like this.

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature
Content-Disposition: inline

--zYM0uCDKw75PZbzx--

Date: Sat, 07 Jul 2007 19:42:05 +0100
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Scott Burleigh wrote:
> Jim Wyllie wrote:
>>>> However, to handle environments in which that information is not
>>>> useful, how about we take bit 3 from the Autodiscovery Flags field and
>>>> use it to convey whether or not there is a capabilities bit vector?
>>> Great idea.
>>
>> Well, if we expand the capabilities and then give an all-or-nothing bit,
>> that could be something of a waste.  I imagine no one needs all the
>> listed capabilities and few people need none of them: the sensible thing
>> is to then always include it, use the pieces you need, and chalk the
>> rest up to overhead.  I think we could probably do better as you both
>> hinted; I'll give it a bit of thought.
> 
> Maybe you're right; it's not a huge amount of data in any case.  Let's 
> think about it some more.
> 
> Meanwhile, another thought: historically, bit efficiency has mattered 
> quite a lot in the environments I'm looking at, so I need to be able to 
> have the EID(s) in this structure CBHE-encoded (just two SDNVs per EID, 
> element number and service number; the scheme number in the primary 
> header would apply to both).  So how about using one of the bits in the 
> Autodiscovery Flags field to indicate this?

Personally, I'd rather we spent some more time thinking about what
we want to send before doing the bit fiddling. I'd also like whatever
we do send to also work (perhaps differently) for terrestrial use
cases (e.g. sensor networks, data-mule cases etc),

This seems like a v. useful topic to spend time on in Chicago.

S.

Date: Sat, 07 Jul 2007 10:57:11 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Jim Wyllie wrote:
>>> However, to handle environments in which that information is not
>>> useful, how about we take bit 3 from the Autodiscovery Flags field and
>>> use it to convey whether or not there is a capabilities bit vector?
>> Great idea.
> 
> Well, if we expand the capabilities and then give an all-or-nothing bit,
> that could be something of a waste.  I imagine no one needs all the
> listed capabilities and few people need none of them: the sensible thing
> is to then always include it, use the pieces you need, and chalk the
> rest up to overhead.  I think we could probably do better as you both
> hinted; I'll give it a bit of thought.

Maybe you're right; it's not a huge amount of data in any case.  Let's think about it some more.

Meanwhile, another thought: historically, bit efficiency has mattered quite a lot in the environments I'm looking at, so I need to be able to have the EID(s) in this structure CBHE-encoded (just two SDNVs per EID, element number and service number; the scheme number in the primary header would apply to both).  So how about using one of the bits in the Autodiscovery Flags field to indicate this?

Scott

Date: Sat, 07 Jul 2007 00:30:13 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFCA3F51FFB7029F1780ABE22
Content-Type: text/plain; charset=windows-1250
Content-Transfer-Encoding: quoted-printable

>> However, to handle environments in which that information is not
>> useful, how about we take bit 3 from the Autodiscovery Flags field and=

>> use it to convey whether or not there is a capabilities bit vector?
> Great idea.

Well, if we expand the capabilities and then give an all-or-nothing bit,
that could be something of a waste.  I imagine no one needs all the
listed capabilities and few people need none of them: the sensible thing
is to then always include it, use the pieces you need, and chalk the
rest up to overhead.  I think we could probably do better as you both
hinted; I'll give it a bit of thought.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enigFCA3F51FFB7029F1780ABE22
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigFCA3F51FFB7029F1780ABE22--

Date: Fri, 06 Jul 2007 23:58:15 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF508E0CDAAC356C7C07A687E
Content-Type: text/plain; charset=windows-1250
Content-Transfer-Encoding: quoted-printable

> Exactly.  Everything is simplified if the autodiscovery data is in
> payload in the first place.  If the autodiscovery implementation is
> external to the bundle agent, great; no need for a new API.  If it's
> internal to the bundle agent, i.e., built into the administrative
> endpoint, fine, it's easily accessible there too.

I think you're right, it does seem that many things are simplified by
just putting this in the payload.  I'd rather do away with the API if
possible: it always seemed somewhat awkward and this seems like a good
plan on how to do it.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enigF508E0CDAAC356C7C07A687E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF508E0CDAAC356C7C07A687E--

Date: Fri, 06 Jul 2007 17:05:03 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Michael Demmer wrote:
>>> In fact, from my point of view the Capabilities
>>> flags field is also domain-specific data: there's nothing in there that
>>> would be useful for the JPL implementation of BP.
>> We were thinking that there were some capabilities that would be useful
>> to a large number of DTN nodes and therefore were looking for a standard
>> way to supply those capabilities without reinventing the wheel.  I'm
>> still not convinced that this is a bad idea, though we may have swung
>> and missed on the capabilities presented rather than the actual presence
>> of such a field in the domain-independent part.
>>
>> If we can't come up with a set of "generic" capabilities, then it would
>> make sense to punt the area altogether to domain-specific payload... but
>> it might not hurt to give it a whack.  Any idea what fields you would 
>> use?
> I like the idea of exchanging a generic set of capabilities. The list 
> that you included seems like a good starting point, and I would expand 
> the set eventually to include other extension blocks such as custodial 
> multicast or other features that have been discussed.
>
> However, to handle environments in which that information is not 
> useful, how about we take bit 3 from the Autodiscovery Flags field and 
> use it to convey whether or not there is a capabilities bit vector?
Great idea.

Scott

Date: Fri, 06 Jul 2007 17:02:48 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------020308060504020602060704
Content-Type: text/plain; charset=windows-1250; format=flowed
Content-Transfer-Encoding: 7bit

Jim Wyllie wrote:
>> 2.   I don't yet understand why it's advantageous to put the
>> Autodiscovery information in a new BP block rather than simply carry it
>> all in the payloads of standard bundles.  I know that you make the point
>> in the first paragraph of section 3 that Autodiscovery is not itself a
>> DTN application, but why not?  In the same way that OSPF is an IP
>> "application"?  That design choice would have several advantages that I
>> can think of:
>>
>> -   BP blocks are not exposed to applications.  This means that if
>> Autodiscovery is in a BP block then either the BP implementation itself
>> has to be modified in order to handle Autodiscovery data or else (as you
>> say in 3.1) you have to do something special with the API (which is
>> undefined in the DTN architecture) to get the Autodiscovery data out to
>> where an application can work on it.  Seems to me it would be way
>> simpler just to have the Autodiscovery data structure in the payload
>> from the beginning so that it can immediately be delivered to whatever
>> application needs to work on it, whether that's the administrative
>> endpoint of the BA or some other application altogether.
>>     
> I was envisioning it more from your first perspective: it seems that
> most DTN implementations prefer to roll lots of functionality into one
> place and therefore wouldn't be much of an issue.  Likewise, that's how
> we had planned to implement.
>   
I think it would be good if the protocol design weren't biased toward 
any particular implementation approach, though.  Personally, I like 
designs that are extensible collections of components.  I think that's 
also the direction that the new plug-in DTN API is moving toward.
>> -    If Autodiscovery data were in the payload -- i.e., if Autodiscovery
>> were a DTN-application-layer protocol -- then you'd be able to use the
>> destination EID to control exactly where it goes.  I think this would
>> give the Autodiscovery implementer a good deal more flexibility, without
>> ever requiring modification of the BP implementation.
>>     
> Unless I'm missing something or misread your statement, we could do this
> having it both as a block or as data in the payload: in either case, we
> would likely refer to a dictionary entry for 3rd-party authentication.
>   
My thought was that if Autodiscovery is in the payload then the 
destination endpoint for Autodiscovery data can be anything at all, so 
you can use whatever exotic endpoint ID structure you like.  If it's in 
a block, then the destination endpoint can only be an endpoint that can 
read blocks -- nominally the administrative endpoint -- unless you do 
something unusual with the API as you propose.
>> -   Autodiscovery would incur less overhead: you don't really need or
>> use the block type code, control flags, or data length in the block header.
>>     
> You do if you create a new block  :)
>   
My point.
>> And autodiscovery would still work for all EID schemes regardless of how
>> endpoint EIDs are constructed within them.  What's the downside?
>>     
> I guess that's an "ease of implementation" question.  If it's going to
> typically be implemented inside the bundling daemon itself (which isn't
> altogether a bad place to stick it, IMHO), it should probably be in a
> block.  If people want this as an application, then it should be in the
> payload.
>
> I'm not much of a fan of the API that we use to get discovery data
> to/from the bundling implementation: it involves changing the bundling
> implementation to provide an API which will likely never be used except
> by bundling autodiscovery applications.  I would think that this would
> be good only if we wanted to have the flexibility of external
> development combined with a necessity for implementing most of this as a
> block.
>   
Exactly.  Everything is simplified if the autodiscovery data is in 
payload in the first place.  If the autodiscovery implementation is 
external to the bundle agent, great; no need for a new API.  If it's 
internal to the bundle agent, i.e., built into the administrative 
endpoint, fine, it's easily accessible there too.

Scott

--------------020308060504020602060704
Content-Type: text/html; charset=windows-1250
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1250"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jim Wyllie wrote:
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">2.   I don't yet understand why it's advantageous to put the
Autodiscovery information in a new BP block rather than simply carry it
all in the payloads of standard bundles.  I know that you make the point
in the first paragraph of section 3 that Autodiscovery is not itself a
DTN application, but why not?  In the same way that OSPF is an IP
"application"?  That design choice would have several advantages that I
can think of:

-   BP blocks are not exposed to applications.  This means that if
Autodiscovery is in a BP block then either the BP implementation itself
has to be modified in order to handle Autodiscovery data or else (as you
say in 3.1) you have to do something special with the API (which is
undefined in the DTN architecture) to get the Autodiscovery data out to
where an application can work on it.  Seems to me it would be way
simpler just to have the Autodiscovery data structure in the payload
from the beginning so that it can immediately be delivered to whatever
application needs to work on it, whether that's the administrative
endpoint of the BA or some other application altogether.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I was envisioning it more from your first perspective: it seems that
most DTN implementations prefer to roll lots of functionality into one
place and therefore wouldn't be much of an issue.  Likewise, that's how
we had planned to implement.
  </pre>
</blockquote>
I think it would be good if the protocol design weren't biased toward
any particular implementation approach, though.  Personally, I like
designs that are extensible collections of components.  I think that's
also the direction that the new plug-in DTN API is moving toward.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">-    If Autodiscovery data were in the payload -- i.e., if Autodiscovery
were a DTN-application-layer protocol -- then you'd be able to use the
destination EID to control exactly where it goes.  I think this would
give the Autodiscovery implementer a good deal more flexibility, without
ever requiring modification of the BP implementation.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Unless I'm missing something or misread your statement, we could do this
having it both as a block or as data in the payload: in either case, we
would likely refer to a dictionary entry for 3rd-party authentication.
  </pre>
</blockquote>
My thought was that if Autodiscovery is in the payload then the
destination endpoint for Autodiscovery data can be anything at all, so
you can use whatever exotic endpoint ID structure you like.  If it's in
a block, then the destination endpoint can only be an endpoint that can
read blocks -- nominally the administrative endpoint -- unless you do
something unusual with the API as you propose.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">-   Autodiscovery would incur less overhead: you don't really need or
use the block type code, control flags, or data length in the block header.
    </pre>
  </blockquote>
  <pre wrap=""><!---->You do if you create a new block  :)
  </pre>
</blockquote>
My point.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">And autodiscovery would still work for all EID schemes regardless of how
endpoint EIDs are constructed within them.  What's the downside?
    </pre>
  </blockquote>
  <pre wrap=""><!---->I guess that's an "ease of implementation" question.  If it's going to
typically be implemented inside the bundling daemon itself (which isn't
altogether a bad place to stick it, IMHO), it should probably be in a
block.  If people want this as an application, then it should be in the
payload.

I'm not much of a fan of the API that we use to get discovery data
to/from the bundling implementation: it involves changing the bundling
implementation to provide an API which will likely never be used except
by bundling autodiscovery applications.  I would think that this would
be good only if we wanted to have the flexibility of external
development combined with a necessity for implementing most of this as a
block.
  </pre>
</blockquote>
Exactly.  Everything is simplified if the autodiscovery data is in
payload in the first place.  If the autodiscovery implementation is
external to the bundle agent, great; no need for a new API.  If it's
internal to the bundle agent, i.e., built into the administrative
endpoint, fine, it's easily accessible there too.<br>
<br>
Scott<br>
</body>
</html>

--------------020308060504020602060704--

Cc: [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Date: Fri, 6 Jul 2007 16:04:58 -0700
To: Jim Wyllie <[email-masked]>
Sender: [email-masked]

First off, my general impressions are that I like the draft and would  
be like to help see this functionality folded into the reference  
implementation.

I have a couple comments on the specific questions that have been  
batted around this list inline below.

>> 2.   I don't yet understand why it's advantageous to put the
>> Autodiscovery information in a new BP block rather than simply  
>> carry it
>> all in the payloads of standard bundles.  I know that you make the  
>> point
>> in the first paragraph of section 3 that Autodiscovery is not  
>> itself a
>> DTN application, but why not?  In the same way that OSPF is an IP
>> "application"?  That design choice would have several advantages  
>> that I
>> can think of:
>>
>> -   BP blocks are not exposed to applications.  This means that if
>> Autodiscovery is in a BP block then either the BP implementation  
>> itself
>> has to be modified in order to handle Autodiscovery data or else  
>> (as you
>> say in 3.1) you have to do something special with the API (which is
>> undefined in the DTN architecture) to get the Autodiscovery data  
>> out to
>> where an application can work on it.  Seems to me it would be way
>> simpler just to have the Autodiscovery data structure in the payload
>> from the beginning so that it can immediately be delivered to  
>> whatever
>> application needs to work on it, whether that's the administrative
>> endpoint of the BA or some other application altogether.
>
> I was envisioning it more from your first perspective: it seems that
> most DTN implementations prefer to roll lots of functionality into one
> place and therefore wouldn't be much of an issue.  Likewise, that's  
> how
> we had planned to implement.
>
>> -    If Autodiscovery data were in the payload -- i.e., if  
>> Autodiscovery
>> were a DTN-application-layer protocol -- then you'd be able to use  
>> the
>> destination EID to control exactly where it goes.  I think this would
>> give the Autodiscovery implementer a good deal more flexibility,  
>> without
>> ever requiring modification of the BP implementation.
>
> Unless I'm missing something or misread your statement, we could do  
> this
> having it both as a block or as data in the payload: in either  
> case, we
> would likely refer to a dictionary entry for 3rd-party authentication.

I agree with Scott here, putting the Autodiscovery information into  
the payload seems like a better design.

Whether or not it's implemented in one place or externally seems like  
an orthogonal question. As Scott pointed out, in some environments  
it's harder to implement externally if carried in a block as opposed  
to a payload, though it's true that there's nothing which mandates  
that other blocks are not delivered to applications.

Still, it just seems cleaner to define a well-known destination  
endpoint identifier in the dtn scheme (say 'dtn:discovery'

>> -   Autodiscovery would incur less overhead: you don't really need or
>> use the block type code, control flags, or data length in the  
>> block header.
>
> You do if you create a new block  :)

I'm a bit confused by what you mean here...

>> And autodiscovery would still work for all EID schemes regardless  
>> of how
>> endpoint EIDs are constructed within them.  What's the downside?
>
> I guess that's an "ease of implementation" question.  If it's going to
> typically be implemented inside the bundling daemon itself (which  
> isn't
> altogether a bad place to stick it, IMHO), it should probably be in a
> block.  If people want this as an application, then it should be in  
> the
> payload.
>
> I'm not much of a fan of the API that we use to get discovery data
> to/from the bundling implementation: it involves changing the bundling
> implementation to provide an API which will likely never be used  
> except
> by bundling autodiscovery applications.  I would think that this would
> be good only if we wanted to have the flexibility of external
> development combined with a necessity for implementing most of this  
> as a
> block.

Again, I disagree with your conclusion that putting the discovery  
data in the payload means that the implementation must be outside of  
the bundling implementation.

As far as the reference implementation goes, I would actually  
implement it as part of the DTN daemon executable by creating an  
internal registration to receive bundles sent to the discovery  
endpoint identifier.

>> 3.   I've been working on a similar sort of design for use in space
>> flight deployment of DTN, and it would be kind of nice if we could
>> converge on a single mechanism.  For my purposes, it would be  
>> necessary
>> to have two bundle agent EIDs (not just one) in the Autodiscovery  
>> block:
>> the receiver of the information (like the sender) might not be  
>> either of
>> the two bundle agents to which the information pertains.
>
> I don't see any good reason to omit this, and I can see where it would
> provide a less hackish solution to some scenarios that we were
> contemplating (they all revolved around the same idea of "3rd party
> discovery")

I concur.

>> Also I'd need
>> something that would indicate which of these bundle agents is able to
>> send to the other during the indicated contact period, or if it's
>> bidirectional.
>
> Makes sense, this would follow from the above example.
>
> Another issue that we were contemplating while making this:
>
>> And I'd also need to know the nominal rate of
>> transmission from each pitcher to each catcher.
>>
>> Certainly in Autodiscovery terms this could all be considered
>> "domain-specific" data [which could be contained in a variable-length
>> field following the autodiscovery protocol type in the event that
>> Autodiscovery changed from being a BP block to being an independent
>> application protocol].
>
> I don't know, I think third-party discovery would be useful in most
> scenarios in which DTN is considered (even better if you make it the
> only authentication mechanism: combined with the security offered, you
> now have a trusted, managed DTN network which is desired in many
> scenarios).  We also could get some extra flag room and indicate  
> whether
> the fields are present: if people don't want them, it should be very
> minimal overhead.
>
>> In fact, from my point of view the Capabilities
>> flags field is also domain-specific data: there's nothing in there  
>> that
>> would be useful for the JPL implementation of BP.
>
> We were thinking that there were some capabilities that would be  
> useful
> to a large number of DTN nodes and therefore were looking for a  
> standard
> way to supply those capabilities without reinventing the wheel.  I'm
> still not convinced that this is a bad idea, though we may have swung
> and missed on the capabilities presented rather than the actual  
> presence
> of such a field in the domain-independent part.
>
> If we can't come up with a set of "generic" capabilities, then it  
> would
> make sense to punt the area altogether to domain-specific  
> payload... but
> it might not hurt to give it a whack.  Any idea what fields you  
> would use?

I like the idea of exchanging a generic set of capabilities. The list  
that you included seems like a good starting point, and I would  
expand the set eventually to include other extension blocks such as  
custodial multicast or other features that have been discussed.

However, to handle environments in which that information is not  
useful, how about we take bit 3 from the Autodiscovery Flags field  
and use it to convey whether or not there is a capabilities bit vector?

-mike

Date: Fri, 06 Jul 2007 15:10:09 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Ivancic, William D. (GRC-RCN0) wrote:
> 	From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Scott
> Burleigh
> 	Sent: Friday, July 06, 2007 5:09 PM
> 	To: Jim Wyllie
> 	Cc: [email-masked]
> 	Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D
> Announced
> ....
> 	I'm working on a general rate matching framework for DTN in
> space mission operations, which I think will provide a practical
> functional alternative to reactive congestion control over space links
> (which is looking less and less plausible these days).  But I don't have
> any details ready to talk about yet.
> 	
> 	Scott
> 	
> I would think that if we knew a reasonable estimate of the bandwidth and
> contact time (from discovery) then, one could do a reasonable proactive
> fragmentation.
>
> Of course getting this information is the trick.  For space links or
> systems one owns, the information may be stable - or perhaps there is a
> stability value associated with the information.  For dynamic
> environments, all bets are off.
Right, I'm looking at generally stable (if complex) environments.  The 
contact periods and associated data rates for communications between 
Mars rovers, the Odyssey orbiter, and the DSN stations are known well in 
advance, for example: all the relevant ephemerides are very well 
understood, tracking passes and relay services have been negotiated in 
detail, and the radios' data rates are fully characterized.  That's the 
information I need to base my rate matching on.

For earth orbiters I would expect this to be generally true as well, but 
maybe not.  Not a big deal in any case, I would think, as the distances 
are so short that you may well be able to use broadcast, hailing, and 
negotiation protocols instead.  That may or may not be a hard problem, 
but at least for now it's not my problem.

Scott

Date: Fri, 06 Jul 2007 17:58:51 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig23A1BE00817FF4E2861D4D2B
Content-Type: text/plain; charset=windows-1251
Content-Transfer-Encoding: quoted-printable

> 1.   I like what you've done in the Terminology section.  These kinds o=
f
> definitions will eventually prove to be really helpful.  One note: I
> suspect you got the terms "pitcher" and "catcher" not from JPL's
> implementation of Bundle Protocol but rather from our implementation of=

> Asynchronous Message Service; they're the names of the two threads
> instantiated when you run the "amshello" test program.

After further review, it looks like you're correct: I was looking at the
wrong code.  It's fixed in the CVS.

> 2.   I don't yet understand why it's advantageous to put the
> Autodiscovery information in a new BP block rather than simply carry it=

> all in the payloads of standard bundles.  I know that you make the poin=
t
> in the first paragraph of section 3 that Autodiscovery is not itself a
> DTN application, but why not?  In the same way that OSPF is an IP
> "application"?  That design choice would have several advantages that I=

> can think of:
>=20
> -   BP blocks are not exposed to applications.  This means that if
> Autodiscovery is in a BP block then either the BP implementation itself=

> has to be modified in order to handle Autodiscovery data or else (as yo=
u
> say in 3.1) you have to do something special with the API (which is
> undefined in the DTN architecture) to get the Autodiscovery data out to=

> where an application can work on it.  Seems to me it would be way
> simpler just to have the Autodiscovery data structure in the payload
> from the beginning so that it can immediately be delivered to whatever
> application needs to work on it, whether that's the administrative
> endpoint of the BA or some other application altogether.

I was envisioning it more from your first perspective: it seems that
most DTN implementations prefer to roll lots of functionality into one
place and therefore wouldn't be much of an issue.  Likewise, that's how
we had planned to implement.

> -    If Autodiscovery data were in the payload -- i.e., if Autodiscover=
y
> were a DTN-application-layer protocol -- then you'd be able to use the
> destination EID to control exactly where it goes.  I think this would
> give the Autodiscovery implementer a good deal more flexibility, withou=
t
> ever requiring modification of the BP implementation.

Unless I'm missing something or misread your statement, we could do this
having it both as a block or as data in the payload: in either case, we
would likely refer to a dictionary entry for 3rd-party authentication.

> -   Autodiscovery would incur less overhead: you don't really need or
> use the block type code, control flags, or data length in the block hea=
der.

You do if you create a new block  :)

> And autodiscovery would still work for all EID schemes regardless of ho=
w
> endpoint EIDs are constructed within them.  What's the downside?

I guess that's an "ease of implementation" question.  If it's going to
typically be implemented inside the bundling daemon itself (which isn't
altogether a bad place to stick it, IMHO), it should probably be in a
block.  If people want this as an application, then it should be in the
payload.

I'm not much of a fan of the API that we use to get discovery data
to/from the bundling implementation: it involves changing the bundling
implementation to provide an API which will likely never be used except
by bundling autodiscovery applications.  I would think that this would
be good only if we wanted to have the flexibility of external
development combined with a necessity for implementing most of this as a
block.

> 3.   I've been working on a similar sort of design for use in space
> flight deployment of DTN, and it would be kind of nice if we could
> converge on a single mechanism.  For my purposes, it would be necessary=

> to have two bundle agent EIDs (not just one) in the Autodiscovery block=
:
> the receiver of the information (like the sender) might not be either o=
f
> the two bundle agents to which the information pertains.

I don't see any good reason to omit this, and I can see where it would
provide a less hackish solution to some scenarios that we were
contemplating (they all revolved around the same idea of "3rd party
discovery")

> Also I'd need
> something that would indicate which of these bundle agents is able to
> send to the other during the indicated contact period, or if it's
> bidirectional.

Makes sense, this would follow from the above example.

Another issue that we were contemplating while making this:

> And I'd also need to know the nominal rate of
> transmission from each pitcher to each catcher.
>=20
> Certainly in Autodiscovery terms this could all be considered
> "domain-specific" data [which could be contained in a variable-length
> field following the autodiscovery protocol type in the event that
> Autodiscovery changed from being a BP block to being an independent
> application protocol].

I don't know, I think third-party discovery would be useful in most
scenarios in which DTN is considered (even better if you make it the
only authentication mechanism: combined with the security offered, you
now have a trusted, managed DTN network which is desired in many
scenarios).  We also could get some extra flag room and indicate whether
the fields are present: if people don't want them, it should be very
minimal overhead.

> In fact, from my point of view the Capabilities
> flags field is also domain-specific data: there's nothing in there that=

> would be useful for the JPL implementation of BP.

We were thinking that there were some capabilities that would be useful
to a large number of DTN nodes and therefore were looking for a standard
way to supply those capabilities without reinventing the wheel.  I'm
still not convinced that this is a bad idea, though we may have swung
and missed on the capabilities presented rather than the actual presence
of such a field in the domain-independent part.

If we can't come up with a set of "generic" capabilities, then it would
make sense to punt the area altogether to domain-specific payload... but
it might not hurt to give it a whack.  Any idea what fields you would use=
?

> 4.   In section 3.2 you discuss the handling of autodiscovery requests.=
=20
> I couldn't find anything in the draft that said what an autodiscovery
> request is, what it looks like, or where it comes from.  Did I miss it?=

It's something of a boundary-defining paragraph: it basically says what
the bundling implementation should do if it gets an API request to start
autodiscovery (by whatever mechanism the API provides to start something
like that from the external application).  If we did away with the API,
we probably do away with this part.  Likewise if we put this in the
bundle payload and do away with the separate block.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enig23A1BE00817FF4E2861D4D2B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig23A1BE00817FF4E2861D4D2B--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Date: Fri, 6 Jul 2007 16:49:38 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "Jim Wyllie" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
	Sent: Friday, July 06, 2007 5:09 PM
	To: Jim Wyllie
	Cc: [email-masked]
	Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D
Announced
....
	I'm working on a general rate matching framework for DTN in
space mission operations, which I think will provide a practical
functional alternative to reactive congestion control over space links
(which is looking less and less plausible these days).  But I don't have
any details ready to talk about yet.
	
	Scott

I would think that if we knew a reasonable estimate of the bandwidth and
contact time (from discovery) then, one could do a reasonable proactive
fragmentation.

Of course getting this information is the trick.  For space links or
systems one owns, the information may be stable - or perhaps there is a
stability value associated with the information.  For dynamic
environments, all bets are off.

Will

Date: Fri, 06 Jul 2007 14:09:11 -0700
From: Scott Burleigh <[email-masked]>
To: Jim Wyllie <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

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

Jim Wyllie wrote:
>>>> And I'd also need to know the nominal rate of 
>>>> transmission from each pitcher to each catcher.
>>>>         
>>> That's doable and similarly useful as knowing about storage limits, but
>>> has to be pretty carefully defined.  Depending on how the information is
>>> used, you may not want simple layer-2 capacity reported, and in many
>>> (most?) link types even the layer-2 capacity is highly variable (e.g.
>>> adaptive coding and modulation can bump it up/down by orders of
>>> magnitude).  So I think maybe knowing what the dynamic range is could be
>>> appropriate; like "no more than X Mbps, and definitely no less than Y
>>> kbps, if the link is up at all", but this softer information will prove
>>> somewhat less useful for making scheduling/forwarding decisions than
>>> more crunchy (but brittle) scalars.
>>>       
>> Right.  What I need, I believe, is information that comes out of mission
>> operations plans very readily: from time T1 to time T2, node X is going
>> to be transmitting to node Y at 256 Kbps.  Given this information I can
>> work out the answers to my buffer occupancy questions.  Certainly I
>> won't expect that at the end of T2 node Y will have acquired ((T2 - T1)
>> * 32768) additional bytes of bundle payload, but I figure turning these
>> raw numbers into useful information is the job of the bundle agent that
>> receives them, not the sender.
>>     
> It depends if this type of definition is to be done on a general or
> specific level, and definitely depends on the characteristics of the
> underlying network layers (TCP has slow-start and congestion as the
> obvious first-thought example of variable network bandwidth).  I don't
> think it can be done well on a general level for the reasons that Wes
> stated.
>
> I think we should try to keep it simple with regard to bandwidth.  For
> instance, a simple (and granted, brittle) scalar value might be
> meaningless to some nodes with strange transmission requirements, but
> those are the nodes for which there's no good generic way to send this
> information anyhow (likely pushing it into the "domain-specific" area if
> it's that important).  However, for other nodes, it might make sense in
> some way that is to be interpreted by the receiver.
>   
Right, that's exactly what I'm looking for.  Again, we may very well 
want to consider this sort of information to be domain-specific, as it 
is stuff that I am pretty confident I need and can use in the specific 
deployments that I care about (space flight missions) but that would be 
useless in other contexts; this is perfectly fine with me.  I think we 
are all agreed that a general mechanism along these lines would be 
difficult to develop and of doubtful utility.
> Determining this information is worth thinking about.  For instance, if
> I'm a DTN node and I get a bundle from another node with a sending rate
> higher than I can receive, what then?  Does this situation come up when
> traveling over only a single convergence layer in a way which couldn't
> mitigate this?
>   
I'm working on a general rate matching framework for DTN in space 
mission operations, which I think will provide a practical functional 
alternative to reactive congestion control over space links (which is 
looking less and less plausible these days).  But I don't have any 
details ready to talk about yet.

Scott

--------------030906030605070206050500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jim Wyllie wrote:
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <pre wrap="">And I'd also need to know the nominal rate of 
transmission from each pitcher to each catcher.
        </pre>
      </blockquote>
      <pre wrap="">That's doable and similarly useful as knowing about storage limits, but
has to be pretty carefully defined.  Depending on how the information is
used, you may not want simple layer-2 capacity reported, and in many
(most?) link types even the layer-2 capacity is highly variable (e.g.
adaptive coding and modulation can bump it up/down by orders of
magnitude).  So I think maybe knowing what the dynamic range is could be
appropriate; like "no more than X Mbps, and definitely no less than Y
kbps, if the link is up at all", but this softer information will prove
somewhat less useful for making scheduling/forwarding decisions than
more crunchy (but brittle) scalars.
      </pre>
    </blockquote>
    <pre wrap="">Right.  What I need, I believe, is information that comes out of mission
operations plans very readily: from time T1 to time T2, node X is going
to be transmitting to node Y at 256 Kbps.  Given this information I can
work out the answers to my buffer occupancy questions.  Certainly I
won't expect that at the end of T2 node Y will have acquired ((T2 - T1)
* 32768) additional bytes of bundle payload, but I figure turning these
raw numbers into useful information is the job of the bundle agent that
receives them, not the sender.
    </pre>
  </blockquote>
  <pre wrap=""><!---->It depends if this type of definition is to be done on a general or
specific level, and definitely depends on the characteristics of the
underlying network layers (TCP has slow-start and congestion as the
obvious first-thought example of variable network bandwidth).  I don't
think it can be done well on a general level for the reasons that Wes
stated.

I think we should try to keep it simple with regard to bandwidth.  For
instance, a simple (and granted, brittle) scalar value might be
meaningless to some nodes with strange transmission requirements, but
those are the nodes for which there's no good generic way to send this
information anyhow (likely pushing it into the "domain-specific" area if
it's that important).  However, for other nodes, it might make sense in
some way that is to be interpreted by the receiver.
  </pre>
</blockquote>
Right, that's exactly what I'm looking for.&nbsp; Again, we may very well
want to consider this sort of information to be domain-specific, as it
is stuff that I am pretty confident I need and can use in the specific
deployments that I care about (space flight missions) but that would be
useless in other contexts; this is perfectly fine with me.&nbsp; I think we
are all agreed that a general mechanism along these lines would be
difficult to develop and of doubtful utility.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Determining this information is worth thinking about.  For instance, if
I'm a DTN node and I get a bundle from another node with a sending rate
higher than I can receive, what then?  Does this situation come up when
traveling over only a single convergence layer in a way which couldn't
mitigate this?
  </pre>
</blockquote>
I'm working on a general rate matching framework for DTN in space
mission operations, which I think will provide a practical functional
alternative to reactive congestion control over space links (which is
looking less and less plausible these days).&nbsp; But I don't have any
details ready to talk about yet.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------030906030605070206050500--

Date: Fri, 06 Jul 2007 16:09:49 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig660EE909A7425CFF16804636
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>> This part of the design might be worth reconsidering.  Personally, I h=
ad
>> thought that a new block type would be desirable because the alternati=
ve
>> seemed to be defining, per-EID scheme, an autodiscovery address to sen=
d
>> towards and hoping the catcher understood the chosen EID scheme that a=

>> pitcher sent contact advertisements to.  The solution space might be
>> broader, though; I didn't quite grasp the details of addressing from t=
he
>> alternative sketch in your previous message, so I'm not (quite yet)
>> convinced that it's really viable in a diverse environment.
>>  =20
> It's a reasonable concern, but I would think that you could always
> default to the administrative endpoint ID for each bundle agent, which
> has to be well known in order for custody transfer to work.  (I probabl=
y
> wouldn't actually do it that way, though, as in practice I don't think
> the range of schemes is going to be so broad as to make this an issue.)=

I agree with Scott on this one...  I doubt you'll have so many schemes
that this would be a major advantage, or at least cases where two nodes
are willing (from a security / permissions / connection standpoint) to
forward bundles but can't due to a lack of EID scheme understanding.

More on this issue in an email to come soon.

>>> And I'd also need to know the nominal rate of=20
>>> transmission from each pitcher to each catcher.
>>>    =20
>> That's doable and similarly useful as knowing about storage limits, bu=
t
>> has to be pretty carefully defined.  Depending on how the information =
is
>> used, you may not want simple layer-2 capacity reported, and in many
>> (most?) link types even the layer-2 capacity is highly variable (e.g.
>> adaptive coding and modulation can bump it up/down by orders of
>> magnitude).  So I think maybe knowing what the dynamic range is could =
be
>> appropriate; like "no more than X Mbps, and definitely no less than Y
>> kbps, if the link is up at all", but this softer information will prov=
e
>> somewhat less useful for making scheduling/forwarding decisions than
>> more crunchy (but brittle) scalars.
>>  =20
> Right.  What I need, I believe, is information that comes out of missio=
n
> operations plans very readily: from time T1 to time T2, node X is going=

> to be transmitting to node Y at 256 Kbps.  Given this information I can=

> work out the answers to my buffer occupancy questions.  Certainly I
> won't expect that at the end of T2 node Y will have acquired ((T2 - T1)=

> * 32768) additional bytes of bundle payload, but I figure turning these=

> raw numbers into useful information is the job of the bundle agent that=

> receives them, not the sender.

It depends if this type of definition is to be done on a general or
specific level, and definitely depends on the characteristics of the
underlying network layers (TCP has slow-start and congestion as the
obvious first-thought example of variable network bandwidth).  I don't
think it can be done well on a general level for the reasons that Wes
stated.

I think we should try to keep it simple with regard to bandwidth.  For
instance, a simple (and granted, brittle) scalar value might be
meaningless to some nodes with strange transmission requirements, but
those are the nodes for which there's no good generic way to send this
information anyhow (likely pushing it into the "domain-specific" area if
it's that important).  However, for other nodes, it might make sense in
some way that is to be interpreted by the receiver.

Determining this information is worth thinking about.  For instance, if
I'm a DTN node and I get a bundle from another node with a sending rate
higher than I can receive, what then?  Does this situation come up when
traveling over only a single convergence layer in a way which couldn't
mitigate this?
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enig660EE909A7425CFF16804636
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig660EE909A7425CFF16804636--

Date: Fri, 06 Jul 2007 10:32:14 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] bundle-spec-10...
Sender: [email-masked]

...has just been published [1]. It conatains two minor process
related tweaks to keep the IRSG happy & should soon be
sent to the IESG (they do a quick review to ensure it isn't
conflicting with current standards track work) and then
the RFC editor.

Regards,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-10.txt

Date: Thu, 05 Jul 2007 12:47:12 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

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

Wesley Eddy wrote:
> Jim can answer some of the finer points, but I'll just express a couple
> quick comments:
>
> On Thu, Jul 05, 2007 at 10:44:53AM -0700, Scott Burleigh wrote:
>   
>> 2.   I don't yet understand why it's advantageous to put the 
>> Autodiscovery information in a new BP block rather than simply carry it 
>> all in the payloads of standard bundles.  I know that you make the point 
>> in the first paragraph of section 3 that Autodiscovery is not itself a 
>> DTN application, but why not?  In the same way that OSPF is an IP 
>> "application"?  That design choice would have several advantages that I 
>> can think of:
>>     
> This part of the design might be worth reconsidering.  Personally, I had
> thought that a new block type would be desirable because the alternative
> seemed to be defining, per-EID scheme, an autodiscovery address to send
> towards and hoping the catcher understood the chosen EID scheme that a
> pitcher sent contact advertisements to.  The solution space might be
> broader, though; I didn't quite grasp the details of addressing from the
> alternative sketch in your previous message, so I'm not (quite yet)
> convinced that it's really viable in a diverse environment.
>   
It's a reasonable concern, but I would think that you could always 
default to the administrative endpoint ID for each bundle agent, which 
has to be well known in order for custody transfer to work.  (I probably 
wouldn't actually do it that way, though, as in practice I don't think 
the range of schemes is going to be so broad as to make this an issue.)
> There are also some semantic hooks that can be built into a new block
> type to restrict forwarding behaviors and etc, which are possibly more
> difficult with a strictly application approach.
>   
Can you expand a little on this?  My intuition is that using a new block 
type would be more, rather than less, constraining.
>> And I'd also need to know the nominal rate of 
>> transmission from each pitcher to each catcher.
>>     
> That's doable and similarly useful as knowing about storage limits, but
> has to be pretty carefully defined.  Depending on how the information is
> used, you may not want simple layer-2 capacity reported, and in many
> (most?) link types even the layer-2 capacity is highly variable (e.g.
> adaptive coding and modulation can bump it up/down by orders of
> magnitude).  So I think maybe knowing what the dynamic range is could be
> appropriate; like "no more than X Mbps, and definitely no less than Y
> kbps, if the link is up at all", but this softer information will prove
> somewhat less useful for making scheduling/forwarding decisions than
> more crunchy (but brittle) scalars.
>   
Right.  What I need, I believe, is information that comes out of mission 
operations plans very readily: from time T1 to time T2, node X is going 
to be transmitting to node Y at 256 Kbps.  Given this information I can 
work out the answers to my buffer occupancy questions.  Certainly I 
won't expect that at the end of T2 node Y will have acquired ((T2 - T1) 
* 32768) additional bytes of bundle payload, but I figure turning these 
raw numbers into useful information is the job of the bundle agent that 
receives them, not the sender.

Scott

--------------030408090302010707060106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Wesley Eddy wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">Jim can answer some of the finer points, but I'll just express a couple
quick comments:

On Thu, Jul 05, 2007 at 10:44:53AM -0700, Scott Burleigh wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">2.   I don't yet understand why it's advantageous to put the 
Autodiscovery information in a new BP block rather than simply carry it 
all in the payloads of standard bundles.  I know that you make the point 
in the first paragraph of section 3 that Autodiscovery is not itself a 
DTN application, but why not?  In the same way that OSPF is an IP 
"application"?  That design choice would have several advantages that I 
can think of:
    </pre>
  </blockquote>
  <pre wrap=""><!---->This part of the design might be worth reconsidering.  Personally, I had
thought that a new block type would be desirable because the alternative
seemed to be defining, per-EID scheme, an autodiscovery address to send
towards and hoping the catcher understood the chosen EID scheme that a
pitcher sent contact advertisements to.  The solution space might be
broader, though; I didn't quite grasp the details of addressing from the
alternative sketch in your previous message, so I'm not (quite yet)
convinced that it's really viable in a diverse environment.
  </pre>
</blockquote>
It's a reasonable concern, but I would think that you could always
default to the administrative endpoint ID for each bundle agent, which
has to be well known in order for custody transfer to work.&nbsp; (I
probably wouldn't actually do it that way, though, as in practice I
don't think the range of schemes is going to be so broad as to make
this an issue.)<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">There are also some semantic hooks that can be built into a new block
type to restrict forwarding behaviors and etc, which are possibly more
difficult with a strictly application approach.
  </pre>
</blockquote>
Can you expand a little on this?&nbsp; My intuition is that using a new
block type would be more, rather than less, constraining.<br>
<blockquote cite="[email-masked]" type="cite">
  <blockquote type="cite">
    <pre wrap="">And I'd also need to know the nominal rate of 
transmission from each pitcher to each catcher.
    </pre>
  </blockquote>
  <pre wrap=""><!---->That's doable and similarly useful as knowing about storage limits, but
has to be pretty carefully defined.  Depending on how the information is
used, you may not want simple layer-2 capacity reported, and in many
(most?) link types even the layer-2 capacity is highly variable (e.g.
adaptive coding and modulation can bump it up/down by orders of
magnitude).  So I think maybe knowing what the dynamic range is could be
appropriate; like "no more than X Mbps, and definitely no less than Y
kbps, if the link is up at all", but this softer information will prove
somewhat less useful for making scheduling/forwarding decisions than
more crunchy (but brittle) scalars.
  </pre>
</blockquote>
Right.&nbsp; What I need, I believe, is information that comes out of
mission operations plans very readily: from time T1 to time T2, node X
is going to be transmitting to node Y at 256 Kbps.&nbsp; Given this
information I can work out the answers to my buffer occupancy
questions.&nbsp; Certainly I won't expect that at the end of T2 node Y will
have acquired ((T2 - T1) * 32768) additional bytes of bundle payload,
but I figure turning these raw numbers into useful information is the
job of the bundle agent that receives them, not the sender.<br>
<br>
Scott<br>
<br>
</body>
</html>

--------------030408090302010707060106--

Date: Thu, 5 Jul 2007 14:34:45 -0400
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Reply-To: [email-masked]
Sender: [email-masked]

Jim can answer some of the finer points, but I'll just express a couple
quick comments:

On Thu, Jul 05, 2007 at 10:44:53AM -0700, Scott Burleigh wrote:
> 
> 2.   I don't yet understand why it's advantageous to put the 
> Autodiscovery information in a new BP block rather than simply carry it 
> all in the payloads of standard bundles.  I know that you make the point 
> in the first paragraph of section 3 that Autodiscovery is not itself a 
> DTN application, but why not?  In the same way that OSPF is an IP 
> "application"?  That design choice would have several advantages that I 
> can think of:

This part of the design might be worth reconsidering.  Personally, I had
thought that a new block type would be desirable because the alternative
seemed to be defining, per-EID scheme, an autodiscovery address to send
towards and hoping the catcher understood the chosen EID scheme that a
pitcher sent contact advertisements to.  The solution space might be
broader, though; I didn't quite grasp the details of addressing from the
alternative sketch in your previous message, so I'm not (quite yet)
convinced that it's really viable in a diverse environment.

There are also some semantic hooks that can be built into a new block
type to restrict forwarding behaviors and etc, which are possibly more
difficult with a strictly application approach.

> And I'd also need to know the nominal rate of 
> transmission from each pitcher to each catcher.

That's doable and similarly useful as knowing about storage limits, but
has to be pretty carefully defined.  Depending on how the information is
used, you may not want simple layer-2 capacity reported, and in many
(most?) link types even the layer-2 capacity is highly variable (e.g.
adaptive coding and modulation can bump it up/down by orders of
magnitude).  So I think maybe knowing what the dynamic range is could be
appropriate; like "no more than X Mbps, and definitely no less than Y
kbps, if the link is up at all", but this softer information will prove
somewhat less useful for making scheduling/forwarding decisions than
more crunchy (but brittle) scalars.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Thu, 05 Jul 2007 10:44:53 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

Jim Wyllie wrote:
> DTN folk:
>
> I'm working on a protocol for DTN Autodiscovery of neighboring
> bundling-enabled nodes with Wes Eddy and Joe Ishac, and we just finished
> / published the -00 Internet Draft.  If you're interested, you can find
> it here:
>
> http://www.ietf.org/internet-drafts/draft-wyllie-dtnrg-badisc-00.txt
>
> Any and all feedback is encouraged and welcome.
>
> I will also be in Chicago if anyone wants to talk about it.
>   
Jim, I'm glad to see some work being done on this kind of thing.  I 
haven't had time to go through your spec in real detail, but on a quick 
reading I've got these comments and questions:

1.   I like what you've done in the Terminology section.  These kinds of 
definitions will eventually prove to be really helpful.  One note: I 
suspect you got the terms "pitcher" and "catcher" not from JPL's 
implementation of Bundle Protocol but rather from our implementation of 
Asynchronous Message Service; they're the names of the two threads 
instantiated when you run the "amshello" test program.

2.   I don't yet understand why it's advantageous to put the 
Autodiscovery information in a new BP block rather than simply carry it 
all in the payloads of standard bundles.  I know that you make the point 
in the first paragraph of section 3 that Autodiscovery is not itself a 
DTN application, but why not?  In the same way that OSPF is an IP 
"application"?  That design choice would have several advantages that I 
can think of:

-   BP blocks are not exposed to applications.  This means that if 
Autodiscovery is in a BP block then either the BP implementation itself 
has to be modified in order to handle Autodiscovery data or else (as you 
say in 3.1) you have to do something special with the API (which is 
undefined in the DTN architecture) to get the Autodiscovery data out to 
where an application can work on it.  Seems to me it would be way 
simpler just to have the Autodiscovery data structure in the payload 
from the beginning so that it can immediately be delivered to whatever 
application needs to work on it, whether that's the administrative 
endpoint of the BA or some other application altogether.

-    If Autodiscovery data were in the payload -- i.e., if Autodiscovery 
were a DTN-application-layer protocol -- then you'd be able to use the 
destination EID to control exactly where it goes.  I think this would 
give the Autodiscovery implementer a good deal more flexibility, without 
ever requiring modification of the BP implementation.

-   Autodiscovery would incur less overhead: you don't really need or 
use the block type code, control flags, or data length in the block header.

And autodiscovery would still work for all EID schemes regardless of how 
endpoint EIDs are constructed within them.  What's the downside?

3.   I've been working on a similar sort of design for use in space 
flight deployment of DTN, and it would be kind of nice if we could 
converge on a single mechanism.  For my purposes, it would be necessary 
to have two bundle agent EIDs (not just one) in the Autodiscovery block: 
the receiver of the information (like the sender) might not be either of 
the two bundle agents to which the information pertains.  Also I'd need 
something that would indicate which of these bundle agents is able to 
send to the other during the indicated contact period, or if it's 
bidirectional.  And I'd also need to know the nominal rate of 
transmission from each pitcher to each catcher.

Certainly in Autodiscovery terms this could all be considered 
"domain-specific" data [which could be contained in a variable-length 
field following the autodiscovery protocol type in the event that 
Autodiscovery changed from being a BP block to being an independent 
application protocol].  In fact, from my point of view the Capabilities 
flags field is also domain-specific data: there's nothing in there that 
would be useful for the JPL implementation of BP.

4.   In section 3.2 you discuss the handling of autodiscovery requests.  
I couldn't find anything in the draft that said what an autodiscovery 
request is, what it looks like, or where it comes from.  Did I miss it?

Scott

Date: Thu, 05 Jul 2007 10:47:11 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: DTN interest Group <[email-masked]>, CETS List <[email-masked]>
Subject: Re: [dtn-interest] Finite state machine for Bundling and LTP
Sender: [email-masked]

Hi Jayram,

Jayram Deshpande wrote:
> Hi,
> 
>  The Bundling draft [1] explains all the different control 
>  messages that need to be exchanged and the conditions under 
>  which they are generated. I would like to suggest adding a 
>  formal state machine (more like a FSM diagram) to the bundling 
>  draft that would make things easier for those of us who may not 
>  be in touch with latest updates/changes.

At this point in the process of finalising these drafts, I think
that'd be couterproductive. Basically, the bundle-spec and LTP I-Ds
are both done in the DTNRG and are on the (long and winding) road to
becoming experimental track RFCs.

However, if you had the time and interest, a stand-alone draft
(or a paper, so you could use graphics) setting out those FSMs
would be interesting.

S.

Date: Wed, 4 Jul 2007 19:39:21 -0400
From: Jayram Deshpande <[email-masked]>
To: DTN interest Group <[email-masked]>, DTN users Group <[email-masked]>
Cc: CETS List <[email-masked]>
Reply-To: [email-masked]
Subject: [dtn-interest] Finite state machine for Bundling and LTP
Sender: [email-masked]

--8t9RHnE3ZwKMSgU+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

 The Bundling draft [1] explains all the different control=20
 messages that need to be exchanged and the conditions under=20
 which they are generated. I would like to suggest adding a=20
 formal state machine (more like a FSM diagram) to the bundling=20
 draft that would make things easier for those of us who may not=20
 be in touch with latest updates/changes.

 On the coding side, last time I dipped myself through the code=20
 (almost an year ago when I was working on a Java Implementation=20
 of the Bundling Protocol), the state transitions and different=20
 events handling was done with a 'switch- case' based model, we may=20
 want to use a two dimensional array of function pointers (states=20
 and events being the two dimensions) that would make code a little
 'better looking' (may be).

=20
  -Jay.

  =20

 P.S. The state machine suggestion also applies to the LTP.=20

=20

--8t9RHnE3ZwKMSgU+
Content-Type: application/pgp-signature
Content-Disposition: inline

--8t9RHnE3ZwKMSgU+--

Date: Wed, 04 Jul 2007 13:33:28 -0400
From: Jim Wyllie <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Bundling Neighbor Autodiscovery I-D Announced
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig73A5B115951F30D09720C523
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

DTN folk:

I'm working on a protocol for DTN Autodiscovery of neighboring
bundling-enabled nodes with Wes Eddy and Joe Ishac, and we just finished
/ published the -00 Internet Draft.  If you're interested, you can find
it here:

http://www.ietf.org/internet-drafts/draft-wyllie-dtnrg-badisc-00.txt

Any and all feedback is encouraged and welcome.

I will also be in Chicago if anyone wants to talk about it.
--=20
Jim Wyllie
Master's Student
IRG Lab, Dept. of EE and CS
Ohio University

--------------enig73A5B115951F30D09720C523
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig73A5B115951F30D09720C523--