Subject: Re: [dtn-interest] DTN Time Sync Issues
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Mon, 31 Mar 2008 22:26:17 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Joseph Ishac wrote:
> At the last DTNRG meeting held in Philadelphia, the research group
> expressed interest in alleviating some of the time sync issues present
> with the current DTN specifications.  The issues arises from the way
> expired bundles are identified.

Joseph, this is an interesting topic to explore, but I don't recall the research group having agreed that there were actually any such issues to alleviate.  I know that I am not yet persuaded that there is a problem.

> DTN bundles have a "creation time
> stamp" and a "lifetime", the combination of which determines the exact
> time in which the bundle is deemed stale and should be discarded by the
> bundle agent that currently holds it.  However, this approach requires
> that *all* DTN nodes processing that bundle to have their clocks
> synchronized, as any skew will impact the way bundles are processed.
> For example, a node whose time is skewed far into the future will
> needlessly drop all of the bundles it receives.  Conversely, a node
> skewed far into the past will quickly run out of resources as it
> erroneously holds bundles which should be discarded.

This is true, and rough clock synchronization (to within about a second) has long been recognized as one of the basic ground rules of the DTN architecture.

> Simply coming up with a way to synchronize clocks is a intractable task
> in some cases, and simply impossible for others.  For example, it is
> difficult to rely on clock synchronization for bundles that must
> traverse DTN nodes which you do not own.

This is not an example of the difficulty of synchronizing clocks.  It is simply an observation regarding the reality of DTN communication.  Bundles are not themselves characterized by "clock synchronization"; they have time values, which may have been obtained from clocks that were not synchronized with the network -- in the event that the originating nodes didn't comply with that basic requirement of the DTN architecture.

> Transmitting to Mars from
> Earth would require synchronization between clocks across planets, a
> problem vastly complicated by the long delays and principles in basic
> and special relativity.

Not at all.  We do this sort of clock synchronization routinely.  We know (by knowing the orbital elements of Mars and Earth) the one-way light time across that distance over a given interval; during that interval, we command the vehicle at Mars to emit a telemetry frame containing the current time, according to its local clock; on receipt of this frame we add the one-way light time to the reported time; the difference between the result and the current time at receipt (according to a reference time source on Earth) is the current error in the vehicle's clock.

In a DTN environment we would report this error back to the vehicle at Mars so that it would know its own current clock error, after which it could simply subtract that error from every clock reading in order to get the correct time.  So inserting accurate, synchronized creation time values into bundles would be straightforward.

Now, I would certainly agree that there is room for many milliseconds of slop in this sort of procedure, and of course the spacecraft clock error will change over time as the clock drifts, so the procedure would have to be repeated every so often.  But for the purposes of bundle expiration we only need very gross clock synchronization, at 1-second granularity.  The timing doesn't have to be nearly as accurate as is required for precise navigation (at which point relativistic effects do indeed become significant), and it would be unusual for a spacecraft clock to gain or lose as much as a second in a single day.

So I don't see the problem.  What makes clock synchronization intractable?

Scott

Date: Mon, 31 Mar 2008 18:30:48 -0400
From: Joseph Ishac <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Mail-Followup-To: Delay Tolerant Networking Interest List  <[email-masked]>
Subject: [dtn-interest] DTN Time Sync Issues
Reply-To: Joseph Ishac <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>

At the last DTNRG meeting held in Philadelphia, the research group
expressed interest in alleviating some of the time sync issues present
with the current DTN specifications.  The issues arises from the way
expired bundles are identified.  DTN bundles have a "creation time
stamp" and a "lifetime", the combination of which determines the exact
time in which the bundle is deemed stale and should be discarded by the
bundle agent that currently holds it.  However, this approach requires
that *all* DTN nodes processing that bundle to have their clocks
synchronized, as any skew will impact the way bundles are processed.
For example, a node whose time is skewed far into the future will
needlessly drop all of the bundles it receives.  Conversely, a node
skewed far into the past will quickly run out of resources as it
erroneously holds bundles which should be discarded.

Simply coming up with a way to synchronize clocks is a intractable task
in some cases, and simply impossible for others.  For example, it is
difficult to rely on clock synchronization for bundles that must
traverse DTN nodes which you do not own.  Transmitting to Mars from
Earth would require synchronization between clocks across planets, a
problem vastly complicated by the long delays and principles in basic
and special relativity.  To summarize, we believe that clock sync
between DTN nodes is an unreasonable assumption, and an assumption that
is not required to solve the issues at hand.

In order to overcome this requirement of clock synchronization, we
propose stepping back and first focusing on what issues need solving.
We then propose a means of solving those issues without the need for
time synchronization.

Issues:

(1) In case of configuration error or other reasons, a means to prevent
bundles from traversing DTN nodes endlessly.

(2) A means to identify stale bundles as specified by the users of the
DTN network overlay.

Proposal:

Instead of "creation time stamp" and  "lifetime", we specify two values:
the amount of time you can hold (store) a bundle before it is expired,
"hold time," and a "hop count".  The hop count is decremented at each
DTN node and actions are taken if it reaches zero.  The hold time is a
time value that is decremented based on the amount of time a bundle is
held in storage.  Actions are taken if the hold time expires.

This approach has several major advantages.  First, it is simple to
implement and requires less resources than the current approach.
Second, it does not require time synchronization between DTN nodes since
the only time value (the hold time) can be decremented accurately using
knowledge of only the local clock.  The holding time provides a
reasonable bound to storage resources and addresses issue (2).  The hop
count prevents sending loops or otherwise lost bundles - identical in
concept to its use in IP - and addresses issue (1).

Now one can argue that you loose the ability to specify a hard kill time
as you could with the previous parameters.  However, a user could
reasonably approximate such a time using the following conversion.

((creation time stamp) + (lifetime)) 
                       - (estimated propagation delays) = (hold time)

Clearly we provide this as only a simple method of conversion with the
understanding that a more elaborate computation could yield a more
accurate value.  The point remains that it is feasible to approximate
the ability to specify a hard expiration time.

Also, the hop count we specify decrements upon traversal of DTN nodes.
If IP is used as part of the convergence layer, it has it's own TTL to
handle IP routing loops, etc.  Even with the absence of a fully fleshed
out DTN routing scheme, it seems to be a fairly important check to have
in place.  By all means the hop count is NOT intended as a method of
specifying bundle lifetime by the user, but rather a means of preventing
"zombie bundles" from traversing DTN nodes endlessly.

We would like to hear comments regarding this approach from members of
the DTNRG, and if there is interest from the group, a means of moving
forward on the DTN timing issues.

-Joseph

Content-class: urn:content-classes:message
Date: Sun, 30 Mar 2008 16:21:06 -0700
From: "Petre Dini (pdini)" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Correction || Space Communications || Call for Papers: ICSNC 2008 || October 26-31, 2008 - Sliema, Malta ||
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

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

Small correction:

My original invitation was intended for Call for Papers and I omitted to
remove the up-front introduction.

While experts from DTN are very welcome to join the SPACOM's committee,
:( it was not our intention of having 900 committee members.

For the special SPACOM topics to contribute for, please see bellow. =20

Also, please forward the attached Call for Papers for ICSNC 2008 to
those groups/individuals which may be interested to submit/attend.

Cheers,
-- Petre
=20
=20
SPACOM: Space communications
Satellite communications: Hybrid Satellite, Terrestrial Networks
Protocols: Transport Protocol Performances over Satellites, IP over
Satellites
Onboard processing technology
Interplanetary communications: Spatial mission analysis, Systems
analysis, In-flight experiences, Delay tolerant networking [DTN]
Nano satellites and nano rockets
Fundamentals of nano-satellites communications: Challenging and
innovative issues, Research projects
New technologies specific for small satellites
Management of space communication projects
Applications: Earth Observation, Science, Telecommunications,
Navigations, New Technologies
Spatial tourism
International cooperation
Economics models and cost minimization
=20
=20
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please consider to contribute to and/or forward to the appropriate
groups the following opportunity to submit and publish original
scientific results.
Apologies for cross-postings.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
=20
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  ICSNC 2008 Call for Papers =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
CALL FOR PAPERS, TUTORIALS, PANELS=20
=20
=20
ICSNC 2008,  The Third International Conference on Systems and Networks
Communications=20

October 26-31, 2008 - Sliema, Malta=20

General page: http://www.iaria.org/conferences2008/ICSNC08.html
<http://www.iaria.org/conferences2008/ICSNC08.html>=20

=20

Call for Papers: http://www.iaria.org/conferences2008/CfPICSNC08.html
=20
Submission deadline:  May 10, 2008=20
=20
Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE
Digital Library, and indexed with the major indexes.

Extended versions of selected papers will be invited for specialized
journals.
=20
ICSNC 2008 Special Area Tracks (details in the CfP on site):

*=09
	WINET      Wireless networks                           =20
*=09
	HSNET     High speed networks

*=09
	SENET     Sensor networks

*=09
	MHNET    Mobile and Ad hoc networks                      =20
*=09
	SESYS    Security systems

*=09
	MCSYS    Multimedia communications systems  =20
*=09
	POSYS    Policy-based systems                                  =20
*=09
	PESYS    Pervasive education systems =20
*=09
	SPACOM  Space Communications

=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IARIA Publicity Board  =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

------_=_NextPart_001_01C892BC.BBFCBA8F
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.2900.3268" name=3DGENERATOR></HEAD>
<BODY><SPAN class=3D327301023-30032008><FONT face=3DArial =
color=3D#0000ff size=3D2>Small=20
correction:</FONT></SPAN><BR>
<DIV class=3Dgmail_quote>
<DIV>
<DIV>
<P><SPAN><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D327301023-30032008>My original invitation was intended for <FONT =

color=3D#ff0000>Call for Papers</FONT> and&nbsp;I omitted to remove the =
up-front=20
introduction.</SPAN></FONT></FONT></FONT></SPAN></P>
<P><SPAN><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D327301023-30032008>While experts from DTN are very welcome to =
join the=20
SPACOM's committee, :( it was not&nbsp;our=20
intention</SPAN></FONT></FONT></FONT></SPAN><SPAN><FONT =
face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2><SPAN class=3D327301023-30032008>&nbsp;of =
having 900=20
committee members.</SPAN></FONT></FONT></FONT></SPAN></P>
<P><FONT color=3D#0000ff><SPAN><FONT face=3DArial><FONT><FONT =
size=3D2><SPAN=20
class=3D327301023-30032008>For the special SPACOM topics&nbsp;to =
contribute for,=20
please see =
bellow.&nbsp;&nbsp;</SPAN></FONT></FONT></FONT></SPAN></FONT></P>
<P><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2>Also, please =
forward=20
the&nbsp;<SPAN>attached </SPAN>Call for Papers=20
for<SPAN><SPAN>&nbsp;<SPAN>ICSNC</SPAN>&nbsp;</SPAN></SPAN>2008 to those =

groups/individuals which may be interested to=20
submit/attend.</FONT></FONT></FONT></P></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN><SPAN=20
class=3D327301023-30032008>Cheers,</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN><SPAN=20
class=3D327301023-30032008>-- Petre</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN><SPAN=20
class=3D327301023-30032008></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><B>SPACOM: Space communications<BR></B>Satellite =
communications<SPAN>:=20
</SPAN>Hybrid Satellite<SPAN>, </SPAN>Terrestrial Networks</DIV>
<DIV>Protocols: Transport Protocol Performances over Satellites, IP over =

Satellites</DIV>
<DIV>Onboard processing technology</DIV>
<DIV>Interplanetary communications<SPAN>: </SPAN>Spatial mission=20
analysis<SPAN>,</SPAN> Systems analysis<SPAN>,</SPAN> In-flight=20
experiences<SPAN>, </SPAN>Delay tolerant networking =
[DTN<SPAN>]</SPAN></DIV>
<DIV>Nano satellites and nano rockets</DIV>
<DIV>Fundamental<SPAN>s</SPAN> of nano-satellites communications<SPAN>:=20
</SPAN>Challenging and innovative issues<SPAN>,</SPAN> Research =
projects</DIV>
<DIV>New technologies specific for small satellites</DIV>
<DIV>Management of space communication project<SPAN>s</SPAN></DIV>
<DIV>Applications<SPAN>: </SPAN>Earth Observation<SPAN>,</SPAN>=20
Science<SPAN>,</SPAN> Telecommunications<SPAN>,</SPAN> =
Navigations<SPAN>,</SPAN>=20
New Technologies</DIV>
<DIV>Spatial tourism</DIV>
<DIV>International cooperation</DIV>
<DIV>Economics models and cost minimization</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2><SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN>
<DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial=20
size=3D2><SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN>=
</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial size=3D2><SPAN>Please consider =
to=20
contribute to and/or forward to the appropriate groups the following =
opportunity=20
to submit and publish original scientific=20
results.</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial size=3D2><SPAN>Apologies for=20
cross-postings.</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial=20
size=3D2><SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN>=
</FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial=20
size=3D2><SPAN></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial=20
size=3D2><SPAN></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN><SPAN><SPAN><FONT face=3DArial><FONT=20
size=3D2><SPAN>&nbsp;</SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&nb=
sp;<SPAN><SPAN><FONT=20
color=3D#0000ff>&nbsp;<SPAN><FONT=20
color=3D#000000>ICS<SPAN>NC</SPAN></FONT></SPAN>&nbsp;</FONT></SPAN></SPA=
N>2008=20
Call for Papers=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></FONT></SPAN></SPAN>=
</SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN>=
</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></S=
PAN></DIV>
<DIV><SPAN><FONT face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial><FONT size=3D2>CALL FOR PAPERS, TUTORIALS, =
PANELS<SPAN><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV></DIV></SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><FONT size=3D2><FONT=20
face=3DArial>ICS<SPAN>NC</SPAN> 2008<SPAN>,</SPAN>&nbsp; The Third =
International=20
Conference on Systems and Networks Communications</FONT><FONT=20
face=3D"Times New Roman">=20
</FONT></FONT></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></DIV>
<DIV>
<DIV>
<P><FONT face=3DArial size=3D2>October 26-31, 2008 - Sliema, Malta=20
</FONT></P><SPAN></SPAN><SPAN><SPAN><FONT face=3DArial><FONT =
size=3D2>General page:=20
</FONT><A title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html=20
href=3D"http://www.iaria.org/conferences2008/ICSNC08.html" =
target=3D_blank><FONT=20
title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html=20
size=3D2>http://www.iaria.org/conferences2008/ICSNC08.html</FONT></A></FO=
NT></SPAN></SPAN></DIV>
<P style=3D"MARGIN: 0in 0in 0pt"><SPAN><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</P>
<DIV style=3D"MARGIN: 0in 0in 0pt"><SPAN></SPAN><SPAN><FONT =
face=3DArial><FONT=20
size=3D2>Call for Papers:<SPAN> <A=20
title=3Dhttp://www.iaria.org/conferences2008/CfPICSNC08.html=20
href=3D"http://www.iaria.org/conferences2008/CfPICSNC08.html"=20
target=3D_blank>http://www.iaria.org/conferences2008/CfPICSNC08.html</A><=
/SPAN></FONT></FONT></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN><FONT face=3DArial><FONT size=3D2><SPAN>S</SPAN>ubmission=20
deadline:&nbsp;<SPAN><FONT color=3D#0000ff><FONT =
color=3D#000000>&nbsp;May <SPAN>10,=20
</SPAN>2008</FONT>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV><SPAN><FONT face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV><SPAN>
<P><SPAN><FONT face=3DArial size=3D2>Submissions will be=20
peer-reviewed,&nbsp;published by IEEE CPS, posted in IEEE Digital=20
Library<SPAN>,</SPAN> and indexed with&nbsp;<SPAN>the major=20
indexes</SPAN>.</FONT></SPAN></P></SPAN></DIV>
<DIV><SPAN><FONT face=3DArial size=3D2>Extended versions of selected =
papers will=20
be&nbsp;invited for specialized =
journals.</FONT></SPAN><SPAN></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT=20
size=3D2><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN><SPAN>ICS<SPAN>N=
C</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN>&n=
bsp;<SPAN>2008&nbsp;<SPAN>Special=20
Area </SPAN></SPAN>T<SPAN><SPAN>racks</SPAN></SPAN> (details in the CfP =
on=20
site)<SPAN>:</SPAN></FONT></FONT><SPAN><SPAN></SPAN></SPAN></DIV>
<UL>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  =
size=3D2>WINET<SPAN><SPAN>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>Wire=
less=20
  networks&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  size=3D2>HSNET<SPAN><SPAN>&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>High speed =
networks=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  size=3D2>SENET<SPAN>&nbsp;<SPAN>&nbsp;&nbsp;&nbsp; </SPAN>Sensor =
networks&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT =
size=3D2>MHNET<SPAN><SPAN>&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><SPAN style=3D"FONT-FAMILY: Arial">Mobile</SPAN><SPAN=20
  style=3D"FONT-FAMILY: Arial"> and Ad hoc networks&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT =
size=3D2>SESYS<SPAN><SPAN>&nbsp;&nbsp;&nbsp;=20
  </SPAN>Security systems=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  size=3D2>MCSYS<SPAN>&nbsp;&nbsp;&nbsp;<SPAN>&nbsp;</SPAN>Multimedia=20
  communications systems&nbsp;&nbsp; </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  size=3D2>POSYS<SPAN>&nbsp;&nbsp;&nbsp;&nbsp;Policy-based=20
  =
systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT=20
  size=3D2>PESYS<SPAN>&nbsp;&nbsp;&nbsp;&nbsp;Pervasive education=20
  systems&nbsp;<SPAN><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV><SPAN><FONT face=3DArial><FONT size=3D2><SPAN><SPAN><FONT =
color=3D#0000ff><FONT=20
  color=3D#000000>SPACOM</FONT> </FONT>&nbsp;Space=20
  Communications</SPAN></SPAN></FONT></FONT></SPAN></DIV></LI></UL>
<DIV><SPAN><FONT face=3DArial><FONT=20
size=3D2><SPAN></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN><FONT face=3DArial =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></SPAN=
></DIV>
<DIV><SPAN></SPAN><SPAN><SPAN>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN><SPAN>IARIA Publicity=20
Board</SPAN></SPAN><SPAN><SPAN>&nbsp;&nbsp;<SPAN>&nbsp;</SPAN></SPAN></SP=
AN></FONT></FONT></DIV></SPAN></SPAN></DIV>
<DIV><SPAN>
<DIV><FONT face=3DArial><FONT =
size=3D2>=3D<SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<SPAN>=3D=
<SPAN><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></SPAN></FONT></FONT></DIV>
<DIV></DIV></SPAN><SPAN><SPAN><SPAN><FONT face=3DArial=20
size=3D2><SPAN><SPAN><SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></DIV>=
</DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C892BC.BBFCBA8F--

Content-class: urn:content-classes:message
Date: Sun, 30 Mar 2008 15:02:44 -0700
From: "Petre Dini (pdini)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Space Communications || Invitation committee membership: ICSNC 2008 || October 26-31, 2008 - Sliema, Malta ||
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

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

Apologizes for duplicate invitations.
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
INVITATION:
=20
It is our pleasure to invite you as a member of the international =
committee of SPACOM (Space Communications) during the ICSNC 2008,  The =
Third International Conference on Systems and Networks Communications in =
 October 26-31, 2008 (Malta).
=20
Site : http://www.iaria.org/conferences2008/ICSNC08.html =
<http://www.iaria.org/conferences2008/ICSNC08.html>=20
=20
As a committee member you will be invited to review 2-3 papers, propose =
new committee members and topics, distribute the Call for Submissions to =
appropriate groups and consider to submit contribution / attend.

Once we get your acknowledgement the ICSNC 2008 committee will be =
updated.

Looking forward for your positive acknowledgement, please provide your =
most updated coordinates [name/affiliation/e-mail address]  to =
[email-masked]. =20

Also, please forward the attached Call for Papers for ICSNC 2008 to =
those groups/individuals which may be interested to submit/attend.

The topics for the Space Communications area are:
=20
SPACOM: Space communications
Satellite communications: Hybrid Satellite, Terrestrial Networks
Protocols: Transport Protocol Performances over Satellites, IP over =
Satellites
Onboard processing technology
Interplanetary communications: Spatial mission analysis, Systems =
analysis, In-flight experiences, Delay tolerant networking [DTN]
Nano satellites and nano rockets
Fundamentals of nano-satellites communications: Challenging and =
innovative issues, Research projects
New technologies specific for small satellites
Management of space communication projects
Applications: Earth Observation, Science, Telecommunications, =
Navigations, New Technologies
Spatial tourism
International cooperation
Economics models and cost minimization
=20
Thanks,
=20
ICSNC 2008 TPC Chair
Jos=E9phine Kohlenberg, INSTITUT TELECOM / TELECOM & Management =
SudParis, France
=20
=20
ICSNC 2008 Steering Committee Chair
Petre Dini, Cisco Systems, USA // Concordia University, Canada
=20
=20
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please consider to contribute to and/or forward to the appropriate =
groups the following opportunity to submit and publish original =
scientific results.
Apologies for cross-postings.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
=20
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  ICSNC 2008 Call for Papers =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
CALL FOR PAPERS, TUTORIALS, PANELS=20
=20
=20
ICSNC 2008,  The Third International Conference on Systems and Networks =
Communications=20

October 26-31, 2008 - Sliema, Malta=20

General page: http://www.iaria.org/conferences2008/ICSNC08.html =
<http://www.iaria.org/conferences2008/ICSNC08.html>=20

=20

Call for Papers: http://www.iaria.org/conferences2008/CfPICSNC08.html
=20
Submission deadline:  May 10, 2008=20
=20
Submissions will be peer-reviewed, published by IEEE CPS, posted in IEEE =
Digital Library, and indexed with the major indexes.

Extended versions of selected papers will be invited for specialized =
journals.
=20
ICSNC 2008 Special Area Tracks (details in the CfP on site):

*=09
	WINET      Wireless networks                           =20
*=09
	HSNET     High speed networks                                   =20
*=09
	SENET     Sensor networks                                          =20
*=09
	MHNET    Mobile and Ad hoc networks                      =20
*=09
	SESYS    Security systems                                         =20
*=09
	MCSYS    Multimedia communications systems  =20
*=09
	POSYS    Policy-based systems                                  =20
*=09
	PESYS    Pervasive education systems =20
*=09
	SPACOM  Space Communications

=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IARIA Publicity Board  =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office" xmlns:st1 =
=3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3268" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D371035521-30032008>Apologizes for=20
duplicate invitations.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT=
></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008>INVITATION:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D+0><SPAN class=3D622322715-20032008><FONT face=3DArial =
size=3D2>It=20
is&nbsp;our pleasure to invite you as a member of the international =
committee of=20
SPACOM (Space Communications) during the </FONT></SPAN></FONT><FONT=20
size=3D+0><SPAN class=3D622322715-20032008><SPAN =
class=3D656514020-07082007><SPAN=20
class=3D354172323-17122007><SPAN class=3D845511023-31122007><SPAN=20
class=3D461162218-02012008><SPAN class=3D788095519-24012008><FONT =
face=3DArial=20
size=3D2>ICS<SPAN class=3D613560220-24012008>NC</SPAN> 2008<SPAN=20
class=3D788095519-24012008>,</SPAN>&nbsp; The Third International =
Conference on=20
Systems and Networks Communications&nbsp;in &nbsp;October 26-31, 2008=20
(Malta).</FONT></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008><SPAN=20
class=3D656514020-07082007><SPAN class=3D354172323-17122007><SPAN=20
class=3D845511023-31122007><SPAN class=3D461162218-02012008><SPAN=20
class=3D788095519-24012008></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FO=
NT>&nbsp;</DIV>
<DIV><FONT size=3D+0><SPAN class=3D622322715-20032008><SPAN=20
class=3D938040920-05062007><SPAN class=3D938040920-05062007><FONT =
size=3D+0><FONT=20
face=3DArial><FONT size=3D2><SPAN =
class=3D622322715-20032008>Site&nbsp;</SPAN>:=20
</FONT></FONT></FONT><A =
title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html=20
href=3D"http://www.iaria.org/conferences2008/ICSNC08.html"><FONT=20
title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html face=3DArial=20
size=3D2>http://www.iaria.org/conferences2008/ICSNC08.html</FONT></A></SP=
AN></SPAN></SPAN></FONT></DIV>
<DIV><FONT size=3D+0><SPAN class=3D622322715-20032008><SPAN=20
class=3D938040920-05062007><SPAN=20
class=3D938040920-05062007></SPAN>&nbsp;</DIV></SPAN></SPAN></FONT>
<DIV><FONT face=3DArial size=3D2>As a committee member&nbsp;<SPAN=20
class=3D175321004-31012008>you will </SPAN>be invited to review 2-3 =
papers,=20
propose new committee members and topics, distribute the Call for =
Submissions to=20
appropriate groups and consider to<SPAN=20
class=3D175321004-31012008>&nbsp;</SPAN><SPAN =
class=3D175321004-31012008>submit=20
contribution&nbsp;</SPAN>/<SPAN=20
class=3D175321004-31012008>&nbsp;</SPAN>attend.</FONT></DIV>
<DIV>
<P><FONT face=3DArial size=3D2>Once we get your acknowledgement<SPAN=20
class=3D622322715-20032008> </SPAN>the<SPAN =
class=3D344112416-07012008><SPAN=20
class=3D175321004-31012008>&nbsp;<SPAN=20
class=3D622322715-20032008>ICSNC</SPAN>&nbsp;</SPAN></SPAN>2008 =
committee will be=20
updated.</FONT></P>
<P><FONT color=3D#000000><FONT face=3DArial><FONT size=3D2>Looking =
forward for your=20
positive acknowledgement, please provide your most updated coordinates=20
[name/affiliation/e-mail address]<SPAN class=3D175321004-31012008><FONT=20
color=3D#0000ff>&nbsp; <FONT color=3D#000000>to</FONT> <A=20
title=3Dmailto:[email-masked] =
href=3D"mailto:[email-masked]">[email-masked]</A>.=20
&nbsp;</FONT></SPAN></FONT></FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Also, please forward the&nbsp;<SPAN=20
class=3D622322715-20032008>attached </SPAN>Call for Papers for<SPAN=20
class=3D344112416-07012008><SPAN class=3D175321004-31012008>&nbsp;<SPAN=20
class=3D622322715-20032008>ICSNC</SPAN>&nbsp;</SPAN></SPAN>2008 to those =

groups/individuals which may be interested to =
submit/attend.</FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008>The =
topics for the=20
Space Communications area are:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><STRONG>SPACOM: Space communications<BR></STRONG>Satellite=20
communications<SPAN class=3D622322715-20032008>: </SPAN>Hybrid =
Satellite<SPAN=20
class=3D622322715-20032008>, </SPAN>Terrestrial Networks</DIV>
<DIV>Protocols: Transport Protocol Performances over Satellites, IP over =

Satellites</DIV>
<DIV>Onboard processing technology</DIV>
<DIV>Interplanetary communications<SPAN class=3D622322715-20032008>:=20
</SPAN>Spatial mission analysis<SPAN class=3D622322715-20032008>,</SPAN> =
Systems=20
analysis<SPAN class=3D622322715-20032008>,</SPAN> In-flight =
experiences<SPAN=20
class=3D622322715-20032008>, </SPAN>Delay tolerant networking [DTN<SPAN=20
class=3D622322715-20032008>]</SPAN></DIV>
<DIV>Nano satellites and nano rockets</DIV>
<DIV>Fundamental<SPAN class=3D622322715-20032008>s</SPAN> of =
nano-satellites=20
communications<SPAN class=3D622322715-20032008>: </SPAN>Challenging and =
innovative=20
issues<SPAN class=3D622322715-20032008>,</SPAN> Research projects</DIV>
<DIV>New technologies specific for small satellites</DIV>
<DIV>Management of space communication project<SPAN=20
class=3D622322715-20032008>s</SPAN></DIV>
<DIV>Applications<SPAN class=3D622322715-20032008>: </SPAN>Earth =
Observation<SPAN=20
class=3D622322715-20032008>,</SPAN> Science<SPAN =
class=3D622322715-20032008>,</SPAN>=20
Telecommunications<SPAN class=3D622322715-20032008>,</SPAN> =
Navigations<SPAN=20
class=3D622322715-20032008>,</SPAN> New Technologies</DIV>
<DIV>Spatial tourism</DIV>
<DIV>International cooperation</DIV>
<DIV>Economics models and cost minimization</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008>ICSNC =
2008 TPC=20
Chair</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D622322715-20032008></SPAN></FONT><FONT=20
size=3D+0><SPAN class=3D622322715-20032008><FONT face=3DArial><FONT =
size=3D2>Jos=E9phine=20
Kohlenberg<SPAN class=3D622322715-20032008>, </SPAN>INSTITUT TELECOM / =
TELECOM=20
&amp; Management SudParis<SPAN class=3D622322715-20032008>,=20
France</SPAN></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT size=3D+0><SPAN class=3D622322715-20032008><FONT =
face=3DArial><FONT=20
size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT></FONT>&nbsp;</DIV></SPAN></FONT=
>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008>ICSNC =
2008 Steering=20
Committee Chair</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008>Petre =
Dini, Cisco=20
Systems, USA // Concordia University, Canada</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D622322715-20032008>
<DIV>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008>Please consider to contribute to and/or =
forward to the=20
appropriate groups the following opportunity to submit and publish =
original=20
scientific results.</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008>Apologies for=20
cross-postings.</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D</SPAN></FONT></SPAN></SPAN></SPAN></DIV>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV=
>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008></SPAN></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV=
>
<DIV><SPAN class=3D861085301-22112007><SPAN =
class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D757500719-24012008>&nbsp;</SPAN>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D&nbsp;<SPAN=20
class=3D461162218-02012008><SPAN class=3D757500719-24012008><FONT=20
color=3D#0000ff>&nbsp;<SPAN class=3D788095519-24012008><FONT =
color=3D#000000>ICS<SPAN=20
class=3D613560220-24012008>NC</SPAN></FONT></SPAN>&nbsp;</FONT></SPAN></S=
PAN>2008=20
Call for Papers =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></FONT></SPAN></SPAN>=
</SPAN><SPAN=20
class=3D861085301-22112007><SPAN class=3D060413502-30122007><SPAN=20
class=3D438414823-31122007><SPAN class=3D515012800-09122007><SPAN=20
class=3D280585301-11122007><SPAN class=3D412321617-08122007><SPAN=20
class=3D654460502-09122007><SPAN class=3D515012800-09122007><SPAN=20
class=3D280585301-11122007><SPAN class=3D412321617-08122007><SPAN=20
class=3D654460502-09122007></DIV>
<DIV><SPAN class=3D757500719-24012008><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial><FONT size=3D2>CALL FOR PAPERS, TUTORIALS, =
PANELS<SPAN=20
class=3D757500719-24012008><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D757500719-24012008></SPAN></FONT>&nbsp;</DIV>
<DIV></SPAN></SPAN></SPAN></SPAN><SPAN class=3D656514020-07082007><SPAN=20
class=3D354172323-17122007><SPAN class=3D845511023-31122007><SPAN=20
class=3D461162218-02012008><SPAN class=3D788095519-24012008><FONT =
size=3D2><FONT=20
face=3DArial>ICS<SPAN class=3D613560220-24012008>NC</SPAN> 2008<SPAN=20
class=3D788095519-24012008>,</SPAN>&nbsp; The Third International =
Conference on=20
Systems and Networks Communications</FONT><FONT face=3D"Times New =
Roman">=20
</FONT></FONT></DIV>
<DIV>
<DIV class=3Dtitle>
<P class=3Dtitle><FONT face=3DArial size=3D2>October 26-31, 2008 - =
Sliema, Malta=20
</FONT></P></SPAN></SPAN></SPAN></SPAN><SPAN=20
class=3D354172323-17122007></SPAN></SPAN><SPAN =
class=3D938040920-05062007><SPAN=20
class=3D938040920-05062007><FONT face=3DArial><FONT size=3D2>General =
page: </FONT><A=20
title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html=20
href=3D"http://www.iaria.org/conferences2008/ICSNC08.html"><FONT=20
title=3Dhttp://www.iaria.org/conferences2008/ICSNC08.html=20
size=3D2>http://www.iaria.org/conferences2008/ICSNC08.html</FONT></A></FO=
NT></SPAN></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D938040920-05062007><FONT face=3DArial =
size=3D2></FONT></SPAN>&nbsp;</P>
<DIV style=3D"MARGIN: 0in 0in 0pt"><SPAN =
class=3D938040920-05062007></SPAN><SPAN=20
class=3D938040920-05062007><FONT face=3DArial><FONT size=3D2>Call for =
Papers:<SPAN=20
class=3D200592204-21012008> <A=20
title=3Dhttp://www.iaria.org/conferences2008/CfPICSNC08.html=20
href=3D"http://www.iaria.org/conferences2008/CfPICSNC08.html">http://www.=
iaria.org/conferences2008/CfPICSNC08.html</A></SPAN></FONT></FONT></SPAN>=
</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV class=3Dtitle><SPAN class=3D880331623-22112007><FONT =
face=3DArial><FONT=20
size=3D2><SPAN class=3D859300119-02122007>S</SPAN>ubmission =
deadline:&nbsp;<SPAN=20
class=3D757500719-24012008><FONT color=3D#0000ff><FONT =
color=3D#000000>&nbsp;May <SPAN=20
class=3D788095519-24012008>10,=20
</SPAN>2008</FONT>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
<DIV class=3Dtitle><SPAN class=3D880331623-22112007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV><SPAN class=3D880331623-22112007>
<P class=3Dtitle><SPAN class=3D630005523-11072007><FONT face=3DArial=20
size=3D2>Submissions will be peer-reviewed,&nbsp;published by IEEE CPS, =
posted in=20
IEEE Digital Library<SPAN class=3D370324200-12072007>,</SPAN> and =
indexed=20
with&nbsp;<SPAN class=3D370324200-12072007>the major=20
indexes</SPAN>.</FONT></SPAN></P></DIV>
<DIV class=3Dtitle><SPAN class=3D630005523-11072007><FONT face=3DArial =
size=3D2>Extended=20
versions of selected papers will be&nbsp;invited for specialized=20
journals.</FONT></SPAN><SPAN class=3D110521407-03032007></DIV>
<DIV class=3Dtitle><FONT face=3DArial =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV class=3Dtitle><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D630005523-11072007><SPAN class=3D237204317-23112007><SPAN=20
class=3D859300119-02122007><SPAN class=3D654460502-09122007><SPAN=20
class=3D121404103-28122007><SPAN class=3D845511023-31122007><SPAN=20
class=3D461162218-02012008><SPAN class=3D757500719-24012008><SPAN=20
class=3D788095519-24012008>ICS<SPAN=20
class=3D613560220-24012008>NC</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></=
SPAN></SPAN></SPAN></SPAN>&nbsp;<SPAN=20
class=3D702580313-16062007>2008&nbsp;<SPAN =
class=3D845511023-31122007>Special Area=20
</SPAN></SPAN>T<SPAN class=3D521280517-29072007><SPAN=20
class=3D654460502-09122007>racks</SPAN></SPAN> (details in the CfP on =
site)<SPAN=20
class=3D521280517-29072007>:</SPAN></FONT></FONT><SPAN=20
class=3D521280517-29072007><SPAN class=3D656514020-07082007></DIV>
<UL>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>WINET<SPAN><SPAN=20
  =
class=3D613560220-24012008>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>Wir=
eless=20
  networks&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>HSNET<SPAN><SPAN =
class=3D613560220-24012008>&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>High speed networks=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>SENET<SPAN>&nbsp;<SPAN =
class=3D613560220-24012008>&nbsp;&nbsp;&nbsp;=20
  </SPAN>Sensor networks&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT =
size=3D2>MHNET<SPAN=20
  style=3D"mso-tab-count: 1"><SPAN =
class=3D613560220-24012008>&nbsp;&nbsp;&nbsp;=20
  </SPAN></SPAN><st1:City w:st=3D"on"><st1:place w:st=3D"on"><SPAN=20
  style=3D"FONT-FAMILY: Arial">Mobile</SPAN></st1:place></st1:City><SPAN =

  style=3D"FONT-FAMILY: Arial"> and Ad hoc networks&nbsp;=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>SESYS<SPAN><SPAN =
class=3D613560220-24012008>&nbsp;&nbsp;&nbsp;=20
  </SPAN>Security systems=20
  =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>MCSYS<SPAN>&nbsp;&nbsp;&nbsp;<SPAN=20
  class=3D613560220-24012008>&nbsp;</SPAN>Multimedia communications=20
  systems&nbsp;&nbsp; </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>POSYS<SPAN>&nbsp;&nbsp;&nbsp;&nbsp;Policy-based=20
  =
systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN><o:p></o:p></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2>PESYS<SPAN>&nbsp;&nbsp;&nbsp;&nbsp;Pervasive education=20
  systems&nbsp;<SPAN class=3D306432015-20032008><FONT=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT></FONT></SPAN></DIV>
  <LI>
  <DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
  size=3D2><SPAN><SPAN class=3D306432015-20032008><FONT =
color=3D#0000ff><FONT=20
  color=3D#000000>SPACOM</FONT> </FONT>&nbsp;Space=20
  Communications</SPAN></SPAN></FONT></FONT></SPAN></DIV></LI></UL>
<DIV style=3D"tab-stops: 86.85pt"><SPAN><FONT face=3DArial><FONT=20
size=3D2><SPAN></SPAN><o:p></o:p></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV></SPAN><SPAN class=3D656514020-07082007><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT></SPAN=
></DIV>
<DIV><SPAN class=3D656514020-07082007></SPAN></SPAN><SPAN=20
class=3D521280517-29072007><SPAN class=3D845511023-31122007>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D394253102-16012008><SPAN=20
class=3D894232702-24012008>IARIA Publicity Board</SPAN></SPAN><SPAN=20
class=3D394253102-16012008><SPAN =
class=3D690193601-24012008>&nbsp;&nbsp;<SPAN=20
class=3D894232702-24012008>&nbsp;</SPAN></SPAN></SPAN></FONT></FONT></DIV=
></SPAN></SPAN></DIV>
<DIV><SPAN class=3D521280517-29072007>
<DIV><FONT face=3DArial><FONT size=3D2>=3D<SPAN=20
class=3D121404103-28122007>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
<SPAN class=3D845511023-31122007>=3D<SPAN=20
class=3D447141200-01012008><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></SPAN></FONT></FONT></DIV>
<DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><SPAN=20
class=3D938040920-05062007><SPAN class=3D880331623-22112007><SPAN=20
class=3D521280517-29072007><FONT face=3DArial size=3D2><SPAN=20
class=3D121404103-28122007><SPAN class=3D845511023-31122007><SPAN=20
class=3D438414823-31122007>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D</SPAN></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></DIV>=
</DIV></SPAN></SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D622322715-20032008></SPAN></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C892B1.C9FB42F6--

Date: Sun, 30 Mar 2008 23:24:28 +0200
From: FORTAINE Guillaume <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] High Throughput and Low Latency Multi-Hop Mobile Ad-hoc Network (MANET) Multimedia Streaming
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Misters,

Happy New Year to You.

Let me introduce myself : Guillaume FORTAINE, Engineer in Computer
Science. It's an honor for me to send this mail to You.

I am definitely aware of Your preeminence in the Mobile
Telecommunications World.

Working with an Open Source Mesh Networks design team :

24C3: *Wireless Kernel Tweaking* 
<http://events.ccc.de/congress/2007/Fahrplan/events/2292.en.html>

We would greatly appreciate to set up a Working Group, if
possible, please to provide QoS (For VoIP/IPTV) to our Users.

Please find below our working plan :

(SBIR) Navy - *High Throughput and Low Latency Multi-Hop Mobile Ad* … 
<http://www.navysbir.com/n08_1/N081-102.htm>

OBJECTIVE: While MANET promises to significantly increase the available
Navy bandwidth, existing MANET throughput decreases exponentially as the
number of hops increases (hops > 4). This research will enable: 1) a
multimedia stream to hop over hundreds of nodes without quality
degradation and 2) hundreds of multimedia steams to cross a single node
without quality degradation; 3) an advance in the state-of-the art
videoconferencing and legacy application virtualization.
Develop an end-to-end software solution (based on low-cost commodity
hardware) that allows a multimedia stream (voice-over-internet-protocol
[VoIP], videoconferencing, screen/application sharing, file transfer,
and biological/chemical sensor data) to hop over a large number of nodes
without quality degradation as defined by psychological human factor
quality-of-service (QoS) requirements.

DESCRIPTION: Existing MANET solutions have difficulty delivering a
multimedia stream over a large number of hops. This research will
develop novel software solutions to maintain high throughput and low
latency for multimedia delivery over a large number of hops. The
solution should: allow >1 Mbps and <500 msec of delay over 100 hops and
be able to handle the cross-stream interference from multiple steams
flowing over a particular node; and allow low-bandwidth
videoconferencing for multiple sites (>100); exploit the difference in
human factor requirements for QoS for different multimedia (audio vs.
video, vs. sensor data, etc) to optimize the streaming of different
media types; use advanced compression and networking techniques to
achieve a significant reduction (10X) in bandwidth compared to existing
commercial solutions; advance in the state-of-the art videoconferencing
and legacy application virtualization; adapt to a variety of networks
(available bandwidth, packet loss rate and jitter); support FIPS 140-2
256 bit AES encryption; record the training sessions; and be able to run
as a web-service or as a stand-alone program on segmented/closed/MANET
networks.

We look forward to Your Answer,

Best Regards,

Dr. Guillaume FORTAINE
Consultant Service Strategy and Innovation
Company : Emppoo (Em(po)²) - Empowering The People
Street : Moulin d'Ignaucourt
ZIP : 62810
City : BERLENCOURT-LE-CAUROY
Country : FRANCE
Tel : +33631092519

Quotes :

"Scientia potentia est.", Sir Francis Bacon

"I consider life itself to be an instinct for growth, for endurance, for 
the accumulation of force, for power: when there is no will to power, 
there is decline.", Friedrich Nietzsche

"Great engineering is about being frugal - it's easy to make great cars 
with a lot of resources.", Carlos Ghosn

From: Michael Demmer <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 27 Mar 2008 12:19:59 -0700
Subject: Re: [dtn-interest] send file over DTN/UDP?
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Mar 27, 2008, at 11:50 AM, Stephen Farrell wrote:
>
> This is probably a better discussion for the dtn-users list.

Agreed.

> I posted a hack/patch that works around this about a year
> ago, dunno if it'd work with the latest version though, and
> it probably still isn't something that should be part of
> the main source, but it worked for my short-term needs at
> the time.

The underlying problem is that DTN2 does not really support proactive  
fragmentation in the current implementation.

It's on my list of things to do.

-mike

> Xuan Wu wrote:
>> We used tcpdump to trace the transmission of the DTN/UDP. From the
>> output of tcpdump, UDP can send files less than 65507 bytes. But the
>> number of fragment sent by IP is limited. Whatever file size we send
>> over UDP, the number of fragment is about 5. That is why we only can
>> receive 7.1K files (each fragment is about 1500 bytes). This file  
>> size
>> is really too small to continue our experiment. Is there any idea to
>> send a file around the limit of 65507 bytes?
>>
>> This is the output of sender side:
>> tcpdump -i ppp0 -s 128 host 10.0.0.3 and host 10.0.0.4 -v
>> tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked),  
>> capture
>> size 128 bytes
>> 15:43:50.494534 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+],
>> proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP,
>> length 52048
>> 15:43:50.494541 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:43:50.560951 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:43:50.693875 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:43:50.826807 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:44:20.673863 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags
>> [none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556:
>> ip reassembly time exceeded
>>
>> This is the output of receiver side:
>> [root@snf ~]# tcpdump -i ppp1 -s 128 host 10.0.0.4 and host  
>> 10.0.0.3 -v
>> tcpdump: listening on ppp1, link-type LINUX_SLL (Linux cooked),  
>> capture
>> size 128 bytes
>> 15:44:36.830496 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+],
>> proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP,
>> length 52048
>> 15:44:36.960448 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:44:37.090411 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:44:37.220396 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:44:37.350369 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags  
>> [+],
>> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
>> 15:45:06.825912 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags
>> [none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556:
>> ip reassembly time exceeded
>>
>> Thanks
>>
>>
>>
>>
>> Darren Long wrote:
>>
>>
>> Hiy,
>>
>>
>> Whilst their may be maximum size issues associated with bundles
>> themselves, there is also the issue of IPv4 fragmentation for UDP
>> datagrams, which might also become problematic at high rates. This
>> might constrain the way you use the UDP-CL.  See:
>>
>> http://www.tools.ietf.org/html/draft-mathis-frag-harmful-00
>>
>> Hope this helps,
>>
>> Darren
>>
>> On 25 Mar 2008, at 22:20, Xuan Wu wrote:
>>>>> We are running DTN over UDP. According to the manual, the limit of
>>>>> datagram is 65507 bytes. So we tried to send a 60k file over DTN/ 
>>>>> UDP.
>>>>> But unfortunately, the receiver can not receive this 60k file.  
>>>>> And we
>>>>> also find out that we only can successfully send and receive files
>>>>> less
>>>>> than 6k. How can we send a file with maximum size?
>>>>> _______________________________________________
>>>>> dtn-interest mailing list
>>>>> [email-masked]
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 27 Mar 2008 18:50:36 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] =?iso-8859-1?q?send_file_over_DTN/UDP=3F?=
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is probably a better discussion for the dtn-users list.

I posted a hack/patch that works around this about a year
ago, dunno if it'd work with the latest version though, and
it probably still isn't something that should be part of
the main source, but it worked for my short-term needs at
the time.

S.

Xuan Wu wrote:
> We used tcpdump to trace the transmission of the DTN/UDP. From the 
> output of tcpdump, UDP can send files less than 65507 bytes. But the 
> number of fragment sent by IP is limited. Whatever file size we send 
> over UDP, the number of fragment is about 5. That is why we only can 
> receive 7.1K files (each fragment is about 1500 bytes). This file size 
> is really too small to continue our experiment. Is there any idea to 
> send a file around the limit of 65507 bytes?
>  
> This is the output of sender side:  
> tcpdump -i ppp0 -s 128 host 10.0.0.3 and host 10.0.0.4 -v
> tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture 
> size 128 bytes
> 15:43:50.494534 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+], 
> proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP, 
> length 52048
> 15:43:50.494541 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:43:50.560951 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:43:50.693875 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:43:50.826807 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:44:20.673863 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags 
> [none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556: 
> ip reassembly time exceeded
> 
> This is the output of receiver side:  
> [root@snf ~]# tcpdump -i ppp1 -s 128 host 10.0.0.4 and host 10.0.0.3 -v
> tcpdump: listening on ppp1, link-type LINUX_SLL (Linux cooked), capture 
> size 128 bytes
> 15:44:36.830496 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+], 
> proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP, 
> length 52048
> 15:44:36.960448 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:44:37.090411 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:44:37.220396 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:44:37.350369 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags [+], 
> proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
> 15:45:06.825912 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags 
> [none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556: 
> ip reassembly time exceeded
> 
> Thanks
> 
> 
> 
> 
> Darren Long wrote:
> 
> 
> Hiy,
> 
> 
> Whilst their may be maximum size issues associated with bundles  
> themselves, there is also the issue of IPv4 fragmentation for UDP  
> datagrams, which might also become problematic at high rates. This  
> might constrain the way you use the UDP-CL.  See:
> 
> http://www.tools.ietf.org/html/draft-mathis-frag-harmful-00
> 
> Hope this helps,
> 
> Darren
> 
> On 25 Mar 2008, at 22:20, Xuan Wu wrote:
>>>> We are running DTN over UDP. According to the manual, the limit of
>>>> datagram is 65507 bytes. So we tried to send a 60k file over DTN/UDP.
>>>> But unfortunately, the receiver can not receive this 60k file. And we
>>>> also find out that we only can successfully send and receive files  
>>>> less
>>>> than 6k. How can we send a file with maximum size?
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 27 Mar 2008 13:00:33 -0500 (CDT)
From: Xuan Wu <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] =?utf-8?q?_Re=3A__send_file_over_DTN/UDP=E2=80=8F?=
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

We used tcpdump to trace the transmission of the DTN/UDP. From the 
output of tcpdump, UDP can send files less than 65507 bytes. But the 
number of fragment sent by IP is limited. Whatever file size we send 
over UDP, the number of fragment is about 5. That is why we only can 
receive 7.1K files (each fragment is about 1500 bytes). This file size 
is really too small to continue our experiment. Is there any idea to 
send a file around the limit of 65507 bytes?
 
This is the output of sender side:  
tcpdump -i ppp0 -s 128 host 10.0.0.3 and host 10.0.0.4 -v
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture 
size 128 bytes
15:43:50.494534 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+], 
proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP, 
length 52048
15:43:50.494541 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:43:50.560951 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:43:50.693875 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:43:50.826807 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:44:20.673863 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags 
[none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556: 
ip reassembly time exceeded

This is the output of receiver side:  
[root@snf ~]# tcpdump -i ppp1 -s 128 host 10.0.0.4 and host 10.0.0.3 -v
tcpdump: listening on ppp1, link-type LINUX_SLL (Linux cooked), capture 
size 128 bytes
15:44:36.830496 IP (tos 0x0, ttl  64, id 16822, offset 0, flags [+], 
proto 17, length: 1500) tx.lamar.edu.32769 > snf.lamar.edu.4556: UDP, 
length 52048
15:44:36.960448 IP (tos 0x0, ttl  64, id 16822, offset 1480, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:44:37.090411 IP (tos 0x0, ttl  64, id 16822, offset 2960, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:44:37.220396 IP (tos 0x0, ttl  64, id 16822, offset 4440, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:44:37.350369 IP (tos 0x0, ttl  64, id 16822, offset 5920, flags [+], 
proto 17, length: 1500) tx.lamar.edu > snf.lamar.edu: udp
15:45:06.825912 IP (tos 0xc0, ttl  64, id 62850, offset 0, flags 
[none], proto 1, length: 576) snf.lamar.edu > tx.lamar.edu: icmp 556: 
ip reassembly time exceeded

Thanks

Darren Long wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hiy,
>
>
>Whilst their may be maximum size issues associated with bundles  
>themselves, there is also the issue of IPv4 fragmentation for UDP  
>datagrams, which might also become problematic at high rates. This  
>might constrain the way you use the UDP-CL.  See:
>
>http://www.tools.ietf.org/html/draft-mathis-frag-harmful-00
>
>Hope this helps,
>
>Darren
>
>On 25 Mar 2008, at 22:20, Xuan Wu wrote:
>> We are running DTN over UDP. According to the manual, the limit of
>> datagram is 65507 bytes. So we tried to send a 60k file over DTN/UDP.
>> But unfortunately, the receiver can not receive this 60k file. And we
>> also find out that we only can successfully send and receive files  
>> less
>> than 6k. How can we send a file with maximum size?
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.8 (Darwin)
>
>iEYEARECAAYFAkfplLQACgkQ6wRd4FrD5m2CYgCfVRBH3gIsf7YpPx8zttoYLzW4
>lIEAoKwe7PftD+U3VutDIrfTNtUbumCx
>=0Hg8
>-----END PGP SIGNATURE-----
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Darren Long <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Wed, 26 Mar 2008 00:11:32 +0000
Subject: Re: [dtn-interest] =?utf-8?q?send_file_over_DTN/UDP=E2=80=8F?=
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hiy,

Whilst their may be maximum size issues associated with bundles  
themselves, there is also the issue of IPv4 fragmentation for UDP  
datagrams, which might also become problematic at high rates. This  
might constrain the way you use the UDP-CL.  See:

http://www.tools.ietf.org/html/draft-mathis-frag-harmful-00

Hope this helps,

Darren

On 25 Mar 2008, at 22:20, Xuan Wu wrote:
> We are running DTN over UDP. According to the manual, the limit of
> datagram is 65507 bytes. So we tried to send a 60k file over DTN/UDP.
> But unfortunately, the receiver can not receive this 60k file. And we
> also find out that we only can successfully send and receive files  
> less
> than 6k. How can we send a file with maximum size?
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 25 Mar 2008 17:20:58 -0500 (CDT)
From: Xuan Wu <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] =?utf-8?q?send_file_over_DTN/UDP=E2=80=8F?=
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

We are running DTN over UDP. According to the manual, the limit of 
datagram is 65507 bytes. So we tried to send a 60k file over DTN/UDP. 
But unfortunately, the receiver can not receive this 60k file. And we 
also find out that we only can successfully send and receive files less 
than 6k. How can we send a file with maximum size?

From: Peter Shames <[email-masked]>
Date: Fri, 21 Mar 2008 12:38:38 -0700
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

The point of a reference implementation is to have at least one "Gold  
Standard" that is known to have implemented everything completely and  
correctly.  This doesn't mean that it is the fastest, or the smallest  
footprint, or the most efficient, or that it works in all RT  
environments, just that it is complete and correct and can be used to  
validate the smaller, faster, and possibly less complete  
implementations.

Cheers, Peter Shames

On 21 Mar 2008, at 7:46 AM, Stephen Farrell wrote:
>
>
> Peter Lovell wrote:
>> Hi Stephen,
>>
>> I was thinking that there would be a single "reference"  
>> implementation,
>> sort of a "gold standard" if you will. There will certainly be  
>> multiple
>> implementations but I wouldn't apply the term "reference  
>> implementation"
>> to those.
>
> Right, that's clear from your earlier mail. But if you read Chris'  
> note,
> you'll see that that's somewhat ambiguous, so let's talk about DTN2 if
> that's what we mean and avoid making it seem like there is, or only
> ever will be, one important implementation.
>
> S.
>
>>
>> Cheers.....Peter
>>
>>
>> On Fri, Mar 21, 2008, Stephen Farrell <[email-masked]>  
>> wrote:
>>
>>> Just a nit: talking about "the RI" assumes that there'll only
>>> be one such whereas we seem to agree that multiple implementations
>>> is a good thing. Maybe a better term is needed? (Or just start
>>> talking about DTN2.x where x > Mike's grad if that's what you
>>> mean.)
>>>
>>> S.
>>>
>>> Michael Demmer wrote:
>>>>> Hi Chris,
>>>>>
>>>>> one issue is to look at the scope of what we mean by "RI".
>>>>>
>>>>> Is it the bundle protocol, and its plug-ins such as BSP,  
>>>>> metadata and
>>>>> the like, or does it it include other things as well? Several  
>>>>> parts
>>>>> interoperate through inter-process-communication mechanisms of one
>>>>> kind
>>>>> or another and these often vary between systems.
>>>>>
>>>>> I suggest that we focus the RI on posix, which should cover  
>>>>> Linux and
>>>>> most Unix variants. It also covers a lot of Win XP but I don't  
>>>>> where
>>>>> the
>>>>> gaps are. Beyond that, we should work with interested parties  
>>>>> with the
>>>>> specialized knowledge to support RI on smaller systems. We'd make
>>>>> reasonable accommodation within RI to help that but it would be a
>>>>> "goal"
>>>>> rather than a "requirement".
>>>> I tend to agree with Peter here that a focus on standard posix  
>>>> systems
>>>> makes sense for the RI.
>>>>
>>>> However I also think that by using a portability layer like the  
>>>> Apache
>>>> Portable Runtime we can extend this applicability to include  
>>>> standard
>>>> Windows systems as well. (I'm not sure about APR and Windows mobile
>>>> however). This is the approach that I'm currently pursuing for
>>>> bleeding-edge DTN2 development...
>>>>
>>>> -mike
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

_______________________________________________________

Peter Shames
Manager - JPL Data Systems Standards Program
InterPlanetary Network Directorate
Jet Propulsion Laboratory, MS 301-230
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-0028

Internet:  [email-masked]
________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the  
first time"

                       T.S. Eliot

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Fri, 21 Mar 2008 11:07:46 -0700
Subject: [dtn-interest] applications area architecture workshop (AAAW)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hey folks.  I mentioned this at the PHL meeting-- that there was an  
applications area meeting sponsored by IETF a few weeks back.
Here are the notes from it:

http://www.ietf.org/mail-archive/web/discuss/current/msg01173.html

Note discussion of generalization of HTTP use, URIs, and email  
architecture.  I'd like to encourage discussion as to whether we
should collectivity take some sort of action or engage this group.

- K

From: "Peter Lovell" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>, "Scott Burleigh" <[email-masked]>
Date: Fri, 21 Mar 2008 13:09:26 -0400
Subject: [dtn-interest] Re(9): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Fri, Mar 21, 2008, Scott Burleigh <[email-masked]> wrote:

>Stephen Farrell wrote:
>> Just a nit: talking about "the RI" assumes that there'll only
>> be one such whereas we seem to agree that multiple implementations
>> is a good thing. Maybe a better term is needed? (Or just start
>> talking about DTN2.x where x > Mike's grad if that's what you
>> mean.)
>>   
>Except I think there's no contradiction between the existence of 
>multiple implementations and the designation of just one of them as "the 
>reference implementation".  I have always taken the term "reference 
>implementation" to mean the authoritative implementation: the community 
>agrees that it conforms strictly and comprehensively to the 
>specification, and if your implementation interoperates fully with it 
>then your implementation is compliant.

I think I detect violent agreement here :)

Date: Fri, 21 Mar 2008 16:29:07 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Friday 21/03/2008 07:44 -0700, Scott Burleigh wrote:
>Stephen Farrell wrote:
>> Just a nit: talking about "the RI" assumes that there'll only
>> be one such whereas we seem to agree that multiple implementations
>> is a good thing. Maybe a better term is needed? (Or just start
>> talking about DTN2.x where x > Mike's grad if that's what you
>> mean.)
>>   
>Except I think there's no contradiction between the existence of 
>multiple implementations and the designation of just one of them as "the 
>reference implementation".  I have always taken the term "reference 
>implementation" to mean the authoritative implementation: the community 
>agrees that it conforms strictly and comprehensively to the 
>specification, and if your implementation interoperates fully with it 
>then your implementation is compliant.

Agree with Scott. That is what a "reference implementation" is.

(Stephen, you will recall our conversation re reference implementations
in Chicago. Scott neatly conveys what I was trying to get across to you.)

L.

>By that standard, the "reference implementation" doesn't have to be 
>high-performing, it doesn't have to be the most widely used 
>implementation, it doesn't have to have pedagogical merit, it doesn't 
>have to be easy to hack for research purposes, and it doesn't have to be 
>portable at all -- interoperation happens over the wire, which is 
>platform-neutral.  So the RI could, for example, be written in Visual 
>Basic if that provided maximum simplicity and visibility and the best 
>support for assurance that the spec is comprehensively and accurately 
>implemented.  Or in something like LOTOS, I guess, if there were a good 
>compiler.  Any number of other, now-certifiably compliant 
>implementations (that might be much more widely used) could then occupy 
>all the various platform and application niches we're looking at.
>
>Scott
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

Date: Fri, 21 Mar 2008 09:18:00 -0700
To: Delay Tolerant Networking Interest List	<[email-masked]>
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future	of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Sorry  - I just got back to work and saw this thread.

The DARPA DTN Phase 2 task agreement with JPL (who in turn funded 
Mike Demmer et al at UCB) specifically called out that DTN code for 
reference implementation purposes would be public open source code. 
We therefore have been careful to keep it generic and not looking 
like anything that falls under ITAR or EAR rules.

The ION code on the other hand, since it's specifically targeted for 
spacecraft use,  does require some restrictions. We got past the ITAR 
rules by a determination of our export control people, but they still 
wanted EAR rules to be followed, hence the EAR99 business.

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

From: Rajesh Krishnan <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Organization: BBN Technologies
Date: Fri, 21 Mar 2008 11:08:31 -0400
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future	of the DTN reference implementation
Reply-To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>

I am in agreement with Scott on not overloading the RI objectives.

Something like the BSD TCP/IP stack that knocks off several of the
objectives at once will be nice, of course, but that does not happen
often.

-Rajesh

On Fri, 2008-03-21 at 07:44 -0700, Scott Burleigh wrote:
> Stephen Farrell wrote:
> > Just a nit: talking about "the RI" assumes that there'll only
> > be one such whereas we seem to agree that multiple implementations
> > is a good thing. Maybe a better term is needed? (Or just start
> > talking about DTN2.x where x > Mike's grad if that's what you
> > mean.)
> >   
> Except I think there's no contradiction between the existence of 
> multiple implementations and the designation of just one of them as "the 
> reference implementation".  I have always taken the term "reference 
> implementation" to mean the authoritative implementation: the community 
> agrees that it conforms strictly and comprehensively to the 
> specification, and if your implementation interoperates fully with it 
> then your implementation is compliant.
> 
> By that standard, the "reference implementation" doesn't have to be 
> high-performing, it doesn't have to be the most widely used 
> implementation, it doesn't have to have pedagogical merit, it doesn't 
> have to be easy to hack for research purposes, and it doesn't have to be 
> portable at all -- interoperation happens over the wire, which is 
> platform-neutral.  So the RI could, for example, be written in Visual 
> Basic if that provided maximum simplicity and visibility and the best 
> support for assurance that the spec is comprehensively and accurately 
> implemented.  Or in something like LOTOS, I guess, if there were a good 
> compiler.  Any number of other, now-certifiably compliant 
> implementations (that might be much more widely used) could then occupy 
> all the various platform and application niches we're looking at.
> 
> Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 21 Mar 2008 14:46:00 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Lovell <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Peter Lovell wrote:
> Hi Stephen,
> 
> I was thinking that there would be a single "reference" implementation,
> sort of a "gold standard" if you will. There will certainly be multiple
> implementations but I wouldn't apply the term "reference implementation"
> to those. 

Right, that's clear from your earlier mail. But if you read Chris' note,
you'll see that that's somewhat ambiguous, so let's talk about DTN2 if
that's what we mean and avoid making it seem like there is, or only
ever will be, one important implementation.

S.

> 
> Cheers.....Peter
> 
> 
> On Fri, Mar 21, 2008, Stephen Farrell <[email-masked]> wrote:
> 
>> Just a nit: talking about "the RI" assumes that there'll only
>> be one such whereas we seem to agree that multiple implementations
>> is a good thing. Maybe a better term is needed? (Or just start
>> talking about DTN2.x where x > Mike's grad if that's what you
>> mean.)
>>
>> S.
>>
>> Michael Demmer wrote:
>>>> Hi Chris,
>>>>
>>>> one issue is to look at the scope of what we mean by "RI".
>>>>
>>>> Is it the bundle protocol, and its plug-ins such as BSP, metadata and
>>>> the like, or does it it include other things as well? Several parts
>>>> interoperate through inter-process-communication mechanisms of one  
>>>> kind
>>>> or another and these often vary between systems.
>>>>
>>>> I suggest that we focus the RI on posix, which should cover Linux and
>>>> most Unix variants. It also covers a lot of Win XP but I don't where  
>>>> the
>>>> gaps are. Beyond that, we should work with interested parties with the
>>>> specialized knowledge to support RI on smaller systems. We'd make
>>>> reasonable accommodation within RI to help that but it would be a  
>>>> "goal"
>>>> rather than a "requirement".
>>> I tend to agree with Peter here that a focus on standard posix systems  
>>> makes sense for the RI.
>>>
>>> However I also think that by using a portability layer like the Apache  
>>> Portable Runtime we can extend this applicability to include standard  
>>> Windows systems as well. (I'm not sure about APR and Windows mobile  
>>> however). This is the approach that I'm currently pursuing for  
>>> bleeding-edge DTN2 development...
>>>
>>> -mike
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 
> 

Date: Fri, 21 Mar 2008 07:44:43 -0700
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Stephen Farrell wrote:
> Just a nit: talking about "the RI" assumes that there'll only
> be one such whereas we seem to agree that multiple implementations
> is a good thing. Maybe a better term is needed? (Or just start
> talking about DTN2.x where x > Mike's grad if that's what you
> mean.)
>   
Except I think there's no contradiction between the existence of 
multiple implementations and the designation of just one of them as "the 
reference implementation".  I have always taken the term "reference 
implementation" to mean the authoritative implementation: the community 
agrees that it conforms strictly and comprehensively to the 
specification, and if your implementation interoperates fully with it 
then your implementation is compliant.

By that standard, the "reference implementation" doesn't have to be 
high-performing, it doesn't have to be the most widely used 
implementation, it doesn't have to have pedagogical merit, it doesn't 
have to be easy to hack for research purposes, and it doesn't have to be 
portable at all -- interoperation happens over the wire, which is 
platform-neutral.  So the RI could, for example, be written in Visual 
Basic if that provided maximum simplicity and visibility and the best 
support for assurance that the spec is comprehensively and accurately 
implemented.  Or in something like LOTOS, I guess, if there were a good 
compiler.  Any number of other, now-certifiably compliant 
implementations (that might be much more widely used) could then occupy 
all the various platform and application niches we're looking at.

Scott

From: "Peter Lovell" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Date: Fri, 21 Mar 2008 10:29:08 -0400
Subject: [dtn-interest] Re(2): Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi Stephen,

I was thinking that there would be a single "reference" implementation,
sort of a "gold standard" if you will. There will certainly be multiple
implementations but I wouldn't apply the term "reference implementation"
to those. 

Cheers.....Peter

On Fri, Mar 21, 2008, Stephen Farrell <[email-masked]> wrote:

>
>Just a nit: talking about "the RI" assumes that there'll only
>be one such whereas we seem to agree that multiple implementations
>is a good thing. Maybe a better term is needed? (Or just start
>talking about DTN2.x where x > Mike's grad if that's what you
>mean.)
>
>S.
>
>Michael Demmer wrote:
>>> Hi Chris,
>>>
>>> one issue is to look at the scope of what we mean by "RI".
>>>
>>> Is it the bundle protocol, and its plug-ins such as BSP, metadata and
>>> the like, or does it it include other things as well? Several parts
>>> interoperate through inter-process-communication mechanisms of one  
>>> kind
>>> or another and these often vary between systems.
>>>
>>> I suggest that we focus the RI on posix, which should cover Linux and
>>> most Unix variants. It also covers a lot of Win XP but I don't where  
>>> the
>>> gaps are. Beyond that, we should work with interested parties with the
>>> specialized knowledge to support RI on smaller systems. We'd make
>>> reasonable accommodation within RI to help that but it would be a  
>>> "goal"
>>> rather than a "requirement".
>> 
>> I tend to agree with Peter here that a focus on standard posix systems  
>> makes sense for the RI.
>> 
>> However I also think that by using a portability layer like the Apache  
>> Portable Runtime we can extend this applicability to include standard  
>> Windows systems as well. (I'm not sure about APR and Windows mobile  
>> however). This is the approach that I'm currently pursuing for  
>> bleeding-edge DTN2 development...
>> 
>> -mike
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 21 Mar 2008 13:22:50 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Just a nit: talking about "the RI" assumes that there'll only
be one such whereas we seem to agree that multiple implementations
is a good thing. Maybe a better term is needed? (Or just start
talking about DTN2.x where x > Mike's grad if that's what you
mean.)

S.

Michael Demmer wrote:
>> Hi Chris,
>>
>> one issue is to look at the scope of what we mean by "RI".
>>
>> Is it the bundle protocol, and its plug-ins such as BSP, metadata and
>> the like, or does it it include other things as well? Several parts
>> interoperate through inter-process-communication mechanisms of one  
>> kind
>> or another and these often vary between systems.
>>
>> I suggest that we focus the RI on posix, which should cover Linux and
>> most Unix variants. It also covers a lot of Win XP but I don't where  
>> the
>> gaps are. Beyond that, we should work with interested parties with the
>> specialized knowledge to support RI on smaller systems. We'd make
>> reasonable accommodation within RI to help that but it would be a  
>> "goal"
>> rather than a "requirement".
> 
> I tend to agree with Peter here that a focus on standard posix systems  
> makes sense for the RI.
> 
> However I also think that by using a portability layer like the Apache  
> Portable Runtime we can extend this applicability to include standard  
> Windows systems as well. (I'm not sure about APR and Windows mobile  
> however). This is the approach that I'm currently pursuing for  
> bleeding-edge DTN2 development...
> 
> -mike
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Michael Demmer <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 20 Mar 2008 16:14:35 -0700
Subject: Re: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

> Hi Chris,
>
> one issue is to look at the scope of what we mean by "RI".
>
> Is it the bundle protocol, and its plug-ins such as BSP, metadata and
> the like, or does it it include other things as well? Several parts
> interoperate through inter-process-communication mechanisms of one  
> kind
> or another and these often vary between systems.
>
> I suggest that we focus the RI on posix, which should cover Linux and
> most Unix variants. It also covers a lot of Win XP but I don't where  
> the
> gaps are. Beyond that, we should work with interested parties with the
> specialized knowledge to support RI on smaller systems. We'd make
> reasonable accommodation within RI to help that but it would be a  
> "goal"
> rather than a "requirement".

I tend to agree with Peter here that a focus on standard posix systems  
makes sense for the RI.

However I also think that by using a portability layer like the Apache  
Portable Runtime we can extend this applicability to include standard  
Windows systems as well. (I'm not sure about APR and Windows mobile  
however). This is the approach that I'm currently pursuing for  
bleeding-edge DTN2 development...

-mike

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>, "Christopher Small" <[email-masked]>
Date: Thu, 20 Mar 2008 18:37:05 -0400
Subject: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Thu, Mar 20, 2008, Christopher Small <[email-masked]> wrote:

>One thing I forgot to bring up during the discussion is what platform(s) 
>people think should be supported by the RI. Is Posix support sufficient? 
>Or do people want to be able to run the reference implementation on 
>small devices running Symbian, Windows ME, or Android? Or on top of the 
>standard Windows API?
>
>My understanding is that some of the alternate implementations have been 
>constructed in part to be able to run a BP on non-Posix machines (e.g. 
>Joerg Ott's Symbian-based implementation; Georgia Tech's C# 
>implementation).
>

Hi Chris,

one issue is to look at the scope of what we mean by "RI". 

Is it the bundle protocol, and its plug-ins such as BSP, metadata and
the like, or does it it include other things as well? Several parts
interoperate through inter-process-communication mechanisms of one kind
or another and these often vary between systems.

I suggest that we focus the RI on posix, which should cover Linux and
most Unix variants. It also covers a lot of Win XP but I don't where the
gaps are. Beyond that, we should work with interested parties with the
specialized knowledge to support RI on smaller systems. We'd make
reasonable accommodation within RI to help that but it would be a "goal"
rather than a "requirement".

Cheers.....Peter

Content-class: urn:content-classes:message
Date: Thu, 20 Mar 2008 11:28:07 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] interop report
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C88AA7.60F95CE3
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Thanks.
=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: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
	Sent: Thursday, March 20, 2008 11:30 AM
	To: Delay Tolerant Networking Interest List
	Subject: Re: [dtn-interest] interop report
=09
=09
	Ivancic, William D. (GRC-RCN0) wrote:=20

			Testing of Licklider Transmission
Protocol.....the two LTP engines exchanged LTP blocks of "red" sizes up
to 130 KB without observed error.
			   =20

		Scott,
	=09
		Was the ONE emulator in line (or some other link
emulator)?
	=09
		If so, what were the settings for BER and Delay?
		 =20

	No, we were working on basic interoperability this time, not any
kind of high-fidelity performance testing.
=09

		Also, what size where the bundles?
		 =20

	This was pure LTP interoperation, not BP over LTP, so there were
no bundles.  The LTP blocks that were being exchanged (which would
contain bundles in a BP/LTP configuration) ranged in size from something
like 50 bytes to 130 KB.  Again, though, we were just trying to
establish basic interoperation, not looking for performance limits.
=09
	Scott
=09

------_=_NextPart_001_01C88AA7.60F95CE3
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.16608" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D140332216-20032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D140332216-20032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D140332216-20032008><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> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Scott=20
  Burleigh<BR><B>Sent:</B> Thursday, March 20, 2008 11:30 =
AM<BR><B>To:</B> Delay=20
  Tolerant Networking Interest List<BR><B>Subject:</B> Re: =
[dtn-interest]=20
  interop report<BR></FONT><BR></DIV>
  <DIV></DIV>Ivancic, William D. (GRC-RCN0) wrote:=20
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
=20
  type=3D"cite">
    <BLOCKQUOTE type=3D"cite"><PRE wrap=3D""><!---->Testing of Licklider =
Transmission Protocol.....the two LTP engines exchanged LTP blocks of =
"red" sizes up to 130 KB without observed error.
    </PRE></BLOCKQUOTE><PRE wrap=3D"">Scott,

Was the ONE emulator in line (or some other link emulator)?

If so, what were the settings for BER and Delay?
  </PRE></BLOCKQUOTE>No, we were working on basic interoperability this =
time,=20
  not any kind of high-fidelity performance testing.<BR>
  <BLOCKQUOTE=20
  =
cite=3Dmid:[email-masked]=
=20
  type=3D"cite"><PRE wrap=3D"">Also, what size where the bundles?
  </PRE></BLOCKQUOTE>This was pure LTP interoperation, not BP over LTP, =
so=20
  there were no bundles.&nbsp; The LTP blocks that were being exchanged =
(which=20
  would contain bundles in a BP/LTP configuration) ranged in size from =
something=20
  like 50 bytes to 130 KB.&nbsp; Again, though, we were just trying to =
establish=20
  basic interoperation, not looking for performance=20
limits.<BR><BR>Scott<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C88AA7.60F95CE3--

From: "Jason Redi" <[email-masked]>
To: "'Delay Tolerant Networking Interest List'" <[email-masked]>
Date: Thu, 20 Mar 2008 12:02:32 -0400
Organization: BBN Technologies
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTN	reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

All,
If you are looking for adoption within small routers or information
appliance devices, you might want to consider RI support for an RTOS such as
VxWorks, Integrity, ThreadX, or even GNU FreeRTOS.  

While the actual development licenses for some of those RTOSes can be quite
high, at least considering the limitations/features of the RTOSes may be
valuable in making the RI of wider interest.

Jason 

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of Christopher Small
> Sent: Thursday, March 20, 2008 9:21 AM
> To: Delay Tolerant Networking Interest List
> Subject: Re: [dtn-interest] notes from IETF discussion on the future of
> the DTN reference implementation
> 
> One thing I forgot to bring up during the discussion is what
> platform(s)
> people think should be supported by the RI. Is Posix support
> sufficient?
> Or do people want to be able to run the reference implementation on
> small devices running Symbian, Windows ME, or Android? Or on top of the
> standard Windows API?
> 
> My understanding is that some of the alternate implementations have
> been
> constructed in part to be able to run a BP on non-Posix machines (e.g.
> Joerg Ott's Symbian-based implementation; Georgia Tech's C#
> implementation).
> 
> - Chris
> 
> --
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 20 Mar 2008 15:45:45 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] interop report
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Scott Burleigh wrote:
> Ivancic, William D. (GRC-RCN0) wrote:
>>> Testing of Licklider Transmission Protocol.....the two LTP engines exchanged LTP blocks of "red" sizes up to 130 KB without observed error.
>>>     
>> Scott,
>>
>> Was the ONE emulator in line (or some other link emulator)?
>>
>> If so, what were the settings for BER and Delay?
>>   
> No, we were working on basic interoperability this time, not any kind of 
> high-fidelity performance testing.
>> Also, what size where the bundles?
>>   
> This was pure LTP interoperation, not BP over LTP, so there were no 
> bundles.  The LTP blocks that were being exchanged (which would contain 
> bundles in a BP/LTP configuration) ranged in size from something like 50 
> bytes to 130 KB.  Again, though, we were just trying to establish basic 
> interoperation, not looking for performance limits.

Actually, some of 'em were encoded bundles that Mike sent me, but they
didn't get passed up to that layer of Scott's code. I just treated the
encoded bundles as files, so also didn't do any BP.

S.

Date: Thu, 20 Mar 2008 08:29:59 -0700
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] interop report
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

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

Ivancic, William D. (GRC-RCN0) wrote:
>> Testing of Licklider Transmission Protocol.....the two LTP engines exchanged LTP blocks of "red" sizes up to 130 KB without observed error.
>>     
> Scott,
>
> Was the ONE emulator in line (or some other link emulator)?
>
> If so, what were the settings for BER and Delay?
>   
No, we were working on basic interoperability this time, not any kind of 
high-fidelity performance testing.
> Also, what size where the bundles?
>   
This was pure LTP interoperation, not BP over LTP, so there were no 
bundles.  The LTP blocks that were being exchanged (which would contain 
bundles in a BP/LTP configuration) ranged in size from something like 50 
bytes to 130 KB.  Again, though, we were just trying to establish basic 
interoperation, not looking for performance limits.

Scott

--------------030805030000050504090906
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">
Ivancic, William D. (GRC-RCN0) wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap=""><!---->Testing of Licklider Transmission Protocol.....the two LTP engines exchanged LTP blocks of "red" sizes up to 130 KB without observed error.
    </pre>
  </blockquote>
  <pre wrap="">Scott,

Was the ONE emulator in line (or some other link emulator)?

If so, what were the settings for BER and Delay?
  </pre>
</blockquote>
No, we were working on basic interoperability this time, not any kind
of high-fidelity performance testing.<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">Also, what size where the bundles?
  </pre>
</blockquote>
This was pure LTP interoperation, not BP over LTP, so there were no
bundles.&nbsp; The LTP blocks that were being exchanged (which would contain
bundles in a BP/LTP configuration) ranged in size from something like
50 bytes to 130 KB.&nbsp; Again, though, we were just trying to establish
basic interoperation, not looking for performance limits.<br>
<br>
Scott<br>
</body>
</html>

--------------030805030000050504090906--

Content-class: urn:content-classes:message
Date: Thu, 20 Mar 2008 09:27:46 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] interop report
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

> Testing of Licklider Transmission Protocol.....the two LTP engines
exchanged LTP blocks of "red" 
> sizes up to 130 KB without observed error.
> 
> Scott

Scott,

Was the ONE emulator in line (or some other link emulator)?

If so, what were the settings for BER and Delay?

Also, what size where the bundles?

Will

Date: Thu, 20 Mar 2008 14:15:17 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Draft minutes from last week's meeting...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

...posted now. [1] Let me know if any changes are
needed,
Cheers,
S.

[1] http://www.ietf.org/proceedings/08mar/minutes/DTNRG.html

Date: Thu, 20 Mar 2008 09:20:30 -0400
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTN	reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

One thing I forgot to bring up during the discussion is what platform(s) 
people think should be supported by the RI. Is Posix support sufficient? 
Or do people want to be able to run the reference implementation on 
small devices running Symbian, Windows ME, or Android? Or on top of the 
standard Windows API?

My understanding is that some of the alternate implementations have been 
constructed in part to be able to run a BP on non-Posix machines (e.g. 
Joerg Ott's Symbian-based implementation; Georgia Tech's C# 
implementation).

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Date: Wed, 19 Mar 2008 17:07:43 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] interop report
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi.  Here's a report on the interoperability testing we did last week, 
March 13-14, in the terminal room at IETF 71 (Philadelphia, USA, 2008).

The IETF 71 interop was our second DTN interoperability testing session, 
and it was much more modest that the first (held in November of 2006): 
only three implementations of Bundle Protocol were tested, plus two 
implementation of LTP, and we had a total of only about 8 hours of 
activity.  Still, we made some useful progress.

One new Bundle Protocol option was tested: Compressed Bundle Header 
Encoding (CBHE) was added to the DTN2 reference implementation.  This 
enabled a DTN2 node on Mike Demmer's OS/X laptop and an "ION" node on 
Scott Burleigh's Linux laptop to exchange bundles whose source and 
destination EIDs were represented in the CBHE-compressible "ipn" scheme 
rather than the normal "dtn" scheme; non-custodial bundles were 
successfully passed in both directions.  Bundles addressed in the "dtn" 
scheme were also successfully exchanged in both directions; a custodial 
"dtn"-scheme bundle passed from the DTN2 node to the ION node was 
received successfully, but the source EID in the responding custody 
acceptance bundle was ill-formed (missing the "//" characters at the 
start of the SSP) due to an ION bug.

Additionally, bundles were successfully exchanged in both directions 
between a DTN2 implementation on Joerg Ott's laptop and a node on his 
Symbian mobile phone.  Joerg's and Mike's nodes also exchanged bundles, 
but neither could interoperate with the ION node without modification 
because the ION node expected version-6 traffic (as in RFC5050) and DTN2 
was still using 5 as the version number.

Interoperability of the DTN reference implementation with
a simulation environment (the ONE simulator) via the external
convergence layer interface implemented was also tested.  Bundles 
generated by DTN applications can be passed to and from dtnd instances 
attached to the ONE.  A small chain of DTN nodes was constructed 
involving the Symbian implementation as the sender, one Nokia Internet 
tablet running the reference implementation as the first intermediate 
node which then connected to the ONE simulator with two stationary and
three mobile nodes through which messages were tunneled via two dtnds
connected to the stationary nodes via the external convergence layer.

Testing of Licklider Transmission Protocol implementations differed from 
the November 2006 session in that, while Stephen Farrell's 
implementation (in C++) was again exercised, a new LTP implementation 
included in JPL's ION stack replaced the Ohio University implementation. 
  Differing conventions for selecting LTP engine numbers and client 
service numbers in the ION implementation, together with differing 
methods for selecting UDP port numbers at the underlying transport 
layer, made some adjustments necessary in both code bases.  Once these 
adjustments had been made, however, the two LTP engines exchanged LTP 
blocks of "red" sizes up to 130 KB without observed error.

Scott

From: Rajesh Krishnan <[email-masked]>
To: Dan <[email-masked]>
Date: Wed, 19 Mar 2008 16:40:09 -0400
Cc: [email-masked]
Subject: [dtn-interest] clean-slate or not -- citation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Dan,

Apologies for not including a citation in my original post, Cc:ing
dtn-interest.  Here it is:

Constantine Dovrolis, "What would Darwin Think about Clean-Slate
Architectures?," ACM SIGCOMM CCR, Volume 38, Number 1, Jan 2008.

Best Regards,
Rajesh

P.S.:  I was secretly hoping someone would ask; thanks Dan. :)

> Hi Rajesh,
>  
> I'm not familiar with the Dovrolis paper you reference.  Could you
> provide me with a cite?
>  
> Thanks,
> Dan
> 
>  
> On 3/11/08, Rajesh Krishnan <[email-masked]> wrote: 
>         Disclaimer: these are my personal views, not of my project,
>         employer, or funding agency.
>         
>         Lloyd,
>         
>         Thanks for the briefing in advance, especially since I will
>         not be there in Philly.
>         
>         An interesting proposal, but could you explain to me the
>         primary purpose
>         and motivating requirement for HTTP-DTN please.   I want to
>         hear from you
>         about both upsides and downsides to adopting HTTP-DTN.
>         
>         Some questions/provocations that will aid me in better
>         understanding the motivation:
>         
>         * Would the IETF EDIINT RFCs/I-Ds already cover your
>         requirements for HTTP-DTN?
>         Or is EDIINT too specialized a domain?
>         
>         * It appears folks are already doing similar things with
>         HTTP/SOAP in the agent
>         middleware world (e.g., www.cougaar.org)? They even seem to
>         support a number of
>         other messaging application protocols.  Would those solutions
>         satisfy
>         your current requirements that motivate HTTP-DTN, or do you
>         see a real
>         need for a DTNRG specification in this area?  Such a need to
>         me suggests
>         potential killer apps lurking for DTN, and I would sure like
>         to hear of them.
>         
>         * Why not write a HTTP-CLA instead?  Why should DTN
>         necessarily sit on top
>         of the transport layer or any other specific layer for that
>         matter?  As
>         long as a suitable CLA is available, why not just do DTN over
>         it?  Would
>         a HTTP/SOAP-CLA not achieve your goal?
>         
>         * Seems one can define a SMTP-DTN using the X-* headers
>         too.  Why fragment
>         the DTN world into BP-DTN, HTTP-DTN, SMTP-DTN, ...?  I doubt
>         that we
>         will have a better/faster Internet if IP-datagram alternatives
>         were
>         ubiquitous.
>         
>         * HTTP is associated with a client-server model of the world,
>         while DTN seems to try to move to a distributed,
>         content-oriented
>         world that may frequently not admit contemporaneous end-to-end
>         paths.
>         While HTTP itself can be torqued to such a distributed model,
>         and you show
>         one way to do it, the whole software infrastructure, tools,
>         and mindset
>         surrounding the HTTP world will be from the client-server,
>         end-to-end stable path
>         view of the world.  Will HTTP-DTN fragment the web world into
>         two halves
>         requiring different mindsets and tool chains to do HTTP?   You
>         can tell
>         me this is a red herring, and I won't mind. :)
>         
>         * Why should HTTP be perpetuated as the new waist, why can't
>         another new waist
>         emerge over time (and make HTTP pay for snatching that
>         position from IP :) ?
>         
>         I want to take a general long-term networking research
>         standpoint and currently
>         do not have commercial product experience/pressures.  I can
>         imagine packet switching
>         that is not based on IP (I may get voted off the island for
>         saying this :), and I
>         can imagine content networking not based on HTTP/SOAP/XML.  I
>         have a rather romantic
>         notion of the BP evolving and supporting a clean-slate (yes I
>         have read Dovrolis'
>         paper :) future Internet.  That is, with the BP being the
>         slate that the new design
>         is written on.  I am being naive and unreasonable perhaps.
>         
>         Schemas/Ontologies to populate the metadata extension block
>         (to support content
>         networking), fast BP forwarders, and policy-based control of
>         content networking
>         are some interesting research topics in this space.  I would
>         like this RG move
>         up the value chain, and not get stuck in low-level protocol
>         encapsulation and
>         message formatting issues.  (A shared encapsulation for DTN
>         helps build critical mass
>         in the research community,  and future versions can fix
>         shortcomings as needed and
>         experience is gained, but a second encapsulation provides
>         diminishing research
>         returns. I understand there may be other pragmatic
>         considerations though.)
>         
>         So, from where I stand, I see that the BP-DTN buys me a
>         more-or-less clean slate
>         without much baggage since I am not interested in the
>         encapsulation per se.  Who
>         is to say some good ideas from DTNRG can't eventually make
>         their way back and get
>         retrofitted into incumbent Internet technologies including
>         HTTP, but I worry if
>         it may be premature to force the DTNRG down that path.  Again,
>         just speaking for
>         myself.
>         
>         For some of my other thoughts on DTN, see for example:
>         http://advika.net/rkrishnan/talks/rkrishnan-coin-neu07.ppt
>         
>         With apologies for sending a long email and including
>         shameless plugs.  ;)
>         
>         Best Regards,
>         Rajesh
>         
>         P.S.:  I will disengage promptly and run away if anyone flames
>         me, for I have
>         lots of other non-flaming dragons to slay.  :)
>         
>         
>         
>         > Finally, the slides I've prepared presenting the HTTP-DTN
>         concept are at:
>         >
>         http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf
>         >
>         > cheers,
>         >
>         > L.
>         >
>         > Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>         
>         _______________________________________________
>         dtn-interest mailing list
>         [email-masked]
>         http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Date: Tue, 18 Mar 2008 17:36:19 -0400
Subject: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Tue, Mar 18, 2008, Stephen Farrell <[email-masked]> wrote:

> ... sorted all this out via crypto export 
>battles that started over a decade ago now.

Hhmmm. I don't think that I would describe what 
we now have as being "sorted out".

Back then you knew what the answer was. 
It was usually "no", but not always.

These days it seems to be hard to get a 
clear answer regarding ITAR. 

Cheers.....Peter

Date: Tue, 18 Mar 2008 20:35:55 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Pedantic note included below:

Hans Kruse wrote:
> The US 
> export rules apply equally to everyone, 

Nope. Different rules apply in different countries.

But seriously, since DTN2 is already out there, there's very
little liklihood that someone would pay to bring it back under
US or other export controls. At least, I hope no-one would want
money that came with that string attached.

The ION case is understandably different, due to the differences
in interpretation of ITAR between the aerospace and general
computing communities - the latter sorted all this out via crypto
export battles that started over a decade ago now.

Cheers,
S.

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>, "Christopher Small" <[email-masked]>, "Hans Kruse" <[email-masked]>
Date: Tue, 18 Mar 2008 16:34:37 -0400
Subject: [dtn-interest] Re(2): notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Tue, Mar 18, 2008, Christopher Small <[email-masked]> wrote:

>> Chris, since DTN2 is currently DARPA funded, how did you avoid getting 
>> snagged in export issues?
>First, DTN2 development has been funded by a number of sources including 
>by volunteers, DARPA, and Mike's graduate funding (which, I believe, has 
>come in part from Intel). The lion's share of the code was written by Mike.
>
>Second, DARPA has not hard-and-fast rule about export control or closed 
>vs. open source development. They have been very supportive of our 
>working on an open source code base, and our project is not the only one 
>for which this is the case.

I think it's also worth noting that DARPA did review the code and
approve it for public release. That was especially the case for the
security code.

Regards.....Peter

Date: Tue, 18 Mar 2008 16:22:44 -0400
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hans Kruse wrote:
> See in-line ...
>
> On Mar 18, 2008, at 3:00 PM, Christopher Small wrote:
>> Second, DARPA has not hard-and-fast rule about export control or closed
>> vs. open source development. They have been very supportive of our
>> working on an open source code base, and our project is not the only one
>> for which this is the case.
> Interesting.  Maybe I need to rephrase the question.  I know our NASA 
> grant under which we distribute ION requires that we follow JPL rules 
> for handling the software.  JPL in turn uses an internal process that 
> assigns a Dept of Commerce (_not_ ITAR) export classification number. 
>   While Jim is correct that the process is onerous, it does very 
> limited filtering in practice since the EAR-99 designation only 
> restricts a very, very small number of destinations.  
>
> The point is that these are all self-assigned procedures.   The US 
> export rules apply equally to everyone, JPL and BBN alike.  So 
> presumably BBN has made the determination that even the limited export 
> control that JPL wants to enforce is not required.  So in our effort 
> to find a home for DTN2 do we need to make sure the host/sponsor is 
> comfortable making that same determination?
OK, I understand your question now.

(One clarification: where I wrote "DARPA has not hard-and-fast rule 
about export control" I did not mean to imply that DARPA doesn't follow 
export rules, nor that it has exempted us from export rules. What I 
meant was that DARPA doesn't require that all code written under a DARPA 
contract be automatically restricted to domestic use -- or closed source.)

And back to your question: I cannot speak with authority and in detail 
on the procedures that BBN and DARPA are following; it's not my area of 
expertise. I can tell you that we submit any new code or documents we 
write for review before they are released to the public. One difference 
between ION and DTN2 is that the DTN2 code base existed before we 
started to work on it; I assume ION was started on the government's nickel.

If you are interested in learning about the processes that we follow, 
and the rationale behind them, you and I can dig into them.  My belief, 
based on what I know about the process and the attention that is paid to 
it by those in the know, is that we are following the rules. (Which 
rules, and how we are following them, is the part I'm fuzzy on.)

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Tue, 18 Mar 2008 16:03:55 -0400
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

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

See in-line ...

On Mar 18, 2008, at 3:00 PM, Christopher Small wrote:

> Hans Kruse wrote:
>> Lets see if we can explore other funding models/options.  Many will
>> come at a price, e.g. if we use a membership model there will be  
>> those
>> with (better) access and those with no (or lesser) access.
> The membership model isn't a great one for fostering community
> development. Consider how well OSF did, and compare it to an open and
> free development supported by volunteers (e.g. the Linux kernel).
> Speaking for myself only, I think that going with a membership model
> could easily mean the death of DTN2.

Just to make sure, I was not advocating that particular model, just  
using it as an example of "strings" that might come along with a  
particular approach.  Based on the conversations on Thursday (which  
you captured quite well, thanks!), I agree that an Open Source model  
is likely the most desirable approach.   Many successful projects are  
directly or indirectly "sponsored" either through direct monetary  
donations or by allowing personnel funded through other sources to  
spend time on the Open Source development.  We need to explore these  
options.

>
>> Chris, since DTN2 is currently DARPA funded, how did you avoid  
>> getting
>> snagged in export issues?
> First, DTN2 development has been funded by a number of sources  
> including
> by volunteers, DARPA, and Mike's graduate funding (which, I believe,  
> has
> come in part from Intel). The lion's share of the code was written  
> by Mike.
>
> Second, DARPA has not hard-and-fast rule about export control or  
> closed
> vs. open source development. They have been very supportive of our
> working on an open source code base, and our project is not the only  
> one
> for which this is the case.

Interesting.  Maybe I need to rephrase the question.  I know our NASA  
grant under which we distribute ION requires that we follow JPL rules  
for handling the software.  JPL in turn uses an internal process that  
assigns a Dept of Commerce (_not_ ITAR) export classification  
number.   While Jim is correct that the process is onerous, it does  
very limited filtering in practice since the EAR-99 designation only  
restricts a very, very small number of destinations.

The point is that these are all self-assigned procedures.   The US  
export rules apply equally to everyone, JPL and BBN alike.  So  
presumably BBN has made the determination that even the limited export  
control that JPL wants to enforce is not required.  So in our effort  
to find a home for DTN2 do we need to make sure the host/sponsor is  
comfortable making that same determination?

>
>
> - Chris
>
> -- 
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-1--69830809
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">See in-line =
...<div><br><div><html>On Mar 18, 2008, at 3:00 PM, Christopher Small =
wrote:</html><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Hans Kruse wrote:<br><blockquote type=3D"cite">Lets see if =
we can explore other funding models/options. &nbsp;Many will =
<br></blockquote><blockquote type=3D"cite">come at a price, e.g. if we =
use a membership model there will be those <br></blockquote><blockquote =
type=3D"cite">with (better) access and those with no (or lesser) =
access.<br></blockquote>The membership model isn't a great one for =
fostering community <br>development. Consider how well OSF did, and =
compare it to an open and <br>free development supported by volunteers =
(e.g. the Linux kernel). <br>Speaking for myself only, I think that =
going with a membership model <br>could easily mean the death of =
DTN2.</blockquote><div><br></div>Just to make sure, I was not advocating =
that particular model, just using it as an example of "strings" that =
might come along with a particular approach. &nbsp;Based on the =
conversations on Thursday (which you captured quite well, thanks!), I =
agree that an Open Source model is likely the most desirable approach. =
&nbsp; Many successful projects are directly or indirectly "sponsored" =
either through direct monetary donations or by allowing personnel funded =
through other sources to spend time on the Open Source development. =
&nbsp;We need to explore these options.</div><div><br><blockquote =
type=3D"cite"><br><blockquote type=3D"cite">Chris, since DTN2 is =
currently DARPA funded, how did you avoid getting =
<br></blockquote><blockquote type=3D"cite">snagged in export =
issues?<br></blockquote>First, DTN2 development has been funded by a =
number of sources including <br>by volunteers, DARPA, and Mike's =
graduate funding (which, I believe, has <br>come in part from Intel). =
The lion's share of the code was written by Mike.<br><br>Second, DARPA =
has not hard-and-fast rule about export control or closed <br>vs. open =
source development. They have been very supportive of our <br>working on =
an open source code base, and our project is not the only one <br>for =
which this is the case.</blockquote><div><br></div>Interesting. =
&nbsp;Maybe I need to rephrase the question. &nbsp;I know our NASA grant =
under which we distribute ION requires that we follow JPL rules for =
handling the software. &nbsp;JPL in turn uses an internal process that =
assigns a Dept of Commerce (_not_ ITAR) export classification number. =
&nbsp; While Jim is correct that the process is onerous, it does very =
limited filtering in practice since the EAR-99 designation only =
restricts a very, very small number of destinations. =
&nbsp;</div><div><br></div><div>The point is that these are all =
self-assigned procedures. &nbsp; The US export rules apply equally to =
everyone, JPL and BBN alike. &nbsp;So presumably BBN has made the =
determination that even the limited export control that JPL wants to =
enforce is not required. &nbsp;So in our effort to find a home for DTN2 =
do we need to make sure the host/sponsor is comfortable making that same =
determination?</div><div><br></div><div><br><blockquote =
type=3D"cite"><br><br>- Chris<br><br>-- <br>Dr. Christopher Small =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;617.=
873.6261 (vox)<br>Networking Research =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;617.873.6091 (fax)<br>BBN Technologies | MS 6/5C | 10 Moulton St =
| Cambridge MA, =
02138<br><br>_______________________________________________<br>dtn-intere=
st mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br>http://maillists.intel-research.net/mailman/listinfo/dtn-intere=
st<br></blockquote></div><br><div> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-1--69830809--

Date: Tue, 18 Mar 2008 15:00:34 -0400
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hans Kruse wrote:
> Lets see if we can explore other funding models/options.  Many will 
> come at a price, e.g. if we use a membership model there will be those 
> with (better) access and those with no (or lesser) access.
The membership model isn't a great one for fostering community 
development. Consider how well OSF did, and compare it to an open and 
free development supported by volunteers (e.g. the Linux kernel). 
Speaking for myself only, I think that going with a membership model 
could easily mean the death of DTN2.
> Chris, since DTN2 is currently DARPA funded, how did you avoid getting 
> snagged in export issues?
First, DTN2 development has been funded by a number of sources including 
by volunteers, DARPA, and Mike's graduate funding (which, I believe, has 
come in part from Intel). The lion's share of the code was written by Mike.

Second, DARPA has not hard-and-fast rule about export control or closed 
vs. open source development. They have been very supportive of our 
working on an open source code base, and our project is not the only one 
for which this is the case.

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Tue, 18 Mar 2008 14:31:51 -0400
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

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

Lets see if we can explore other funding models/options.  Many will  
come at a price, e.g. if we use a membership model there will be those  
with (better) access and those with no (or lesser) access.

Chris, since DTN2 is currently DARPA funded, how did you avoid getting  
snagged in export issues?

On Mar 18, 2008, at 1:15 PM, Ivancic, William D. (GRC-RCN0) wrote:

> NASA has funded Ohio University in the past to maintain code like the
> ION code.  My ability to obtain funding for DTN is pretty poor lately.
> In addition, government funding may come at a cost - ITAR related
> garbage that make code release painful and places unnecessary  
> hurdles in
> place.  So, although I see a usefulness in having a reference model,
> that is reasonably well maintained and documented, I also agree with
> Stephen Farrell.   It would be nice to have both, a well maintained
> reference model and links to other implementations.
>
>
> Will

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-2--75354897
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Lets see if we can explore =
other funding models/options. &nbsp;Many will come at a price, e.g. if =
we use a membership model there will be those with (better) access and =
those with no (or lesser) access.<div><br =
class=3D"webkit-block-placeholder"></div><div>Chris, since DTN2 is =
currently DARPA funded, how did you avoid getting snagged in export =
issues?</div><div><br =
class=3D"webkit-block-placeholder"></div><div><br><div><div>On Mar 18, =
2008, at 1:15 PM, Ivancic, William D. (GRC-RCN0) wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; ">NASA has funded Ohio University in =
the past to maintain code like the<br>ION code. &nbsp;My ability to =
obtain funding for DTN is pretty poor lately.<br>In addition, government =
funding may come at a cost - ITAR related<br>garbage that make code =
release painful and places unnecessary hurdles in<br>place. &nbsp;So, =
although I see a usefulness in having a reference model,<br>that is =
reasonably well maintained and documented, I also agree with<br>Stephen =
Farrell. &nbsp;&nbsp;It would be nice to have both, a well =
maintained<br>reference model and links to other implementations. =
&nbsp;<br><br><br>Will<br></span></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-2--75354897--

Date: Tue, 18 Mar 2008 13:49:59 -0400
From: Jim Wyllie <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
OpenPGP: url=http://edirectory.ohio.edu/CN%3dJames%20Wyllie%201%2cOU%3dStudents%2cO%3dOhio%20University%2cC%3dUS%3f$tmpl%3dPerson%20%28pgp%29
Subject: [dtn-interest] Future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1EE91729F395BC56D51EA8F1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> NASA has funded Ohio University in the past to maintain code like the
> ION code.  My ability to obtain funding for DTN is pretty poor lately.
> In addition, government funding may come at a cost - ITAR related
> garbage that make code release painful and places unnecessary hurdles i=
n
> place.  So, although I see a usefulness in having a reference model,
> that is reasonably well maintained and documented, I also agree with
> Stephen Farrell.   It would be nice to have both, a well maintained
> reference model and links to other implementations. =20

It would be a major problem if any part of DTN2 were placed under the
same restrictions as the ION codebase.  As a reference implementation, I
can see where more-casual users would be turned off to the asinine
restrictions we have on obtaining the code.  It's OK for ION (as it's
currently an "other implementation" as Will describes it) but IMHO it's
far too cumbersome for a reference implementation.

If it came to funding + Dept of Commerce export restrictions or no
funding and no restrictions, I strongly believe that DTN2 and the
concept of DTN would prosper more under the latter arrangement.

I also agree with Stephen / Will:  well-maintained reference
implementation and links to other implementations is the right answer.
--=20
Jim Wyllie
Master's Student
IRG Lab, School of EE and CS
Ohio University

--------------enig1EE91729F395BC56D51EA8F1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig1EE91729F395BC56D51EA8F1--

Content-class: urn:content-classes:message
Date: Tue, 18 Mar 2008 12:15:24 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

NASA has funded Ohio University in the past to maintain code like the
ION code.  My ability to obtain funding for DTN is pretty poor lately.
In addition, government funding may come at a cost - ITAR related
garbage that make code release painful and places unnecessary hurdles in
place.  So, although I see a usefulness in having a reference model,
that is reasonably well maintained and documented, I also agree with
Stephen Farrell.   It would be nice to have both, a well maintained
reference model and links to other implementations.  

Will

*> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Christopher Small
> Sent: Tuesday, March 18, 2008 11:45 AM
> To: Delay Tolerant Networking Interest List
> Subject: [dtn-interest] notes from IETF discussion on the 
> future of the DTNreference implementation
> 
> I gave a short talk at the DTNRG meeting at IETF on Thursday 
> March 13, pointing out that the future development and 
> maintenance of the DTN reference implementation (DTN2) was 
> uncertain, and that we, as a community, should discuss what 
> we would like from a reference implementation, and who is 
> going to develop and maintain it.
> 
> Slides from my talk are archived at
> http://www.ietf.org/proceedings/08mar/slides/DTNRG-3.pdf.
> 
> After the meeting, seventeen of us convened to discuss the topic. 
> Attending were
> 
> Christopher Small, BBN Technologies
> Scott Burleigh, JPL
> Keith Scott, MITRE
> Mike Petkevich, Lockheed Martin
> Hans Kruse, Ohio University
> Jim Wyllie, Ohio University
> David Young, Ohio University
> Yunfeng Huang, Ohio University
> Stephen Farrell, Trinity College Dublin
> Joerg Ott, Helsinki University of Technology Andrei Gurtov, 
> University of Helsinki Jeff Bush, MITRE Prithwish Basu, BBN 
> Technologies Jim Snyder, DARPA/STA Ryan Metzger, Lehigh 
> University Mike Demmer, UC Berkeley Kevin Fall, Intel 
> Berkeley Research Lab
> 
> I framed the question as follows: there are a number of 
> different reasons for having a reference implementation. It 
> might be (a) as a benchmark for interoperability with 
> alternate implementations; (b) a platform for experimenting 
> with the technology, e.g. trying out different routers and 
> convergence layers, or variants of the protocol; and (c) a 
> platform for people who want to build DTNs, a black box they 
> can download and deploy in the field. What do we want the DTN 
> RI to be?
> 
> I pointed out that the relative sizes of the groups were | (a) | << |
> (b) | << | (c) |, i.e. there would be a handful of people 
> building alternate implementations; there might be tens or 
> hundreds interested in experimenting with routing or the 
> protocol; there would be (eventually, we hope) thousands or 
> hundreds of thousands of DTNs deployed.
> 
> As a point of comparison, there are a (relatively) small 
> number of HTTP daemons; a larger number of people who 
> implement Apache plugins; a much, much larger number of 
> people who deploy Apache out-of-the-box, only modifying 
> config scripts.
> 
> I took away that people want (b), a platform for 
> experimenting with DTN itself. It was pointed out that if 
> (when) the need for easily-deployed, high-performance and/or 
> high-reliability DTN implementations arose, it would be met 
> by the commercial world. (The need might be met by taking the 
> reference implementation and modifying it, or it might be met 
> by clean-slate implementations -- but that wasn't the goal 
> for the DTNRG RI.)
> 
> Mike Demmer told me that he plans to finish his Ph.D. this 
> summer, and is thinking that he's interested in finding a 
> start-up, which will leave him with little time to maintain 
> DTN2. He hopes to be able to spend some time on it, given his 
> investment in the code, but the time is likely to be very limited.
> 
> Someone suggested that Ohio University might be a good place 
> for the code and DTNRG server to call home, long-term. Other 
> suggestions that came up were Boston University and Google 
> (Vint Cerf owns the domain name dtnrg.org; he might be able 
> to get his employer to maintain the DTNRG server).
> 
> Ohio University might also be a good place for an 
> interoperability lab, assuming funding could be secured.
> 
> Someone pointed out that the RI had done quite well being 
> maintained by a graduate student, and perhaps what we should 
> do is find another grad student to take it on as a project.
> 
> Stephen Farrell espoused the position that there was no need 
> for a single distinguished reference implementation. He 
> pointed to the Jabber community, where there are dozens of 
> servers and clients available, and a well-specified protocol. 
> He suggested that instead of having one implementation listed 
> as the RI on the web page, list any implementations 
> available, with comments describing their attributes -- this 
> one is written in Java, this one is small and lightweight, 
> this one scales, this one is good for hacking on, this one is 
> easy to deploy.
> 
> I apologize for my notes being incomplete; we met at a pub, 
> and it was difficult to hear the person next to you, much 
> less the people at the other end of the table. If anyone has 
> additional notes they are willing to share, I would 
> appreciate them posting them here.
> 
> My thanks to Jim Snyder for co-sponsoring the beer.
> 
> - Chris
> 
> -- 
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Tue, 18 Mar 2008 12:15:25 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTNreference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

NASA has funded Ohio University in the past to maintain code like the
ION code.  My ability to obtain funding for DTN is pretty poor lately.
In addition, government funding may come at a cost - ITAR related
garbage that make code release painful and places unnecessary hurdles in
place.  So, although I see a usefulness in having a reference model,
that is reasonably well maintained and documented, I also agree with
Stephen Farrell.   It would be nice to have both, a well maintained
reference model and links to other implementations.  

Will

*> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Christopher Small
> Sent: Tuesday, March 18, 2008 11:45 AM
> To: Delay Tolerant Networking Interest List
> Subject: [dtn-interest] notes from IETF discussion on the 
> future of the DTNreference implementation
> 
> I gave a short talk at the DTNRG meeting at IETF on Thursday 
> March 13, pointing out that the future development and 
> maintenance of the DTN reference implementation (DTN2) was 
> uncertain, and that we, as a community, should discuss what 
> we would like from a reference implementation, and who is 
> going to develop and maintain it.
> 
> Slides from my talk are archived at
> http://www.ietf.org/proceedings/08mar/slides/DTNRG-3.pdf.
> 
> After the meeting, seventeen of us convened to discuss the topic. 
> Attending were
> 
> Christopher Small, BBN Technologies
> Scott Burleigh, JPL
> Keith Scott, MITRE
> Mike Petkevich, Lockheed Martin
> Hans Kruse, Ohio University
> Jim Wyllie, Ohio University
> David Young, Ohio University
> Yunfeng Huang, Ohio University
> Stephen Farrell, Trinity College Dublin
> Joerg Ott, Helsinki University of Technology Andrei Gurtov, 
> University of Helsinki Jeff Bush, MITRE Prithwish Basu, BBN 
> Technologies Jim Snyder, DARPA/STA Ryan Metzger, Lehigh 
> University Mike Demmer, UC Berkeley Kevin Fall, Intel 
> Berkeley Research Lab
> 
> I framed the question as follows: there are a number of 
> different reasons for having a reference implementation. It 
> might be (a) as a benchmark for interoperability with 
> alternate implementations; (b) a platform for experimenting 
> with the technology, e.g. trying out different routers and 
> convergence layers, or variants of the protocol; and (c) a 
> platform for people who want to build DTNs, a black box they 
> can download and deploy in the field. What do we want the DTN 
> RI to be?
> 
> I pointed out that the relative sizes of the groups were | (a) | << |
> (b) | << | (c) |, i.e. there would be a handful of people 
> building alternate implementations; there might be tens or 
> hundreds interested in experimenting with routing or the 
> protocol; there would be (eventually, we hope) thousands or 
> hundreds of thousands of DTNs deployed.
> 
> As a point of comparison, there are a (relatively) small 
> number of HTTP daemons; a larger number of people who 
> implement Apache plugins; a much, much larger number of 
> people who deploy Apache out-of-the-box, only modifying 
> config scripts.
> 
> I took away that people want (b), a platform for 
> experimenting with DTN itself. It was pointed out that if 
> (when) the need for easily-deployed, high-performance and/or 
> high-reliability DTN implementations arose, it would be met 
> by the commercial world. (The need might be met by taking the 
> reference implementation and modifying it, or it might be met 
> by clean-slate implementations -- but that wasn't the goal 
> for the DTNRG RI.)
> 
> Mike Demmer told me that he plans to finish his Ph.D. this 
> summer, and is thinking that he's interested in finding a 
> start-up, which will leave him with little time to maintain 
> DTN2. He hopes to be able to spend some time on it, given his 
> investment in the code, but the time is likely to be very limited.
> 
> Someone suggested that Ohio University might be a good place 
> for the code and DTNRG server to call home, long-term. Other 
> suggestions that came up were Boston University and Google 
> (Vint Cerf owns the domain name dtnrg.org; he might be able 
> to get his employer to maintain the DTNRG server).
> 
> Ohio University might also be a good place for an 
> interoperability lab, assuming funding could be secured.
> 
> Someone pointed out that the RI had done quite well being 
> maintained by a graduate student, and perhaps what we should 
> do is find another grad student to take it on as a project.
> 
> Stephen Farrell espoused the position that there was no need 
> for a single distinguished reference implementation. He 
> pointed to the Jabber community, where there are dozens of 
> servers and clients available, and a well-specified protocol. 
> He suggested that instead of having one implementation listed 
> as the RI on the web page, list any implementations 
> available, with comments describing their attributes -- this 
> one is written in Java, this one is small and lightweight, 
> this one scales, this one is good for hacking on, this one is 
> easy to deploy.
> 
> I apologize for my notes being incomplete; we met at a pub, 
> and it was difficult to hear the person next to you, much 
> less the people at the other end of the table. If anyone has 
> additional notes they are willing to share, I would 
> appreciate them posting them here.
> 
> My thanks to Jim Snyder for co-sponsoring the beer.
> 
> - Chris
> 
> -- 
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 18 Mar 2008 16:49:20 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] notes from IETF discussion on the future of the DTN	reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

First thanks to Chris and Jim for the beers, (an excellent
precedent:-), and thanks to Chris for documenting the chat.

As an addendum, the N4C project (that Avri introduced at
the DTNRG session [1]) will have some effort allocated for
DTN code maintenance but we won't know just how much for
exactly what until the project gets going properly in the
summer.

Cheers,
Stephen.

[1] http://www3.ietf.org/proceedings/08mar/slides/DTNRG-9.pdf

Christopher Small wrote:
> I gave a short talk at the DTNRG meeting at IETF on Thursday March 13, 
> pointing out that the future development and maintenance of the DTN 
> reference implementation (DTN2) was uncertain, and that we, as a 
> community, should discuss what we would like from a reference 
> implementation, and who is going to develop and maintain it.
> 
> Slides from my talk are archived at 
> http://www.ietf.org/proceedings/08mar/slides/DTNRG-3.pdf.
> 
> After the meeting, seventeen of us convened to discuss the topic. 
> Attending were
> 
> Christopher Small, BBN Technologies
> Scott Burleigh, JPL
> Keith Scott, MITRE
> Mike Petkevich, Lockheed Martin
> Hans Kruse, Ohio University
> Jim Wyllie, Ohio University
> David Young, Ohio University
> Yunfeng Huang, Ohio University
> Stephen Farrell, Trinity College Dublin
> Joerg Ott, Helsinki University of Technology
> Andrei Gurtov, University of Helsinki
> Jeff Bush, MITRE
> Prithwish Basu, BBN Technologies
> Jim Snyder, DARPA/STA
> Ryan Metzger, Lehigh University
> Mike Demmer, UC Berkeley
> Kevin Fall, Intel Berkeley Research Lab
> 
> I framed the question as follows: there are a number of different 
> reasons for having a reference implementation. It might be (a) as a 
> benchmark for interoperability with alternate implementations; (b) a 
> platform for experimenting with the technology, e.g. trying out 
> different routers and convergence layers, or variants of the protocol; 
> and (c) a platform for people who want to build DTNs, a black box they 
> can download and deploy in the field. What do we want the DTN RI to be?
> 
> I pointed out that the relative sizes of the groups were | (a) | << | 
> (b) | << | (c) |, i.e. there would be a handful of people building 
> alternate implementations; there might be tens or hundreds interested in 
> experimenting with routing or the protocol; there would be (eventually, 
> we hope) thousands or hundreds of thousands of DTNs deployed.
> 
> As a point of comparison, there are a (relatively) small number of HTTP 
> daemons; a larger number of people who implement Apache plugins; a much, 
> much larger number of people who deploy Apache out-of-the-box, only 
> modifying config scripts.
> 
> I took away that people want (b), a platform for experimenting with DTN 
> itself. It was pointed out that if (when) the need for easily-deployed, 
> high-performance and/or high-reliability DTN implementations arose, it 
> would be met by the commercial world. (The need might be met by taking 
> the reference implementation and modifying it, or it might be met by 
> clean-slate implementations -- but that wasn't the goal for the DTNRG RI.)
> 
> Mike Demmer told me that he plans to finish his Ph.D. this summer, and 
> is thinking that he's interested in finding a start-up, which will leave 
> him with little time to maintain DTN2. He hopes to be able to spend some 
> time on it, given his investment in the code, but the time is likely to 
> be very limited.
> 
> Someone suggested that Ohio University might be a good place for the 
> code and DTNRG server to call home, long-term. Other suggestions that 
> came up were Boston University and Google (Vint Cerf owns the domain 
> name dtnrg.org; he might be able to get his employer to maintain the 
> DTNRG server).
> 
> Ohio University might also be a good place for an interoperability lab, 
> assuming funding could be secured.
> 
> Someone pointed out that the RI had done quite well being maintained by 
> a graduate student, and perhaps what we should do is find another grad 
> student to take it on as a project.
> 
> Stephen Farrell espoused the position that there was no need for a 
> single distinguished reference implementation. He pointed to the Jabber 
> community, where there are dozens of servers and clients available, and 
> a well-specified protocol. He suggested that instead of having one 
> implementation listed as the RI on the web page, list any 
> implementations available, with comments describing their attributes -- 
> this one is written in Java, this one is small and lightweight, this one 
> scales, this one is good for hacking on, this one is easy to deploy.
> 
> I apologize for my notes being incomplete; we met at a pub, and it was 
> difficult to hear the person next to you, much less the people at the 
> other end of the table. If anyone has additional notes they are willing 
> to share, I would appreciate them posting them here.
> 
> My thanks to Jim Snyder for co-sponsoring the beer.
> 
> - Chris
> 

Date: Tue, 18 Mar 2008 11:45:17 -0400
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] notes from IETF discussion on the future of the DTN reference implementation
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I gave a short talk at the DTNRG meeting at IETF on Thursday March 13, 
pointing out that the future development and maintenance of the DTN 
reference implementation (DTN2) was uncertain, and that we, as a 
community, should discuss what we would like from a reference 
implementation, and who is going to develop and maintain it.

Slides from my talk are archived at 
http://www.ietf.org/proceedings/08mar/slides/DTNRG-3.pdf.

After the meeting, seventeen of us convened to discuss the topic. 
Attending were

Christopher Small, BBN Technologies
Scott Burleigh, JPL
Keith Scott, MITRE
Mike Petkevich, Lockheed Martin
Hans Kruse, Ohio University
Jim Wyllie, Ohio University
David Young, Ohio University
Yunfeng Huang, Ohio University
Stephen Farrell, Trinity College Dublin
Joerg Ott, Helsinki University of Technology
Andrei Gurtov, University of Helsinki
Jeff Bush, MITRE
Prithwish Basu, BBN Technologies
Jim Snyder, DARPA/STA
Ryan Metzger, Lehigh University
Mike Demmer, UC Berkeley
Kevin Fall, Intel Berkeley Research Lab

I framed the question as follows: there are a number of different 
reasons for having a reference implementation. It might be (a) as a 
benchmark for interoperability with alternate implementations; (b) a 
platform for experimenting with the technology, e.g. trying out 
different routers and convergence layers, or variants of the protocol; 
and (c) a platform for people who want to build DTNs, a black box they 
can download and deploy in the field. What do we want the DTN RI to be?

I pointed out that the relative sizes of the groups were | (a) | << | 
(b) | << | (c) |, i.e. there would be a handful of people building 
alternate implementations; there might be tens or hundreds interested in 
experimenting with routing or the protocol; there would be (eventually, 
we hope) thousands or hundreds of thousands of DTNs deployed.

As a point of comparison, there are a (relatively) small number of HTTP 
daemons; a larger number of people who implement Apache plugins; a much, 
much larger number of people who deploy Apache out-of-the-box, only 
modifying config scripts.

I took away that people want (b), a platform for experimenting with DTN 
itself. It was pointed out that if (when) the need for easily-deployed, 
high-performance and/or high-reliability DTN implementations arose, it 
would be met by the commercial world. (The need might be met by taking 
the reference implementation and modifying it, or it might be met by 
clean-slate implementations -- but that wasn't the goal for the DTNRG RI.)

Mike Demmer told me that he plans to finish his Ph.D. this summer, and 
is thinking that he's interested in finding a start-up, which will leave 
him with little time to maintain DTN2. He hopes to be able to spend some 
time on it, given his investment in the code, but the time is likely to 
be very limited.

Someone suggested that Ohio University might be a good place for the 
code and DTNRG server to call home, long-term. Other suggestions that 
came up were Boston University and Google (Vint Cerf owns the domain 
name dtnrg.org; he might be able to get his employer to maintain the 
DTNRG server).

Ohio University might also be a good place for an interoperability lab, 
assuming funding could be secured.

Someone pointed out that the RI had done quite well being maintained by 
a graduate student, and perhaps what we should do is find another grad 
student to take it on as a project.

Stephen Farrell espoused the position that there was no need for a 
single distinguished reference implementation. He pointed to the Jabber 
community, where there are dozens of servers and clients available, and 
a well-specified protocol. He suggested that instead of having one 
implementation listed as the RI on the web page, list any 
implementations available, with comments describing their attributes -- 
this one is written in Java, this one is small and lightweight, this one 
scales, this one is good for hacking on, this one is easy to deploy.

I apologize for my notes being incomplete; we met at a pub, and it was 
difficult to hear the person next to you, much less the people at the 
other end of the table. If anyone has additional notes they are willing 
to share, I would appreciate them posting them here.

My thanks to Jim Snyder for co-sponsoring the beer.

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Content-class: urn:content-classes:message
Date: Thu, 13 Mar 2008 15:30:06 -0400
From: "Scott, Keith L." <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] CCSDS to standardise Bundle Protocol? [also:Apps area]
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I think Kevin's got the right idea.

The various agencies in CCSDS see potential benefits from implementing
a common, interoperable, disruption-tolerant networking capability.
Once the working group has a firm handle on the requirements of such
for space missions we'll move out on identifying possible solutions,
and of course the bundle protocol as specified by rfc5050 seems a good
candidate.  If there are specific capabilities needed by space mission
operations, I could see CCSDS specifying additional bundle blocks to
provide those.  I would think that any such work would be coordinated
with other ongoing DTN research, or even going through the dtnrg if
they are found to be of general utility.  The bundle protocol is
intended to be extensible, so there is at least the chance that
'additional capabilities' (whatever they might be) would be
interoperable with the base protocol specification.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kevin Fall
Sent: Thursday, March 13, 2008 8:39 AM
To: Delay Tolerant Networking Interest List
Subject: Re: [dtn-interest] CCSDS to standardise Bundle Protocol?
[also:Apps area]

Thanks for providing the pointer.

On Mar 12, 2008, at Mar 126:46 PMPDT, Lloyd Wood wrote:

> http://mailman.ccsds.org/pipermail/sis-dtn/2008-March/000027.html
>
> has a summary of this week's CCSDS DTN workgroup meeting (which was  
> scheduled for the same week at IETF-71 and the IRTF DTNRG meeting,  
> alas - but later moved from the same day), with links to relevant  
> documents at:
>
http://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2Fsis%2Fd
ocs%2FSIS%2DDTN%2FMeeting%20Materials%2FSpring%202008
>
> excerpted from their charter, stored there:
> "DTN-WG is a Standards Track Working Group.  The Working Group will  
> determine whether or not "Delay-Tolerant Networking" as specified in

> RFC5050 is a feasible solution for a store-and-forward networking  
> protocol for space environments where data relay is likely. If  
> RFC5050 is deemed suitable overall but lacking in certain specific  
> capabilities needed by the space community, this working group may  
> define extensions to RFC5050 to address these needs."
>
> So CCSDS may well end up standardising and doing change control on  
> the experimental IRTF Bundle Protocol for use on operational  
> spacecraft? Is my understanding of this correct?
>
> thanks,
>
> L.

I take the CCSDS statement to mean that within CCSDS, they may borrow  
and/or adopt RFC5050, and possibly change it within the confines of  
CCSDS.  Said another way, no, CCSDS will not have change control over  
IETF (or IRTF) documents, but if they wish to base their own standard  
on I{E,R}TF documents and modify them to suit their needs and make  
them CCSDS standards, that's their game.  Of course, depending on the  
nature of such changes, whether it would really be interoperable or  
not would remain to be seen.

As you probably know, IETF proper has official liaisons with other  
standards developing organizations when deemed necessary.  As a  
possible long-term future direction, if the DTN bundle stuff heads  
toward a real standard within IETF, one could imagine a day when it  
would be worth discussing an IETF/CCSDS liaison.  I believe this would

be premature at this point.

By the way, there is some discussion going on in the apps area about a

re-structuring of e-mail and other things, and this all starts to  
relate to some of the work going on in DTNRG

	(FYI, please see http://www.ietf.org/rfc/rfc3205.txt if you
haven't  
seen it)

The time may become ripe soon to engage a bit with the apps area  
people and see what we bring to the table.  They have a page here:

http://www.apps.ietf.org/mailing-lists.html

and I haven't yet joined these lists, but there was recently a  
breakout session in San Francisco and am looking around for the  
archives. (there were a bunch of whitepapers written up
by the participants)... so more to come.

- K

>
>
> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

Content-class: urn:content-classes:message
Date: Thu, 13 Mar 2008 13:10:37 -0500
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: [dtn-interest] UK-DMC Slides - Type
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I had a typo in the slides and microphone time was limited.  When
Preston mentioned the large metadata size on the NASA bundles, I noted
the typo.
The bundle metadata was 70 - 80 bytes NOT kbytes.

The updated slides are available here:
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/

Steven, can you put the corrected versions in the ITRF DTNRG meeting
materials.

Thanks,

Will

From: Rajesh Krishnan <[email-masked]>
To: Lloyd Wood <[email-masked]>
Organization: BBN Technologies
Date: Thu, 13 Mar 2008 13:54:38 -0400
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] updated bundle checksum draft, slides for	discussion
Reply-To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>

Hi Lloyd,

I appreciate your detailed response.   I can see where you come from.  

I think you and I differ: what you think is a plus for HTTP, I think is
a minus; and what you think is a minus for BP, I think is a plus.  Which
is fine.   IP is pretty remarkable or unremarkable depending on your
POV.  Ditto for other encapsulation formats.

Whatever ATM accomplished or not, it gave researchers a playground, and
also gave IP folks competition that helped IMO.  If the best DTN ideas
do get assimilated into the Internet, that's great.   But the things to
choose to assimilate need time to develop further preferably with
minimum constraints.

I still feel this RG should move up the value chain.  A point worth
repeating I think.

Best Regards,
Rajesh

P.S.:  From where I stand, I can walk away quickly.  From where you sit
you have to get up first, before you can walk away. :)

On Thu, 2008-03-13 at 01:59 +0000, Lloyd Wood wrote:
> Hi Rajesh,
> 
> some answers in brief here below to lay out my thinking around
> http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
> 
> At Tuesday 11/03/2008 20:18 -0400, Rajesh Krishnan wrote:
> >Disclaimer: these are my personal views, not of my project, employer, or funding agency.
> >
> >Lloyd,
> >
> >Thanks for the briefing in advance, especially since I will not be there in Philly.
> >
> >An interesting proposal, but could you explain to me the primary purpose 
> >and motivating requirement for HTTP-DTN please.  
> 
> Well, because we could. (and we can present it here in this research group to an
> audience likely to have at least a passing interest.)
> 
> We'd been thinking about putting MIME'd files into bundles for a project, got to figuring
> out that MIME objects could be delineated in each bundle via http instead of messy
> custom encapsulations we made up, and suddenly realised that that was an http stream,
> and that a continuous persistent pipelined http stream was the simple minimum necessary.
> Creating Content-Destination: clinched it.
> 
> 
> >I want to hear from you 
> >about both upsides and downsides to adopting HTTP-DTN. 
> 
>     upside: it's not the bundle protocol.
> downside: it's not the bundle protocol.
> 
> 
> >Some questions/provocations that will aid me in better understanding the motivation:
> >
> >* Would the IETF EDIINT RFCs/I-Ds already cover your requirements for HTTP-DTN?
> >  Or is EDIINT too specialized a domain?
> 
> EDIINT AS1 (RFC3335) depends on SMTP, and SMTP brings with it a lot of assumptions
> about the infrastructure it depends on - DNS, MX records - even before the 'is this SMTP
> still 7-bit?' question is raised. SMTP is rather chatty, with many timers. HTTP is less so.
> 
> The newer AS2 (RFC4130) is HTTP - interesting, thanks for pointing it out. But it's using
> POST, is very transactional, and presumes an end-to-end http path as a result, which I
> don't think is a good fit with ad-hoc DTN networks or long delays, or the use of http
> hop-by-hop here, where PUT is more relied on. And a lot of email headers and email
> assumptions about infrastructure (e.g. Message-ID, Disposition-Notification-To:) do
> creep into AS2. It's really a port from email and AS1 to http, still with email dependencies.
> 
> AS3 (RFC4823) uses ftp - unlike http, not something that can be easily abstracted away
> from TCP. I don't understand why this was created after AS2 http; http or scp seem
> better starting points.
> 
> (I've no idea whether EDIINT's chosen security model would make sense in any DTN
> environment.)
> 
> 
> >* It appears folks are already doing similar things with HTTP/SOAP in the agent 
> >  middleware world (e.g., www.cougaar.org)? They even seem to support a number of 
> >  other messaging application protocols.  Would those solutions satisfy 
> >  your current requirements that motivate HTTP-DTN, or do you see a real
> >  need for a DTNRG specification in this area?  Such a need to me suggests
> >  potential killer apps lurking for DTN, and I would sure like to hear of them.
> 
> HTTP-DTN can be an enabler for SOAP in DTN environments, in that SOAP expects
> MIME and runs over HTTP. (Discussed in my answer to Stephen on the list when the
> draft was first announced.)
> 
> So, if anyone wanted to run SOAP in an ad-hoc environment where nodes peer to pass
> on information, I think something like HTTP-DTN would be required first as basic
> supporting infrastructure.
> 
> 
> >* Why not write a HTTP-CLA instead?  Why should DTN necessarily sit on top 
> >  of the transport layer or any other specific layer for that matter?  As 
> >  long as a suitable CLA is available, why not just do DTN over it?  Would
> >  a HTTP/SOAP-CLA not achieve your goal?
> 
> What makes the Bundle Protocol compelling for DTN? Layering the BP over
> HTTP/TCP wouldn't add much to the existing TCP/UDP convergence layers,
> while losing access to MIME and the flexible HTTP headers.
> 
> (We've already adapted the Saratoga protocol as a convergence layer for the
> Bundle Protocol:
> http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03
> - if all you want to do is already in the Bundle Protocol and that meets your
> needs, then creating BP-specific convergence layers for your operational
> scenario would be the right thing for you.)
> 
> 
> >* Seems one can define a SMTP-DTN using the X-* headers too.  Why fragment 
> >  the DTN world into BP-DTN, HTTP-DTN, SMTP-DTN, ...? 
> 
> Well, SMTP brings with it infrastructure and assumptions - see above.
> 
> Different scenarios with different needs may benefit from different tools.
> 
> >  I doubt that we 
> >  will have a better/faster Internet if IP-datagram alternatives were 
> >  ubiquitous.
> 
> MPLS is pretty widespread, and arguably contributed to that faster Internet.
> Also, there's IPv6, the alternative to IPv4... and, for where the core of the
> Internet is going, it's interesting to talk to Stewart Bryant on pseudowires
> for core trunking of traffic. These are alternatives to IP, and they're
> increasingly widespread.
> 
> But this is low-level plumbing down below application communication,
> which I gather from your note is not really your area of interest.
> 
> 
> > * HTTP is associated with a client-server model of the world, 
> >  while DTN seems to try to move to a distributed, content-oriented 
> >  world that may frequently not admit contemporaneous end-to-end paths.  
> >  While HTTP itself can be torqued to such a distributed model, and you show 
> >  one way to do it, the whole software infrastructure, tools, and mindset
> >  surrounding the HTTP world will be from the client-server, end-to-end stable path 
> >  view of the world.  Will HTTP-DTN fragment the web world into two halves 
> >  requiring different mindsets and tool chains to do HTTP?   You can tell
> >  me this is a red herring, and I won't mind. :)
> 
> Yes, HTTP-DTN is separate (use of new Content- headers guarantees it).
> 
> So there are two separate pieces - not halves, because one will always be vastly
> larger than the other. Yes, the mindsets are different - no proxying; the end-to-end
> http model is changed to a series of hop-by-hop http sessions along a path. It's an
> interesting question as to how much of the toolsets can be reused usefully - or how
> much you'd want to reuse them.
> 
> With its focus on MIME for content identification, http is all about content networking.
> 
> 
> >* Why should HTTP be perpetuated as the new waist, why can't another new waist
> >  emerge over time (and make HTTP pay for snatching that position from IP :) ?
> 
> HTTP-DTN can become the waist for its particular networks, as the glue
> everything works to - and the idea of separating HTTP from TCP to create a truly
> independent session layer is also interesting for research.
> 
> For other networks - Rosenberg has a draft in currently about how TCP/UDP are really
> the real waist of the terrestrial internet due to NAT and firewalls discouraging anything
> else.
> 
> Over time, stacks collapse, new chokepoints emerge, depending on the architecture
> and what is being done. There's probably an argument for many apps that their
> middleware is the waist as far as the applications are concerned, in that that
> middleware hides many lower-level dependencies from the apps.
> 
> But that is high up, and http-dtn is down in the lower protocols and the plumbing.
> 
> 
> >I want to take a general long-term networking research standpoint and currently 
> >do not have commercial product experience/pressures.  I can imagine packet switching 
> >that is not based on IP (I may get voted off the island for saying this :), and I
> >can imagine content networking not based on HTTP/SOAP/XML.  
> 
> ...while I can imagine DTNs not based on the Bundle Protocol.
> 
> 
> >I have a rather romantic 
> >notion of the BP evolving and supporting a clean-slate (yes I have read Dovrolis' 
> >paper :) future Internet.  That is, with the BP being the slate that the new design 
> >is written on.  I am being naive and unreasonable perhaps.
> 
> I don't see anything compelling in the Bundle Protocol to support that view.
> 
> 
> >Schemas/Ontologies to populate the metadata extension block (to support content 
> >networking), fast BP forwarders, and policy-based control of content networking 
> >are some interesting research topics in this space.  I would like this RG move 
> >up the value chain, and not get stuck in low-level protocol encapsulation and 
> >message formatting issues. 
> 
> I don't see much point in moving up the stack unless the fundamental low-level issues
> are worked out satisfactorily. Hence our ongoing discussion of reliability in the BP.
> Getting the plumbing right for the environment means that you can build vast cities
> in the environment around that plumbing. But the plumbing has to be right.
> 
> Also, there's an argument that the longest-lived protocols are always the flexible,
> text-based ones, which are best suited to expressing metadata etc. Possibly one
> reason why text http displaced binary gopher. And why XML is gaining adoption.
> 
> (Speaking of binary, I see
> http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sdnv-00.txt
> expires next week...)
> 
> > (A shared encapsulation for DTN helps build critical mass 
> >in the research community,  and future versions can fix shortcomings as needed and
> >experience is gained, but a second encapsulation provides diminishing research 
> >returns. I understand there may be other pragmatic considerations though.)
> 
> I think other approaches are also valid research topics that can provide rich
> research returns. As a veteran of European research projects into ATM back when
> Europe was funding only ATM networking projects, I'm sceptical of 'one chosen way',
> and not a great fan of groupthink. The critical mass of European research into ATM
> really didn't achieve much...
> 
> 
> >So, from where I stand, I see that the BP-DTN buys me a more-or-less clean slate 
> >without much baggage since I am not interested in the encapsulation per se.  
> 
> Yet from where I sit, http-dtn gives me a clean slate with a lot of tools that
> I can choose to add to that slate.
> 
> thanks for looking at our work,
> 
> L.
> 
> >Who 
> >is to say some good ideas from DTNRG can't eventually make their way back and get 
> >retrofitted into incumbent Internet technologies including HTTP, but I worry if 
> >it may be premature to force the DTNRG down that path.  Again, just speaking for 
> >myself.
> >
> >For some of my other thoughts on DTN, see for example:
> >http://advika.net/rkrishnan/talks/rkrishnan-coin-neu07.ppt
> >
> >With apologies for sending a long email and including shameless plugs.  ;)
> >
> >Best Regards,
> >Rajesh
> >
> >P.S.:  I will disengage promptly and run away if anyone flames me, for I have 
> >lots of other non-flaming dragons to slay.  :)
> 
> Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/dtn/
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>  
> 

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 13 Mar 2008 05:38:59 -0700
Subject: Re: [dtn-interest] CCSDS to standardise Bundle Protocol? [also: Apps area]
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Thanks for providing the pointer.

On Mar 12, 2008, at Mar 126:46 PMPDT, Lloyd Wood wrote:

> http://mailman.ccsds.org/pipermail/sis-dtn/2008-March/000027.html
>
> has a summary of this week's CCSDS DTN workgroup meeting (which was  
> scheduled for the same week at IETF-71 and the IRTF DTNRG meeting,  
> alas - but later moved from the same day), with links to relevant  
> documents at:
> http://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2Fsis%2Fdocs%2FSIS%2DDTN%2FMeeting%20Materials%2FSpring%202008
>
> excerpted from their charter, stored there:
> "DTN-WG is a Standards Track Working Group.  The Working Group will  
> determine whether or not “Delay-Tolerant Networking” as specified in  
> RFC5050 is a feasible solution for a store-and-forward networking  
> protocol for space environments where data relay is likely. If  
> RFC5050 is deemed suitable overall but lacking in certain specific  
> capabilities needed by the space community, this working group may  
> define extensions to RFC5050 to address these needs."
>
> So CCSDS may well end up standardising and doing change control on  
> the experimental IRTF Bundle Protocol for use on operational  
> spacecraft? Is my understanding of this correct?
>
> thanks,
>
> L.

I take the CCSDS statement to mean that within CCSDS, they may borrow  
and/or adopt RFC5050, and possibly change it within the confines of  
CCSDS.  Said another way, no, CCSDS will not have change control over  
IETF (or IRTF) documents, but if they wish to base their own standard  
on I{E,R}TF documents and modify them to suit their needs and make  
them CCSDS standards, that's their game.  Of course, depending on the  
nature of such changes, whether it would really be interoperable or  
not would remain to be seen.

As you probably know, IETF proper has official liaisons with other  
standards developing organizations when deemed necessary.  As a  
possible long-term future direction, if the DTN bundle stuff heads  
toward a real standard within IETF, one could imagine a day when it  
would be worth discussing an IETF/CCSDS liaison.  I believe this would  
be premature at this point.

By the way, there is some discussion going on in the apps area about a  
re-structuring of e-mail and other things, and this all starts to  
relate to some of the work going on in DTNRG

	(FYI, please see http://www.ietf.org/rfc/rfc3205.txt if you haven't  
seen it)

The time may become ripe soon to engage a bit with the apps area  
people and see what we bring to the table.  They have a page here:

http://www.apps.ietf.org/mailing-lists.html

and I haven't yet joined these lists, but there was recently a  
breakout session in San Francisco and am looking around for the  
archives. (there were a bunch of whitepapers written up
by the participants)... so more to come.

- K

>
>
> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 13 Mar 2008 12:16:13 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] http dtn delivery filename typo - fixed
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Thursday 13/03/2008 01:59 +0000, Lloyd Wood wrote:
>some answers in brief here below to lay out my thinking around
>http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01

Stephen points out the 'dtrng' typo in the above filename; our local filenames were right, but the submission tool keys off the title line in the draft (xml category line), which was consistently typo'd for -00 and -01, so e.g. the draft tracker couldn't pick up on this as a dtnrg-related item. I've uploaded 'dtnrg' replacements, which should be available from where you'd expect shortly.

The correct non-typo'd
http://www.ietf.org/internet-drafts/draft-wood-dtnrg-http-dtn-delivery-01.txt
is now available.

oops.

L.

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

Date: Thu, 13 Mar 2008 11:55:48 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Materials for tomorrow's meeting...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Thanks Marshall.

I believe the URLs you need to follow the meeting are:

jabber room: [email-masked]
jabber log: http://www.ietf.org/meetings/ietf-logs/dtnrg/
audio stream: http://videolab.uoregon.edu/events/ietf/ietf713.m3u

Stephen.

Marshall Eubanks wrote:
> On Mar 13, 2008, at 3:28 AM, vishwas Rudramurthy wrote:
> 
>> Hi,
>>
>> I am planning to attend the meeting remotely, as I reside in  
>> bangalore, India I will be not able to make to the meeting there.  
>> So could you kindly help me out.
> 
> All IETF sessions are webcast, as this message explains. Oddly, the
> Thursday schedule is empty, but the room is Franklin 5 so DTN will be  
> on Channel 3.
> 
> Regards
> Marshall
> 
> ------------------------------------------------------------------------ 
> -
> 
> Greetings,
> 
> All 8 parallel tracks will be broadcast starting with the
> commencement of working group sessions on Monday March 10 at 0900
> EST (UTC-5) and continue until Friday at 1130 EST. Additionally it is
> our intention to broadcast the IEPG meeting occurring on Sunday the 9th
> starting at 1000 EST.
> 
> Because I have been asked several times in the past, note that if you
> wish to use the rooms that are being recorded for impromptu meeting
> during unscheduled sessions or lunch breaks that you can invite remote
> participants to tune in to the appropriate stream. Recording cannot be
> guaranteed for unscheduled sessions. Conversely, it should never be
> assumed that recording or observation is not occurring on open
> microphones, they are after all connected to the Internet.
> 
> The links for streaming sources and the schedule will be available
> thanks to the continued support of the Network Startup Resource Center
> in their traditional location:
> 
> http://videolab.uoregon.edu/events/ietf/
> 
> I Look forward to seeing some of you in Philadelphia and hope that this
> facility remains useful for remote participants in and observers of the
> IETF Process.
> 
> Regards
> Joel Jaeggli
> 
> 
> 
> 
>> Thanks,
>> - Vishwas R
>> Cell: +91 9916473865
>>
>>
>>
>>
>>
>> On 3/13/08, Stephen Farrell <[email-masked]> wrote:
>> ...are mostly now on the datatracker. [1]
>>
>> If you'll be participating remotely via audio and/or jabber,
>> can you let Kevin and I know and we'll try police the mic
>> accordingly.
>>
>> If you owe me slides, please send them soon (though I'm
>> off for a beer now, so anytime tonight is really ok:-)
>>
>> Thanks,
>> Stephen.
>>
>> [1] https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>>
>>
>> -- 
>> VISHWAS R
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Mar 2008 04:17:46 -0400
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Materials for tomorrow's meeting...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Mar 13, 2008, at 3:28 AM, vishwas Rudramurthy wrote:

> Hi,
>
> I am planning to attend the meeting remotely, as I reside in  
> bangalore, India I will be not able to make to the meeting there.  
> So could you kindly help me out.

All IETF sessions are webcast, as this message explains. Oddly, the
Thursday schedule is empty, but the room is Franklin 5 so DTN will be  
on Channel 3.

Regards
Marshall

------------------------------------------------------------------------ 
-

Greetings,

All 8 parallel tracks will be broadcast starting with the
commencement of working group sessions on Monday March 10 at 0900
EST (UTC-5) and continue until Friday at 1130 EST. Additionally it is
our intention to broadcast the IEPG meeting occurring on Sunday the 9th
starting at 1000 EST.

Because I have been asked several times in the past, note that if you
wish to use the rooms that are being recorded for impromptu meeting
during unscheduled sessions or lunch breaks that you can invite remote
participants to tune in to the appropriate stream. Recording cannot be
guaranteed for unscheduled sessions. Conversely, it should never be
assumed that recording or observation is not occurring on open
microphones, they are after all connected to the Internet.

The links for streaming sources and the schedule will be available
thanks to the continued support of the Network Startup Resource Center
in their traditional location:

http://videolab.uoregon.edu/events/ietf/

I Look forward to seeing some of you in Philadelphia and hope that this
facility remains useful for remote participants in and observers of the
IETF Process.

Regards
Joel Jaeggli

>
> Thanks,
> - Vishwas R
> Cell: +91 9916473865
>
>
>
>
>
> On 3/13/08, Stephen Farrell <[email-masked]> wrote:
> ...are mostly now on the datatracker. [1]
>
> If you'll be participating remotely via audio and/or jabber,
> can you let Kevin and I know and we'll try police the mic
> accordingly.
>
> If you owe me slides, please send them soon (though I'm
> off for a beer now, so anytime tonight is really ok:-)
>
> Thanks,
> Stephen.
>
> [1] https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
>
> -- 
> VISHWAS R
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 13 Mar 2008 12:58:25 +0530
From: "vishwas Rudramurthy" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] Materials for tomorrow's meeting...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

------=_Part_9780_33533560.1205393306760
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

I am planning to attend the meeting remotely, as I reside in bangalore,
India I will be not able to make to the meeting there. So could you kindly
help me out.

*Thanks,*
*- Vishwas R*
*Cell: +91 9916473865*

**

On 3/13/08, Stephen Farrell <[email-masked]> wrote:
>
>
> ...are mostly now on the datatracker. [1]
>
> If you'll be participating remotely via audio and/or jabber,
> can you let Kevin and I know and we'll try police the mic
> accordingly.
>
> If you owe me slides, please send them soon (though I'm
> off for a beer now, so anytime tonight is really ok:-)
>
> Thanks,
> Stephen.
>
> [1] https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

-- 
VISHWAS R

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

<div>Hi,</div>
<div>&nbsp;</div>
<div>I am planning to attend the meeting remotely, as I reside in bangalore, India I will be not able to make to the meeting there. So could you kindly help me out.</div>
<div>&nbsp;</div>
<div><strong>Thanks,</strong></div>
<div><strong>- Vishwas R</strong></div>
<div><strong>Cell: +91 9916473865</strong></div>
<p><strong></strong>&nbsp;</p>
<div><br><br>&nbsp;</div>
<div><span class="gmail_quote">On 3/13/08, <b class="gmail_sendername">Stephen Farrell</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>...are mostly now on the datatracker. [1]<br><br>If you&#39;ll be participating remotely via audio and/or jabber,<br>
can you let Kevin and I know and we&#39;ll try police the mic<br>accordingly.<br><br>If you owe me slides, please send them soon (though I&#39;m<br>off for a beer now, so anytime tonight is really ok:-)<br><br>Thanks,<br>
Stephen.<br><br>[1] <a href="https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG">https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG</a><br><br><br>_______________________________________________<br>
dtn-interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>VISHWAS R 

------=_Part_9780_33533560.1205393306760--

Date: Thu, 13 Mar 2008 01:59:59 +0000
To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] updated bundle checksum draft, slides for  discussion
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi Rajesh,

some answers in brief here below to lay out my thinking around
http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01

At Tuesday 11/03/2008 20:18 -0400, Rajesh Krishnan wrote:
>Disclaimer: these are my personal views, not of my project, employer, or funding agency.
>
>Lloyd,
>
>Thanks for the briefing in advance, especially since I will not be there in Philly.
>
>An interesting proposal, but could you explain to me the primary purpose 
>and motivating requirement for HTTP-DTN please.  

Well, because we could. (and we can present it here in this research group to an
audience likely to have at least a passing interest.)

We'd been thinking about putting MIME'd files into bundles for a project, got to figuring
out that MIME objects could be delineated in each bundle via http instead of messy
custom encapsulations we made up, and suddenly realised that that was an http stream,
and that a continuous persistent pipelined http stream was the simple minimum necessary.
Creating Content-Destination: clinched it.

>I want to hear from you 
>about both upsides and downsides to adopting HTTP-DTN. 

    upside: it's not the bundle protocol.
downside: it's not the bundle protocol.

>Some questions/provocations that will aid me in better understanding the motivation:
>
>* Would the IETF EDIINT RFCs/I-Ds already cover your requirements for HTTP-DTN?
>  Or is EDIINT too specialized a domain?

EDIINT AS1 (RFC3335) depends on SMTP, and SMTP brings with it a lot of assumptions
about the infrastructure it depends on - DNS, MX records - even before the 'is this SMTP
still 7-bit?' question is raised. SMTP is rather chatty, with many timers. HTTP is less so.

The newer AS2 (RFC4130) is HTTP - interesting, thanks for pointing it out. But it's using
POST, is very transactional, and presumes an end-to-end http path as a result, which I
don't think is a good fit with ad-hoc DTN networks or long delays, or the use of http
hop-by-hop here, where PUT is more relied on. And a lot of email headers and email
assumptions about infrastructure (e.g. Message-ID, Disposition-Notification-To:) do
creep into AS2. It's really a port from email and AS1 to http, still with email dependencies.

AS3 (RFC4823) uses ftp - unlike http, not something that can be easily abstracted away
from TCP. I don't understand why this was created after AS2 http; http or scp seem
better starting points.

(I've no idea whether EDIINT's chosen security model would make sense in any DTN
environment.)

>* It appears folks are already doing similar things with HTTP/SOAP in the agent 
>  middleware world (e.g., www.cougaar.org)? They even seem to support a number of 
>  other messaging application protocols.  Would those solutions satisfy 
>  your current requirements that motivate HTTP-DTN, or do you see a real
>  need for a DTNRG specification in this area?  Such a need to me suggests
>  potential killer apps lurking for DTN, and I would sure like to hear of them.

HTTP-DTN can be an enabler for SOAP in DTN environments, in that SOAP expects
MIME and runs over HTTP. (Discussed in my answer to Stephen on the list when the
draft was first announced.)

So, if anyone wanted to run SOAP in an ad-hoc environment where nodes peer to pass
on information, I think something like HTTP-DTN would be required first as basic
supporting infrastructure.

>* Why not write a HTTP-CLA instead?  Why should DTN necessarily sit on top 
>  of the transport layer or any other specific layer for that matter?  As 
>  long as a suitable CLA is available, why not just do DTN over it?  Would
>  a HTTP/SOAP-CLA not achieve your goal?

What makes the Bundle Protocol compelling for DTN? Layering the BP over
HTTP/TCP wouldn't add much to the existing TCP/UDP convergence layers,
while losing access to MIME and the flexible HTTP headers.

(We've already adapted the Saratoga protocol as a convergence layer for the
Bundle Protocol:
http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03
- if all you want to do is already in the Bundle Protocol and that meets your
needs, then creating BP-specific convergence layers for your operational
scenario would be the right thing for you.)

>* Seems one can define a SMTP-DTN using the X-* headers too.  Why fragment 
>  the DTN world into BP-DTN, HTTP-DTN, SMTP-DTN, ...? 

Well, SMTP brings with it infrastructure and assumptions - see above.

Different scenarios with different needs may benefit from different tools.

>  I doubt that we 
>  will have a better/faster Internet if IP-datagram alternatives were 
>  ubiquitous.

MPLS is pretty widespread, and arguably contributed to that faster Internet.
Also, there's IPv6, the alternative to IPv4... and, for where the core of the
Internet is going, it's interesting to talk to Stewart Bryant on pseudowires
for core trunking of traffic. These are alternatives to IP, and they're
increasingly widespread.

But this is low-level plumbing down below application communication,
which I gather from your note is not really your area of interest.

> * HTTP is associated with a client-server model of the world, 
>  while DTN seems to try to move to a distributed, content-oriented 
>  world that may frequently not admit contemporaneous end-to-end paths.  
>  While HTTP itself can be torqued to such a distributed model, and you show 
>  one way to do it, the whole software infrastructure, tools, and mindset
>  surrounding the HTTP world will be from the client-server, end-to-end stable path 
>  view of the world.  Will HTTP-DTN fragment the web world into two halves 
>  requiring different mindsets and tool chains to do HTTP?   You can tell
>  me this is a red herring, and I won't mind. :)

Yes, HTTP-DTN is separate (use of new Content- headers guarantees it).

So there are two separate pieces - not halves, because one will always be vastly
larger than the other. Yes, the mindsets are different - no proxying; the end-to-end
http model is changed to a series of hop-by-hop http sessions along a path. It's an
interesting question as to how much of the toolsets can be reused usefully - or how
much you'd want to reuse them.

With its focus on MIME for content identification, http is all about content networking.

>* Why should HTTP be perpetuated as the new waist, why can't another new waist
>  emerge over time (and make HTTP pay for snatching that position from IP :) ?

HTTP-DTN can become the waist for its particular networks, as the glue
everything works to - and the idea of separating HTTP from TCP to create a truly
independent session layer is also interesting for research.

For other networks - Rosenberg has a draft in currently about how TCP/UDP are really
the real waist of the terrestrial internet due to NAT and firewalls discouraging anything
else.

Over time, stacks collapse, new chokepoints emerge, depending on the architecture
and what is being done. There's probably an argument for many apps that their
middleware is the waist as far as the applications are concerned, in that that
middleware hides many lower-level dependencies from the apps.

But that is high up, and http-dtn is down in the lower protocols and the plumbing.

>I want to take a general long-term networking research standpoint and currently 
>do not have commercial product experience/pressures.  I can imagine packet switching 
>that is not based on IP (I may get voted off the island for saying this :), and I
>can imagine content networking not based on HTTP/SOAP/XML.  

...while I can imagine DTNs not based on the Bundle Protocol.

>I have a rather romantic 
>notion of the BP evolving and supporting a clean-slate (yes I have read Dovrolis' 
>paper :) future Internet.  That is, with the BP being the slate that the new design 
>is written on.  I am being naive and unreasonable perhaps.

I don't see anything compelling in the Bundle Protocol to support that view.

>Schemas/Ontologies to populate the metadata extension block (to support content 
>networking), fast BP forwarders, and policy-based control of content networking 
>are some interesting research topics in this space.  I would like this RG move 
>up the value chain, and not get stuck in low-level protocol encapsulation and 
>message formatting issues. 

I don't see much point in moving up the stack unless the fundamental low-level issues
are worked out satisfactorily. Hence our ongoing discussion of reliability in the BP.
Getting the plumbing right for the environment means that you can build vast cities
in the environment around that plumbing. But the plumbing has to be right.

Also, there's an argument that the longest-lived protocols are always the flexible,
text-based ones, which are best suited to expressing metadata etc. Possibly one
reason why text http displaced binary gopher. And why XML is gaining adoption.

(Speaking of binary, I see
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-sdnv-00.txt
expires next week...)

> (A shared encapsulation for DTN helps build critical mass 
>in the research community,  and future versions can fix shortcomings as needed and
>experience is gained, but a second encapsulation provides diminishing research 
>returns. I understand there may be other pragmatic considerations though.)

I think other approaches are also valid research topics that can provide rich
research returns. As a veteran of European research projects into ATM back when
Europe was funding only ATM networking projects, I'm sceptical of 'one chosen way',
and not a great fan of groupthink. The critical mass of European research into ATM
really didn't achieve much...

>So, from where I stand, I see that the BP-DTN buys me a more-or-less clean slate 
>without much baggage since I am not interested in the encapsulation per se.  

Yet from where I sit, http-dtn gives me a clean slate with a lot of tools that
I can choose to add to that slate.

thanks for looking at our work,

L.

>Who 
>is to say some good ideas from DTNRG can't eventually make their way back and get 
>retrofitted into incumbent Internet technologies including HTTP, but I worry if 
>it may be premature to force the DTNRG down that path.  Again, just speaking for 
>myself.
>
>For some of my other thoughts on DTN, see for example:
>http://advika.net/rkrishnan/talks/rkrishnan-coin-neu07.ppt
>
>With apologies for sending a long email and including shameless plugs.  ;)
>
>Best Regards,
>Rajesh
>
>P.S.:  I will disengage promptly and run away if anyone flames me, for I have 
>lots of other non-flaming dragons to slay.  :)

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

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

Date: Thu, 13 Mar 2008 01:46:50 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] CCSDS to standardise Bundle Protocol?
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

http://mailman.ccsds.org/pipermail/sis-dtn/2008-March/000027.html

has a summary of this week's CCSDS DTN workgroup meeting (which was scheduled for the same week at IETF-71 and the IRTF DTNRG meeting, alas - but later moved from the same day), with links to relevant documents at:
http://cwe.ccsds.org/sis/docs/Forms/AllItems.aspx?RootFolder=%2Fsis%2Fdocs%2FSIS%2DDTN%2FMeeting%20Materials%2FSpring%202008

excerpted from their charter, stored there:
"DTN-WG is a Standards Track Working Group.  The Working Group will determine whether or not “Delay-Tolerant Networking” as specified in RFC5050 is a feasible solution for a store-and-forward networking protocol for space environments where data relay is likely. If RFC5050 is deemed suitable overall but lacking in certain specific capabilities needed by the space community, this working group may define extensions to RFC5050 to address these needs."

So CCSDS may well end up standardising and doing change control on the experimental IRTF Bundle Protocol for use on operational spacecraft? Is my understanding of this correct?

thanks,

L.

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

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

Date: Thu, 13 Mar 2008 01:21:31 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Materials for tomorrow's meeting...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

...are mostly now on the datatracker. [1]

If you'll be participating remotely via audio and/or jabber,
can you let Kevin and I know and we'll try police the mic
accordingly.

If you owe me slides, please send them soon (though I'm
off for a beer now, so anytime tonight is really ok:-)

Thanks,
Stephen.

[1] https://datatracker.ietf.org/meeting/71/materials.html#wg-DTNRG

Date: Wed, 12 Mar 2008 03:43:49 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] updated bundle checksum draft, slides for  discussion
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Tuesday 11/03/2008 22:16 +0000, Stephen Farrell wrote:

>Isn't the repository open since Monday?

Okay, -02a *is* -02.

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-checksum-02.txt

ta.

>Lloyd Wood wrote:
>> Hi all,
>> 
>> We've produced an updated bundle checksum draft in line with Kevin's comments of 6 March and subsequent discussion. This is version -02a; we'll submit -02 proper when the drafts repository reopens. A copy of this draft can be obtained at (long url, sorry):
>> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/draft-irtf-dtnrg-bundle-checksum-02a.txt
>> 
>> We've also prepared slides covering important points for the upcoming discussion of reliability and the issues raised in this bundle checksum draft. A copy of those slides is at:
>> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/bundle-checksum-discussion-ietf-71-dtnrg-session.pdf
>> 
>> These should be of interest to anyone not at the meeting who is following along by the audio stream at.
>> http://videolab.uoregon.edu/events/ietf/
>> http://videolab.uoregon.edu/events/ietf/ietf715.m3u
>> channel 3, Franklin 5, 9-11:30am EDT, 1300-1530 GMT Thursday 13 March.
>> 
>> Finally, the slides I've prepared presenting the HTTP-DTN concept are at:
>> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf
>> 
>> cheers,
>> 
>> L.
>> 
>> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

From: Rajesh Krishnan <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Organization: BBN Technologies
Date: Tue, 11 Mar 2008 20:18:47 -0400
Subject: Re: [dtn-interest] updated bundle checksum draft, slides for	discussion
Reply-To: [email-masked], Delay Tolerant Networking Interest List <[email-masked]>

Disclaimer: these are my personal views, not of my project, employer, or funding agency.

Lloyd,

Thanks for the briefing in advance, especially since I will not be there in Philly.

An interesting proposal, but could you explain to me the primary purpose 
and motivating requirement for HTTP-DTN please.   I want to hear from you 
about both upsides and downsides to adopting HTTP-DTN. 

Some questions/provocations that will aid me in better understanding the motivation:

* Would the IETF EDIINT RFCs/I-Ds already cover your requirements for HTTP-DTN?
  Or is EDIINT too specialized a domain?

* It appears folks are already doing similar things with HTTP/SOAP in the agent 
  middleware world (e.g., www.cougaar.org)? They even seem to support a number of 
  other messaging application protocols.  Would those solutions satisfy 
  your current requirements that motivate HTTP-DTN, or do you see a real
  need for a DTNRG specification in this area?  Such a need to me suggests
  potential killer apps lurking for DTN, and I would sure like to hear of them.

* Why not write a HTTP-CLA instead?  Why should DTN necessarily sit on top 
  of the transport layer or any other specific layer for that matter?  As 
  long as a suitable CLA is available, why not just do DTN over it?  Would
  a HTTP/SOAP-CLA not achieve your goal?

* Seems one can define a SMTP-DTN using the X-* headers too.  Why fragment 
  the DTN world into BP-DTN, HTTP-DTN, SMTP-DTN, ...?  I doubt that we 
  will have a better/faster Internet if IP-datagram alternatives were 
  ubiquitous.
 
* HTTP is associated with a client-server model of the world, 
  while DTN seems to try to move to a distributed, content-oriented 
  world that may frequently not admit contemporaneous end-to-end paths.  
  While HTTP itself can be torqued to such a distributed model, and you show 
  one way to do it, the whole software infrastructure, tools, and mindset
  surrounding the HTTP world will be from the client-server, end-to-end stable path 
  view of the world.  Will HTTP-DTN fragment the web world into two halves 
  requiring different mindsets and tool chains to do HTTP?   You can tell
  me this is a red herring, and I won't mind. :)

* Why should HTTP be perpetuated as the new waist, why can't another new waist
  emerge over time (and make HTTP pay for snatching that position from IP :) ?

I want to take a general long-term networking research standpoint and currently 
do not have commercial product experience/pressures.  I can imagine packet switching 
that is not based on IP (I may get voted off the island for saying this :), and I
can imagine content networking not based on HTTP/SOAP/XML.  I have a rather romantic 
notion of the BP evolving and supporting a clean-slate (yes I have read Dovrolis' 
paper :) future Internet.  That is, with the BP being the slate that the new design 
is written on.  I am being naive and unreasonable perhaps.

Schemas/Ontologies to populate the metadata extension block (to support content 
networking), fast BP forwarders, and policy-based control of content networking 
are some interesting research topics in this space.  I would like this RG move 
up the value chain, and not get stuck in low-level protocol encapsulation and 
message formatting issues.  (A shared encapsulation for DTN helps build critical mass 
in the research community,  and future versions can fix shortcomings as needed and
experience is gained, but a second encapsulation provides diminishing research 
returns. I understand there may be other pragmatic considerations though.)

So, from where I stand, I see that the BP-DTN buys me a more-or-less clean slate 
without much baggage since I am not interested in the encapsulation per se.  Who 
is to say some good ideas from DTNRG can't eventually make their way back and get 
retrofitted into incumbent Internet technologies including HTTP, but I worry if 
it may be premature to force the DTNRG down that path.  Again, just speaking for 
myself.

For some of my other thoughts on DTN, see for example:
http://advika.net/rkrishnan/talks/rkrishnan-coin-neu07.ppt

With apologies for sending a long email and including shameless plugs.  ;)

Best Regards,
Rajesh

P.S.:  I will disengage promptly and run away if anyone flames me, for I have 
lots of other non-flaming dragons to slay.  :)

> Finally, the slides I've prepared presenting the HTTP-DTN concept are at:
> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf
> 
> cheers,
> 
> L.
> 
> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Michael Demmer <[email-masked]>
To: dtn-interest <[email-masked]>
Date: Tue, 11 Mar 2008 16:01:49 -0700
Subject: [dtn-interest] dinner wednesday
Reply-To: Michael Demmer <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>

If anyone else is interested in going out for dinner as a group on  
Wednesday (tomorrow) in advance of the DTNRG meeting, send me an email  
and I'll try to organize something.

-mike

Date: Wed, 12 Mar 2008 00:21:28 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] WNS2 CFP: inviting DTN-related papers
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Lloyd,

just curious: since this is an ns2 workshop, I suspect you are
not very much interested in getting a paper on a different simulator
(such as ONE)?  How much connection to ns2 would be needed?

Thanks,
Joerg

> http://www.wns2.org/
> http://www.wns2.org/docs/wns2-2008-call-for-papers.pdf
> 
> The Second Workshop on ns-2 (and -3) is being held in Athens, Greece this October. We'd welcome papers on using ns for delay-tolerant networking simulation.
> 
> L.
> 
> for the WNS2 co-chairs.
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 11 Mar 2008 22:16:38 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] updated bundle checksum draft, slides for discussion
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Isn't the repository open since Monday?

Lloyd Wood wrote:
> Hi all,
> 
> We've produced an updated bundle checksum draft in line with Kevin's comments of 6 March and subsequent discussion. This is version -02a; we'll submit -02 proper when the drafts repository reopens. A copy of this draft can be obtained at (long url, sorry):
> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/draft-irtf-dtnrg-bundle-checksum-02a.txt
> 
> We've also prepared slides covering important points for the upcoming discussion of reliability and the issues raised in this bundle checksum draft. A copy of those slides is at:
> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/bundle-checksum-discussion-ietf-71-dtnrg-session.pdf
> 
> These should be of interest to anyone not at the meeting who is following along by the audio stream at.
> http://videolab.uoregon.edu/events/ietf/
> http://videolab.uoregon.edu/events/ietf/ietf715.m3u
> channel 3, Franklin 5, 9-11:30am EDT, 1300-1530 GMT Thursday 13 March.
> 
> Finally, the slides I've prepared presenting the HTTP-DTN concept are at:
> http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf
> 
> cheers,
> 
> L.
> 
> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 11 Mar 2008 22:01:52 +0000
To: DTN <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] updated bundle checksum draft, slides for discussion
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi all,

We've produced an updated bundle checksum draft in line with Kevin's comments of 6 March and subsequent discussion. This is version -02a; we'll submit -02 proper when the drafts repository reopens. A copy of this draft can be obtained at (long url, sorry):
http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/draft-irtf-dtnrg-bundle-checksum-02a.txt

We've also prepared slides covering important points for the upcoming discussion of reliability and the issues raised in this bundle checksum draft. A copy of those slides is at:
http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-irtf-dtnrg-bundle-checksum/bundle-checksum-discussion-ietf-71-dtnrg-session.pdf

These should be of interest to anyone not at the meeting who is following along by the audio stream at.
http://videolab.uoregon.edu/events/ietf/
http://videolab.uoregon.edu/events/ietf/ietf715.m3u
channel 3, Franklin 5, 9-11:30am EDT, 1300-1530 GMT Thursday 13 March.

Finally, the slides I've prepared presenting the HTTP-DTN concept are at:
http://info.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf

cheers,

L.

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

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

Date: Tue, 11 Mar 2008 21:32:42 +0000
To: DTN <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] WNS2 CFP: inviting DTN-related papers
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

http://www.wns2.org/
http://www.wns2.org/docs/wns2-2008-call-for-papers.pdf

The Second Workshop on ns-2 (and -3) is being held in Athens, Greece this October. We'd welcome papers on using ns for delay-tolerant networking simulation.

L.

for the WNS2 co-chairs.

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

From: "Peter Lovell" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Date: Tue, 11 Mar 2008 11:05:14 -0400
Cc: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Re(2): comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Tue, Mar 11, 2008, Stephen Farrell <[email-masked]> wrote:

>Having said that, an implementation (e.g. Pete's DTN2 code)
>might equally decide not to be quite so flexible, which may
>or may not be the right design decision, so the spec-level
>flexibility might or might not be present in all implementations.
>(In this case, I don't know how flexible Pete's code is in
>this respect.)

Hi Stephen,

The existing dtn2 code leaves the decision to each ciphersuite. 
The BlockProcessor code (the higher-level plugin) deals only
with ciphersuites and not with the block content, except for
intermediate nodes doing forwarding. 

The detailed processing of the block content, which is where
canonicalization is handled, is done by the plugin code
(at next layer down) implementing the specific ciphersuite.
There's no requirement or expectation that ciphersuites will
use the two canonicalization schemes described in BSP.

Cheers.....Peter

From: "Peter Lovell" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>, "Lloyd Wood" <[email-masked]>, Susan <[email-masked]>, "Peter Lovell" <[email-masked]>
Date: Tue, 11 Mar 2008 10:49:48 -0400
Subject: [dtn-interest] Re(2): comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

On Tue, Mar 11, 2008, Eddy, Wesley M. (GRC-RCN0)[VZ]
<[email-masked]> wrote:

>On canonicalization, Stephen educated me yesterday that a ciphersuite
>is able to define its own canonicalization and isn't limited to the
>two modes specified in the BSP.  On re-reading the BSP spec, I think
>one sentence is needed to be appended to:
>
>   This section defines two bundle canonicalisation algorithms which can
>   be used by various ciphersuites.
>
>Append: "Ciphersuites may define other canonicalisation algorithms and are
>not limited two the two defined in this document."
>
>This was probably clear to the authors, but it wasn't to me as a reader! :)

Hi Wes,

that's a good point. Yes - it has been clear to authors and, re-reading
that section now, it's true that the language there suggests that there
are only the two possibilities. 

I think it might be even more clear if I change it to say that the two
possibilities being described are the ones used for the ciphersuites
described [further down] and that other suites may use these or define
their own.

Separate from but related to this is a follow-up thought to a comment
the other day about adding more bits to those covered by
canonicalization (raised by Lloyd, IIRC). It turns out that we have a
problem with versions; more specifically with a lack of version
numbering. We have it for bundle protocol but it slipped by with regard
to BSP. That's not good :(  It's not appropriate to change the bundle-
protocol-version if we change a ciphersuite definition, so ciphersuites
need some way to define their own versions. We'll have to address this
down the road -- I just wanted to memorialize it so we don't forget.

Regards.....Peter

Date: Tue, 11 Mar 2008 14:55:03 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Interop
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi All,

I've spoken to the terminal room folks and they're expecting a
bunch of us to colonise a table Thursday afternoon and maybe
Friday morning. (The network tear-down starts at noon Friday.)

If you're interested in taking part, gather at the end of the
DTNRG session and we can self-organise.

Stephen.

PS: Chatting with Joerg this morning, he (as usual:-) has a
cool app that'd be good to try out in the BP interop. Turn up
to find out more!

Date: Tue, 11 Mar 2008 14:21:57 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Cc: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> On canonicalization, Stephen educated me yesterday that a ciphersuite
> is able to define its own canonicalization and isn't limited to the
> two modes specified in the BSP.  On re-reading the BSP spec, I think
> one sentence is needed to be appended to:
> 
>    This section defines two bundle canonicalisation algorithms which can
>    be used by various ciphersuites.
> 
> Append: "Ciphersuites may define other canonicalisation algorithms and are
> not limited two the two defined in this document."

Sounds good.

Might even expand a bit more in addition to add something like:

"Each ciphersuite independently defines its inputs (the bytes
processed), processing (including c14n and all other crypto
processing), and its outputs (block types and content). While
new ciphersuites may well re-use some of the elements defined
for existing ciphersuites (e.g. c14n), there is no requirement
that this be the case. One motivation for this is the experience
in other groups [xmlsig, s/mime] of the need to change such
ciphersuite details over time."

Having said that, an implementation (e.g. Pete's DTN2 code)
might equally decide not to be quite so flexible, which may
or may not be the right design decision, so the spec-level
flexibility might or might not be present in all implementations.
(In this case, I don't know how flexible Pete's code is in
this respect.)

Stephen.

> 
> This was probably clear to the authors, but it wasn't to me as a reader! :)
> 
> As for talking about canonicalization in the checksum draft, I think we
> can remove this; it's not a big deal.
> 
> -----Original Message-----
> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Wed 3/5/2008 5:53 PM
> To: Delay Tolerant Networking Interest List; Symington, Susan F.
> Cc: Ivancic, William D. (GRC-RCN0); Wesley Eddy
> Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01
> 
> Hi Susan,
> 
> first of all, thanks for taking the time to review and comment on our draft.
> 
> We'll deal with the first part here, and with mutable canonicalization later
> in a separate email. Inline below:
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Tue, 11 Mar 2008 08:40:10 -0500
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Delay Tolerant Networking Interest List" <[email-masked]>, "Symington, Susan F." <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8837D.6D039DC7
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On canonicalization, Stephen educated me yesterday that a ciphersuite
is able to define its own canonicalization and isn't limited to the
two modes specified in the BSP.  On re-reading the BSP spec, I think
one sentence is needed to be appended to:

   This section defines two bundle canonicalisation algorithms which can
   be used by various ciphersuites.

Append: "Ciphersuites may define other canonicalisation algorithms and =
are
not limited two the two defined in this document."

This was probably clear to the authors, but it wasn't to me as a reader! =
:)

As for talking about canonicalization in the checksum draft, I think we
can remove this; it's not a big deal.

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]]
Sent: Wed 3/5/2008 5:53 PM
To: Delay Tolerant Networking Interest List; Symington, Susan F.
Cc: Ivancic, William D. (GRC-RCN0); Wesley Eddy
Subject: Re: [dtn-interest] comments on =
draft-irtf-dtnrg-bundle-checksum-01
=20
Hi Susan,

first of all, thanks for taking the time to review and comment on our =
draft.

We'll deal with the first part here, and with mutable canonicalization =
later
in a separate email. Inline below:

------_=_NextPart_001_01C8837D.6D039DC7
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.7652.24">
<TITLE>RE: [dtn-interest] comments on =
draft-irtf-dtnrg-bundle-checksum-01</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>On canonicalization, Stephen educated me yesterday =
that a ciphersuite<BR>
is able to define its own canonicalization and isn't limited to the<BR>
two modes specified in the BSP.&nbsp; On re-reading the BSP spec, I =
think<BR>
one sentence is needed to be appended to:<BR>
<BR>
&nbsp;&nbsp; This section defines two bundle canonicalisation algorithms =
which can<BR>
&nbsp;&nbsp; be used by various ciphersuites.<BR>
<BR>
Append: &quot;Ciphersuites may define other canonicalisation algorithms =
and are<BR>
not limited two the two defined in this document.&quot;<BR>
<BR>
This was probably clear to the authors, but it wasn't to me as a reader! =
:)<BR>
<BR>
As for talking about canonicalization in the checksum draft, I think =
we<BR>
can remove this; it's not a big deal.<BR>
<BR>
-----Original Message-----<BR>
From: Lloyd Wood [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Wed 3/5/2008 5:53 PM<BR>
To: Delay Tolerant Networking Interest List; Symington, Susan F.<BR>
Cc: Ivancic, William D. (GRC-RCN0); Wesley Eddy<BR>
Subject: Re: [dtn-interest] comments on =
draft-irtf-dtnrg-bundle-checksum-01<BR>
<BR>
Hi Susan,<BR>
<BR>
first of all, thanks for taking the time to review and comment on our =
draft.<BR>
<BR>
We'll deal with the first part here, and with mutable canonicalization =
later<BR>
in a separate email. Inline below:</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8837D.6D039DC7--

Content-class: urn:content-classes:message
Date: Fri, 7 Mar 2008 09:19:21 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] my commentson	draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kevin Fall
>Sent: Thursday, March 06, 2008 5:27 PM
>
>Point taken.  This is a thing that has been implemented both 
>with reliability in the CL and without, and left at least a 
>little vague up to this point.  I think its a thing we should 
>now iron out, now that the situation is relatively more clear. 
> II think we've generally thought of the BP as "better than 
>best effort" (which is "more reliable", but maybe not quite to 
>the point of TCP-ish reliability).  Ultimately, BP doesn't 
>have e2e retransmission, and is conceived to (e.g.) work over 
>one-way links.... so it can never be truly reliable.  But the 
>things some layer of software has to worry about, whether its 
>an application or a transport-layer-like reliability protocol, 
>that sits above the BP should be made more tight... which is a 
>thing I believe you would agree with.

I very much agree with that!  I guess the issue to resolve is that
4838 and 5050 use "reliable" without making qualifiers.  Just picking
on one instance in 4838 for example:

"the responsibility for reliable delivery of the bundle to its
 destination(s) may move among one or more "custodians" in the
 network."

The responsibility that's moved should not be "reliable
delivery", but rather just "delivery"!  Then note that it's
ultimately the job of an application built on top of bundle protocol
to determine if reliability of the delivered PDU contents even
matters, and optionally take responsibility for this itself.
Decoupling the concept of ensuring delivery of some number of bits
from the concept of maintaining the exact same set of bits is the key.

I think it would be more clear if only one paragraph was added to the
architecture.  This would note that the basic bundle PROTOCOL is
not intended to have capabilities itself for detecting errors either
in transmission or introduced internal to a node, and that
convergence layer protocols cannot detect or correct errors that
occur internal to a node, though within the ARCHITECTURE, other means
might be employed to acheive this end-to-end (though perhaps not at
intermediate hops).  This scopes the services that are and aren't
provided by different parts of the architecture and allows users to
determine their application requirements based on a clear
understanding.

What do you think about that?

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 6 Mar 2008 14:27:49 -0800
Subject: Re: [dtn-interest] free beer (and the future of the DTN reference implementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

after the plenary.. then I'm no longer on the IAB :o....

- K

On Mar 6, 2008, at Mar 62:05 PMPST, Christopher Small wrote:

> It looks like more people will be around on Thursday than on  
> Wednesday,
> so let's plan on Thursday. Now the question is whether to have it  
> before
> the plenary (say, 4:00-5:00) or after the plenary (7:30-...).  If the
> latter I'll find a place that has food as well.
>
> Do people have strong feelings about either slot? The advantage of the
> former is that it does not conflict with dinner plans (or other
> meetings) and allows us to continue after the plenary if there is  
> interest.
>
> I'll scout out the area on Wednesday and will announce a location on
> Thursday at the DTNRG meeting.
>
> - Chris
>
> -- 
> Dr. Christopher Small                         617.873.6261 (vox)
> Networking Research                           617.873.6091 (fax)
> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 6 Mar 2008 14:26:50 -0800
Subject: Re: [dtn-interest] my comments on	draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

comments inline...

On Mar 6, 2008, at Mar 69:40 AMPST, Eddy, Wesley M. (GRC-RCN0)[VZ]  
wrote:

>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Kevin  
>> Fall
>> Sent: Thursday, March 06, 2008 10:18 AM
>>
>> 	"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 statement is false.  It is possible, it just is not
>> provided by the custody transfer mechanism / bundle protocol alone.
>
>
> Do you mean by an end application?  The statement, as written
> is true if talking about an intermediate bundle agent.  Maybe
> we just need a couple words added to clarify that.

Perhaps.  The point is that there are many ways to verify that things  
have been reliably delivered.  You may have an application sitting  
atop the bundle protocol which could do it, or you may have some other  
layer of software atop it that could also do it.

>
>
> A lot of the other comments look like they just require
> wording changes to make clear that "some common (but not all)
> application types are not tolerant of errored content"

yes, maybe.  Please don't underestimate the value of delivering data  
with errors in it.  Errors in the meta-data is perhaps another thing,  
and that
is the part that will merit interesting discussion in the context of  
the rest of the group, imho.

> so
> I didn't comment on them individually below.  The other
> places where you noted "inflammatory" language can be easily
> fixed too, though didn't make it into this particular update.

Yes, I expect it can be fixed.

>
> I can take responsibility for making these changes by the next
> update.

excellent.. have at it!

>
>
>
>> 	"It is assumed that the
>>   "convergence layer adapters" that connect BAs to each other will
>>   detect and correct errors before presenting bundle data to the BAs
>>   themselves. "
>>
>> This statement is false.  A CL may or may not do this.  I
>> objected to this before when I reviewed the -0 draft.
>
>
> The bundle architecture is pretty vague on this.  On September 18th,
> 2007,
> I asked you the following the first time you mentioned this sentence,
> and I
> never received any clarification:
> """
> Is there a reference we can use for that?  Maybe part of 4838?  I  
> looked
> in 4838, but didn't find a clear statement saying that this was  
> either a
> DTN application's job or the bundle protocol's job.  As an
> application-writer, I'd be prone to assuming the protocol handled it  
> for
> me since 4838 talks so much about being able to provide reliability  
> when
> requested.

Point taken.  This is a thing that has been implemented both with  
reliability in the CL and without, and left at least a little vague
up to this point.  I think its a thing we should now iron out, now  
that the situation is relatively more clear.  II think we've generally  
thought
of the BP as "better than best effort" (which is "more reliable", but  
maybe not quite to the point of TCP-ish reliability).  Ultimately, BP  
doesn't
have e2e retransmission, and is conceived to (e.g.) work over one-way  
links.... so it can never be truly reliable.  But the things some layer
of software has to worry about, whether its an application or a  
transport-layer-like reliability protocol, that sits above the BP  
should be made
more tight... which is a thing I believe you would agree with.

>
>
> ...
>
>> 	The phrase: "Since error-detection and rejection is a vital
>> 	and absolutely essential component of reliable networking
> protocols"
>> 	I don't necessarily agree with.  This refers to what layer you
>> 	implement this capability, and as mentioned above, the
> application
>> 	is free to implement this and in general we advise folks to
>> 	implement apps this way if they require it.
>
>
> I'm fine if that's what we want to decide, but I wish this point was
> clear in the architecture document or the bundle protocol spec.  It
> won't be pleasant if users have to discover through their own trials
> and tribulations that they have some additional responsibilities that
> they were assumed to be aware of.
> """
> http://maillists.intel-research.net/pipermail/dtn-interest/2007-Septembe
> r/002898.html
>
> You said you were concerned about getting your comment addressed in  
> the
> document, so I hope you or others will follow-up and discuss how we  
> can
> get the architecture clarified in this regard, or if it is documented
> clearly somewhere that several of us have somehow missed.
>
> I have recently seen the bundle protocol referred to as a "robust"
> networking protocol, so these gaps between perception and reality
> make me a lot nervous about using the current protocol operationally.

Again, I follow your point.  I think its a reasonable thing for us to  
bring up collectively.  If necessary, we can write a draft clarifying  
what "reliability" means precisely, and this might well be derived  
from what you have done so far.

>
>
>
>> 	"Due to the more open-loop nature of communication across delay-
>>   tolerant and disrupted networks, applications do not communicate as
>>   well or as easily as they do in the traditional Internet, meaning
>>   that the the efficiency tradeoff for application-only
>> checks is such
>>   that DTN application performance will increase with
>> earlier detection
>>   of errors and earlier resends within the network."
>>
>> (typo: "the the")
>> Once again, this is assuming a particular operational scenario
>> which may not necessarily be the case.  In particular:
>> 1. error free delivery may not be necessary 2. it may not be
>> the case that app performance will increase by doing this
>
>
> Ok; so the wording should be clarified a bit here, to reflect
> that the assumed application tolerance of errored content is
> true for many but not all classes of applications?

that would help immensely.  Maybe even "some" rather than "many".

>
>
>
>> 	"But the biggest problem with PIB-RSA-SHA256 is the bulk of code
>>   needed to support the RSA operations, which include bignum math and
>>   modular arithmetic libraries.  "
>>
>> Well, it might be for some cases.  Please say so.
>> Further, if you are going to use reference to
>> a particular library (bignum), please provide a reference.
>> Alternatively,
>> just say that large numbers need to be manipulated.
>
>
> We didn't reference a particular library.  Did you want us to
> provide a line count for some common bignum library like GMP
> to show what it takes to do math on large numbers?  No matter
> which library one picks, it requires extra code in the systems
> languages that I'm familiar with and only comes for free in
> higher-level languages.

No, I wasn't really looking for something burdensome.  To just say  
"bignum" is a bit askew in level of detail relative to the rest of the  
document.  I think it would be more convincing to say something along  
the lines of the size of the numbers that need to be manipulated.

>
>
>
>> 	"As providing error detection is necessary to ensure
>>   reliable delivery of bundles, these MUST always be supported in any
>>   implementation of the Bundle Protocol, since
>> error-detection must be
>>   an essential property of the Bundle Protocol.
>>
>> I fundamentally disagree with this statement.  However, it
>> could be argued that bundle protocol implementations need to
>> implement these things nonetheless, as long as they can be
>> optionally enabled.
>> One could consider pulling out the error detection capability
>> as separate and/or we may consider protection of only the meta data.
>
>
> Ok; the use of requirements language in that block of text seems out
> of place to me, and I think your suggestion is good to give some
> flexibility to implementers to do something that's appropriate for
> their environment, *as long as they understand the implications.*

sure.  I could probably even be convinced (after some work) that some  
level of error detection could be the default.  It is absolutely  
essential to me, however, that
bundles with errors in their payloads have some way of not being  
discarded by the network or end system.

>
>
>
>> 	"When applications request custody transfer, the
>> generated bundles
>>   MUST use an unkeyed or NULL-keyed PIB ciphersuite defined in this
>>   document between the source and destination bundle agents."
>>
>> I think this merits further discussion.  In particular,
>> whether it is correct to couple the type of error detection
>> you are after with custody transfer or whether error detection
>> (or lack thereof) should be an orthogonal thing an application
>> can request.
>
>
> Definitely, this needs to be discussed more.  I think we can
> probably even get consensus on what the defaults are or aren't.

yeah, I'd think probably so.

>
> Maybe this should be a (or the?) primary thing to try and resolve
> in Philadelphia?  In my mind, it's at the crux because it clarifies
> whether an application assumes error-free bundle delivery, or if
> it has to specifically request it.

I basically agree.  I think its important to have this discussion, and  
PHL seems reasonable.

>
>
>
>> Perhaps the document should simply not be an RG
>> document but instead an individual submission unless/until
>> some of the objections I raised in the -0 draft which still
>> persist are resolved.
>
>
> I don't personally have much opinion on whether this particular
> document is an individual or RG draft, as long as the RG adopts
> some draft or action on the topic.  There is at least one other
> standards body attempting to utilize the bundle protocol, and
> it seems that the RG should be officially doing something about
> the issue of where and how errors are dealt with in the
> architecture so that other groups don't have to puzzle over it.

My statement above is targeted at the objectionable language and the  
lack of updates relative to my last set of comments.  If these  
concerns are addressed, I see no particular reason why we couldn't  
progress this document (and this issue more broadly) within the  
context of the RG.

thx,
- K {from Torino}

>
> http://mailman.ccsds.org/pipermail/sis-dtn/2008-March/000014.html
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Thu, 06 Mar 2008 17:05:16 -0500
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] free beer (and the future of the DTN reference implementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

It looks like more people will be around on Thursday than on Wednesday, 
so let's plan on Thursday. Now the question is whether to have it before 
the plenary (say, 4:00-5:00) or after the plenary (7:30-...).  If the 
latter I'll find a place that has food as well.

Do people have strong feelings about either slot? The advantage of the 
former is that it does not conflict with dinner plans (or other 
meetings) and allows us to continue after the plenary if there is interest.

I'll scout out the area on Wednesday and will announce a location on 
Thursday at the DTNRG meeting.

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Content-class: urn:content-classes:message
Date: Thu, 6 Mar 2008 11:40:57 -0600
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] my comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Kevin Fall
>Sent: Thursday, March 06, 2008 10:18 AM
>
>	"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 statement is false.  It is possible, it just is not 
>provided by the custody transfer mechanism / bundle protocol alone.

Do you mean by an end application?  The statement, as written
is true if talking about an intermediate bundle agent.  Maybe
we just need a couple words added to clarify that.

A lot of the other comments look like they just require
wording changes to make clear that "some common (but not all)
application types are not tolerant of errored content", so
I didn't comment on them individually below.  The other
places where you noted "inflammatory" language can be easily
fixed too, though didn't make it into this particular update.
I can take responsibility for making these changes by the next
update.

>	"It is assumed that the
>    "convergence layer adapters" that connect BAs to each other will
>    detect and correct errors before presenting bundle data to the BAs
>    themselves. "
>
>This statement is false.  A CL may or may not do this.  I 
>objected to this before when I reviewed the -0 draft.

The bundle architecture is pretty vague on this.  On September 18th,
2007,
I asked you the following the first time you mentioned this sentence,
and I
never received any clarification:
"""
Is there a reference we can use for that?  Maybe part of 4838?  I looked
in 4838, but didn't find a clear statement saying that this was either a
DTN application's job or the bundle protocol's job.  As an
application-writer, I'd be prone to assuming the protocol handled it for
me since 4838 talks so much about being able to provide reliability when
requested.

...

> 	The phrase: "Since error-detection and rejection is a vital
> 	and absolutely essential component of reliable networking
protocols"
> 	I don't necessarily agree with.  This refers to what layer you
> 	implement this capability, and as mentioned above, the
application
> 	is free to implement this and in general we advise folks to
> 	implement apps this way if they require it.

I'm fine if that's what we want to decide, but I wish this point was
clear in the architecture document or the bundle protocol spec.  It
won't be pleasant if users have to discover through their own trials
and tribulations that they have some additional responsibilities that
they were assumed to be aware of.
"""
http://maillists.intel-research.net/pipermail/dtn-interest/2007-Septembe
r/002898.html

You said you were concerned about getting your comment addressed in the
document, so I hope you or others will follow-up and discuss how we can
get the architecture clarified in this regard, or if it is documented
clearly somewhere that several of us have somehow missed.

I have recently seen the bundle protocol referred to as a "robust"
networking protocol, so these gaps between perception and reality
make me a lot nervous about using the current protocol operationally.

>	"Due to the more open-loop nature of communication across delay-
>    tolerant and disrupted networks, applications do not communicate as
>    well or as easily as they do in the traditional Internet, meaning
>    that the the efficiency tradeoff for application-only 
>checks is such
>    that DTN application performance will increase with 
>earlier detection
>    of errors and earlier resends within the network."
>
>(typo: "the the")
>Once again, this is assuming a particular operational scenario 
>which may not necessarily be the case.  In particular:
>1. error free delivery may not be necessary 2. it may not be 
>the case that app performance will increase by doing this

Ok; so the wording should be clarified a bit here, to reflect
that the assumed application tolerance of errored content is
true for many but not all classes of applications?

>	"But the biggest problem with PIB-RSA-SHA256 is the bulk of code
>    needed to support the RSA operations, which include bignum math and
>    modular arithmetic libraries.  "
>
>Well, it might be for some cases.  Please say so.
>Further, if you are going to use reference to
>a particular library (bignum), please provide a reference.   
>Alternatively,
>just say that large numbers need to be manipulated.

We didn't reference a particular library.  Did you want us to
provide a line count for some common bignum library like GMP
to show what it takes to do math on large numbers?  No matter
which library one picks, it requires extra code in the systems
languages that I'm familiar with and only comes for free in
higher-level languages.

>	"As providing error detection is necessary to ensure
>    reliable delivery of bundles, these MUST always be supported in any
>    implementation of the Bundle Protocol, since 
>error-detection must be
>    an essential property of the Bundle Protocol.
>
>I fundamentally disagree with this statement.  However, it 
>could be argued that bundle protocol implementations need to 
>implement these things nonetheless, as long as they can be 
>optionally enabled.
>One could consider pulling out the error detection capability 
>as separate and/or we may consider protection of only the meta data.

Ok; the use of requirements language in that block of text seems out
of place to me, and I think your suggestion is good to give some
flexibility to implementers to do something that's appropriate for
their environment, *as long as they understand the implications.*

>	"When applications request custody transfer, the 
>generated bundles
>    MUST use an unkeyed or NULL-keyed PIB ciphersuite defined in this
>    document between the source and destination bundle agents."
>
>I think this merits further discussion.  In particular, 
>whether it is correct to couple the type of error detection 
>you are after with custody transfer or whether error detection 
>(or lack thereof) should be an orthogonal thing an application 
>can request.

Definitely, this needs to be discussed more.  I think we can
probably even get consensus on what the defaults are or aren't.
Maybe this should be a (or the?) primary thing to try and resolve
in Philadelphia?  In my mind, it's at the crux because it clarifies
whether an application assumes error-free bundle delivery, or if
it has to specifically request it.

>Perhaps the document should simply not be an RG 
>document but instead an individual submission unless/until 
>some of the objections I raised in the -0 draft which still 
>persist are resolved.

I don't personally have much opinion on whether this particular
document is an individual or RG draft, as long as the RG adopts
some draft or action on the topic.  There is at least one other
standards body attempting to utilize the bundle protocol, and
it seems that the RG should be officially doing something about
the issue of where and how errors are dealt with in the
architecture so that other groups don't have to puzzle over it.
http://mailman.ccsds.org/pipermail/sis-dtn/2008-March/000014.html

Date: Thu, 06 Mar 2008 08:50:58 -0800
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] my comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Kevin Fall wrote:
> Below are my comments on this draft.  Note that there are a few  
> comments relating to items that remain from the -0 draft... an item  
> which causes me concern.  -K
>   
Excellent.  Thank you, Kevin.

Scott

From: Kevin Fall <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Thu, 6 Mar 2008 07:18:02 -0800
Subject: [dtn-interest] my comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Below are my comments on this draft.  Note that there are a few  
comments relating to items that remain from the -0 draft... an item  
which causes me concern.  -K

comments on draft-irtf-dtnrg-bundle-checksum-01
K. Fall
6-Mar-2008

my comments are structured as quotes from the
document (indented), followed by my comment(s), not indented

	"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 statement is false.  It is possible, it just is not provided by the
custody transfer mechanism / bundle protocol alone.

	"TCP and UDP segments ..."

nit: UDP does not have "segments"

	"It is assumed that the
    "convergence layer adapters" that connect BAs to each other will
    detect and correct errors before presenting bundle data to the BAs
    themselves. "

This statement is false.  A CL may or may not do this.  I objected
to this before when I reviewed the -0 draft.

	"To detect errors introduced in storage, a
    checksum across the bundle would be verified before the bundle is
    sent to the next hop."

I would say "could be" rather than "would be".

	"It would be possible for all intermediate routers in the terrestrial
    Internet to verify the upper-layer pseudo-header checksum at each  
hop
    rather than just checking data-link CRCs, but, in an efficiency
    tradeoff, this is not normally done."

This statement is not always true, due to fragmentation.

	"It becomes
    worthwhile for intermediate bundle nodes to check all content for
    error-free correctness before forwarding it, to prevent incurring
    unnecessary transmission costs and to also increase the possibility
    of getting the bundle from the source or from over the previous hop
    again if it needs to be resent, shortening the overall resend time."

I do not agree with this statement, although I wouldn't call it false.
There may well be some cases where it is worthwhile, but it is important
to remember there are cases where this is not the case.  This statement
implicitly assumes errored data is not valuable.

	"Due to the more open-loop nature of communication across delay-
    tolerant and disrupted networks, applications do not communicate as
    well or as easily as they do in the traditional Internet, meaning
    that the the efficiency tradeoff for application-only checks is such
    that DTN application performance will increase with earlier  
detection
    of errors and earlier resends within the network."

(typo: "the the")
Once again, this is assuming a particular operational scenario which
may not necessarily be the case.  In particular:
1. error free delivery may not be necessary
2. it may not be the case that app performance will increase by doing  
this

	"This shift in costs caused by the difficulty of resending
    information, when compared to the traditional Internet, makes
    verifying the correctness of the header and payload content at each
    bundle node much more important, to permit faster resends and
    conserve storage and transmission capacity.  The Bundle Protocol, as
    specified in [RFC5050], does neither of these things.  Nor does the
    Bundle Protocol protect itself end-to-end."

I agree only with the last two sentences, for reasons mentioned above.
True, the other sentences -may- be true, but maybe not.

    "There
    is a need for a check at intermediate nodes in challenged networks,
    given the cost tradeoffs, yet those nodes cannot take advantage of a
    precomputed end-to-end checksum unless one is first provided for
    them."

Same argument I have made above.

	"The PIB is intended to be used end-to-end; that is, by two endpoints,
    rather than hop-by-hop at each intermediate point."

I believe you want to say by -at least- two endpoints.

	"As there the Bundle Protocol has no separate outer error detection
    wrapping this security payload, if a private key is used, then  
third-
    party nodes that do not possess that secret key cannot determine the
    reliability of the content, and would be unable to prevent further
    forwarding of errored bundles, leading to decreased performance of
    the delay-tolerant network for resends, due to the open nature of  
its
    control loop as discussed above."

I just do not understand this subparagraph.  I asume the word "there"
shouldn't be there.  Please expand or refine this explanation.

	"But the biggest problem with PIB-RSA-SHA256 is the bulk of code
    needed to support the RSA operations, which include bignum math and
    modular arithmetic libraries.  "

Well, it might be for some cases.  Please say so.
Further, if you are going to use reference to
a particular library (bignum), please provide a reference.   
Alternatively,
just say that large numbers need to be manipulated.

	"Furthermore, RSA was historically patent-encumbered, and this is very
    typical of modern asymmetric-key cryptography techniques in general,
    so although the RSA patents have expired, we are hesitant to require
    implementation of asymmetric-key techniques unless needed for
    security purposes."

This seems moot.  Suggest delete.

	"Any PIB ciphersuite providing only integrity checking for error-
    detection and is unkeyed MUST contain the string "INSECURE" in its
    mnemonic."

nit: I don't think you mean unkeyed.  I think you mean
using published keys?

	"Since error-detection support is
    essential in any sane protocol design and should be mandated in the
    design,"

I fundamentally disagree with this statement.  The current text
is evidently a small modification of what you said in the -0 draft.  I
objected to it there, and I do so here as well.

	"The
    security result is always a 4-octet quantity when PIB-INSECURE-CRC32
    is used.  The advantage of this checksum"

Some folks really don't like calling CRCs checksums.  Personally, I do
not care all that much.

	"As providing error detection is necessary to ensure
    reliable delivery of bundles, these MUST always be supported in any
    implementation of the Bundle Protocol, since error-detection must be
    an essential property of the Bundle Protocol.

I fundamentally disagree with this statement.  However, it could be
argued that bundle protocol implementations need to implement
these things nonetheless, as long as they can be optionally enabled.
One could consider pulling out the error detection capability as  
separate
and/or we may consider protection of only the meta data.

	"When applications request custody transfer, the generated bundles
    MUST use an unkeyed or NULL-keyed PIB ciphersuite defined in this
    document between the source and destination bundle agents."

I think this merits further discussion.  In particular, whether it
is correct to couple the type of error detection you are after with
custody transfer or whether error detection (or lack thereof) should
be an orthogonal thing an application can request.

	"Private
    keys cannot guarantee reliable hop-by-hop delivery, increasing the
    time to error detection at the end nodes and the time required for
    resends. "

This sentence sounds rather strange.  I don't think you really mean
that private keys either do or don't guarantee reliable hop-by-hop
delivery.  I think you mean something related to how private keys
might be used.

	"A future version of the Bundle
    Protocol might include a bundle processing flag that signals that
    errored-delivery is acceptable to a receiving application.  "

This is an important thing... a thing that we need to discuss as a group
I think.

	"... their meaningful use of custody transfer."

Can you define what "meaningful" means?

	"This design decision to reuse a security block for error-detection
    may seem bizarre to both security and networking experts unfamiliar
    with the travails of the IRTF DTN research group.  However, this
    decision was necessitated by the late addition of checksum support  
to
    the Bundle Protocol.  By the time this work was recognized by the
    group as necessary by the group, "

You do understand that this has *not* been recognized by the group,
and that I have objected to this portion (and this paragraph) in the
past, which apparently you still need to address.

	"Ideally, the error-detection functions would be implemented within
    the basic networking portions of the Bundle Protocol, and not as a
    subset of the security framework."

That is one opinion.  I don't necessarily find it ideal.  If I wish
to use an ECC, for example, why would I possibly want your error  
detection?

	"Since at this time, the
    Bundle Protocol has only been proposed as Experimental with some
    disclaimers, this situation is temporarily palatable.  It is well-
    understood that future revisions of the Bundle Protocol need to
    provide mechanisms ensuring error detection for reliable delivery."

See above.  Perhaps the document should simply not be an RG document but
instead an individual submission unless/until
some of the objections I raised in the -0 draft which still persist
are resolved.

	"Some proposed convergence layers do not provide any form
    of checksum to compensate for this oversight in bundle design."

I object to this statement, for reasons I have stated repeatedly.  I  
find
it inflammatory.

	"he BSP's
        mutable canonicalization description shows three separate  
fields,
        with only slightly differing names, but in totally opposite
        order: "Proc.  Flags", "COS Flags", and "SRR Flags", instead of
        one single SDNV, yet has text that describes operating on these
        as a single 64-bit value and applying a fixed-length mask to
        them.  This is unclear at best, and feared to be uninteroperable
        in implementations."

I expect this may be a result of a version mismatch between BSP
and block design in the BP.  I expect this can be easily addressed.

	"This means that these bits, and any other bundle
        processing control bits, will be unprotected by the end-to-end
        checksum and may change in-transit, potentially causing mis-
        treatment or mal-delivery of bundles."

Probably something to discuss further, but reference to DSCP needs
to be understood in the context of the fact that those bits may be
changed in transit due to remarkers.

I would echo Susan's comment wrt fragmentation.
I think this will bring up the relative value of having a built-in
cksum mechanism cover only block information (except payload)
when custody xfer or another (TBD) bit is enabled.

As I have suggested in the comments, I would like to know if you
intend to remove or modify the language in the draft where you have made
absolute and inflammatory remarks, suggesting group consensus
which does not exist.  If you don't intend to remove or modify
this language, I will suggest we change this draft to a
individual submission.

Date: Wed, 05 Mar 2008 23:53:12 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>,  "Symington, Susan F." <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi Susan,

first of all, thanks for taking the time to review and comment on our draft.

We'll deal with the first part here, and with mutable canonicalization later
in a separate email. Inline below:

At Wednesday 05/03/2008 13:01 -0500, Symington, Susan F. wrote:
>Wesley, Lloyd, and Will,
>
>I've read through your bundle_checksum_01 draft.
>
>I agree that it would be nice to have a mechanism that enables every
>node in the network to  verify whether a bundle that it receives for
>forwarding or delivery has had any errors  introduced into it. As you
>point out, there is no point in wasting network resources  forwarding a
>bundle across the network if it will only be discarded at its
>destination  because it fails an integrity check. Furthermore, there is
>no point in taking custody of a  bundle for storing and later
>forwarding if it will only be discared at its destination  because it
>fails an integrity check. This is basically the reasoning behind using
>the Bundle  Authentication Block (BAB). The idea is to identify and
>discard erroneous bundles at the  first node at which they are
>received.

Yes - the weakness in relying on the BAB is that the BAB can only detect
in-transit errors over a single bundle hop.

Corruption in a node followed by an okay transfer won't be picked up
by any BAB or by any convergence layer checksum or custody transfer
subsequently, and the corrupted bundle will be relayed to its
destination, consuming network resources, before errors are detected
(using end-to-end security and the PIB if encryption is in use).

 From this point of view, the BAB is equivalent to (though at a slightly higher
layer than) a convergence layer checksum (if the convergence layer has one.)

>You assert that computing checksums on a hop-by-hop basis would be
>inadequate because this  would allow errors that are introduced within
>a bundle node's memory, storage, or forwarding  system to go unnoticed.
>My first thought is that I wonder how much of a concern this really
>is. I don't know; I'm just wondering. 

Our take is that for large bundles, which undergo a lot of segmentation and
reassembly, the risk of introduced error, corruption or overwriting is far higher
than for single small datagrams which don't have as many computations done
on or around them. For nodes in challenging environments (radiation, lack of
error-correcting memory, etc, long-term holding onto bundles) the storage
risk is also higher than for Internet routers trying to hold onto packets for
as little time as possible.

That would make Jonathan Stone's 'Traces of Internet packets for the past
two years show that between 1 packet in 1,100 and 1 packet in 32,000
fails the TCP checksum, even on links where link-level CRCs should catch
all but 1 in 4 billion errors' [When the CRC and TCP Checksum Disagree,
ACM SIGCOMM 2000] a best-case scenario.

Here, we can think of the link-level CRC for a single datagram frame
as the equivalent of a per-link BAB check for a single, larger,
reassembled bundle with a higher probability of introduced error.
Despite the link-layer checks, the number of packets failing the
end-to-end check is significant.

We can extrapolate from this to predict that, despite the BAB checks,
and due to the reasons outlined above, the number of bundles failing
the end-to-end PIB check will also be proportionally significant.

>Defining a hop-by-hop "checksum"
>(I'm using this term  as shorthand for any unkeyed or NULL-keyed
>ciphersuite) for use in the BAB may not be ideal,  but it seems a lot
>less fraught with complexities than defining an an end-to-end checksum
>that has the property that it can be verified at any intermediate node.
>An  end-to-end checksum could be used in conjunction with a BAB
>checksum to ensure that errors  that are missed by use of the BAB
>checksum are found at the destination.

However, you have to expend network resources to get to the
destination. And, if you're sending an encrypted bundle through nodes
lacking the key, you MUST expend resources to get to the destination,
because only at the destination can that encrypted bundle be decrypted
and checked. Errors can't be detected early to lead to early discards.

With the unencrypted ciphersuites our draft defines, checking a complete
bundle at an intermediate hop at least becomes possible - no key required.
This leads to the odd situation where the resend loop and network utilization
for unencrypted complete bundles is smaller and faster than for encrypted
complete bundles, as errors can be picked up sooner. It's more
DTN-friendly in that it increases DTN performance.

Performance considerations would then encourage using the insecure
(unkeyed or NULL-keyed) ciphersuites, and applications doing their own
private security outside the Bundle Protocol to get bundle checks at
intermediate nodes and an overall performance increase.

(And utilization and efficiency concerns would encourage intermediate
nodes to favour forwarding unencrypted traffic they can check and know
is good over PIB-encrypted traffic that they can't and know nothing about.
We're presuming that transfer of reliable data is the goal here; it will
not be for some applications, but it is for the majority.)

>The use of both a  BAB checksum
>and a PIB (end-to-end) checksum in combination would allow all errors
>that were not introduced in the  nodes themselves to be discovered
>immediately, and all other errors to be discovered at the  destination.

It's the (eventually) 'at the destination' which consumes network resources
and slows things up, but this seems to be more of a problem for encrypted
ciphersuites than for the new insecure cyphersuites.

Also, if there's a custody transfer along the way after an error has been
introduced, there may no longer be a viable pristine copy of the bundle
available to be resent; with custody transfer the problem has
been handed off. So, once the corrupted bundle reaches the end node,
there's no recourse. (This can be ameliorated somewhat by sending back
a checksum in the custody transfer receipt and not discarding the bundle
until you've verified the checksum, or better but far more resource-
consuming, having the source node hang on to its original copy until it gets
some sort of ack from the destination. That's a long control loop, though.)

>So, performing checksumming in the BAB may be something to reconsider.
>(It also has  the added benefit of protecting all the mutable fields in
>the bundle.)

..during transfers only, alas - not while sitting in memory. It's better
than nothing, but as Stone suggests, it won't be sufficient by itself. And it
doesn't give much over a convergence-layer checksum.

>If you have already  considered this carefully, or if this
>was already discussed and dismissed at the last DTNRG meeting, which I
>missed, my apologies.

We think our basic arguments about the BAB not addressing the core
reliability and performance issues are outlined above.

>You want to use the Payload Integrity Block (PIB) to compute checksums
>at the source and  verify them at the destination because this is the
>only way to ensure integrity along the  entire path. While verifying at
>the destination may be relatively easy, computing checksums  at the
>source and being able to verify them at any node along the way to the
>destination is much harder, as you have discovered.

The main reason it's harder is that security prevents it! Place encryption
within an outer end-to-end reliability wrapper, and this becomes less hard,
as the reliability wrapper can be checked at each node (provided that
fragmentation does not occur.)

It seems that the easiest way to get end-to-end security within an
end-to-end reliability wrapper that can be checked wherever a complete
bundle is present (which should include all custody transfer destinations)
for faster detection of introduced errors will be for the applications to
use the insecure ciphersuites introduced in this draft for reliability within
the network and checking (when not fragmented), and to
do their own security outside the Bundle Protocol. (This is a solution
C to add to the A and B outlined previously in the thread below.)

>The main question that stands out for me as I read your draft is how it
>will interact with  fragmentation, and I don't think the answer is
>favorable. Suppose a bundle is generated  by an application and custody
>transfer is requested. According to your draft, the bundle must have a
>PIB checksum attached to it. Then suppose at some later node the bundle
>is fragmented  into two parts. These two parts will themselves each be
>a bundle, one having a payload block  with the first n bytes of the
>original payload and the other having a payload block with the  last m
>bytes of the original payload. The first fragment will have the PIB
>checksum in it.  When these fragments are forwarded to separate
>next-hop nodes, the node that receives the  first fragment will not be
>able to verify the PIB checksum in it because the payload in that
>fragment is not the payload over which the PIB checksum was calculated.
>If this node tries to  perform the PIB checksum verification, it will
>end up discarding the bundle. The PIB checksum  can only be verified at
>a node that has all fragments and is able to reassemble them so as to
>recover the entire original payload.

Yes, fragmentation is thorny; that hasn't changed.

There's probably a case to be made for calculating per-fragment checksums.

[mutable canonicalization]

We'll deal with mutable canonicalization in a later email.

>Thank you for acknowledging me in your draft. I hope my comments
>continue to be helpful.

they are. Thankyou.

L. (for Will/Wes)

>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Lloyd
>Wood
>>Sent: Saturday, March 01, 2008 4:52 PM
>>To: Delay Tolerant Networking Interest List
>>Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
>>
>>At Saturday 01/03/2008 18:24 +0000, Stephen Farrell wrote:
>>>Lloyd Wood wrote:
>>>> At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:
>>>>> I was assuming we'd just have the chat without PPT since we
>>>>> already had a presentation on this before - has it changed
>>>>> significantly?
>>>> 
>>>> http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>>>> 
>>>> Yes, this draft has changed significantly. Good you asked, 
>>otherwise the chairs and others might not be aware of this and 
>>might not think to read this working group 
>>>
>>>This is not an IETF working group. Rather basic differences 
>>exist between IRTF RGs and IETF WGs.
>>
>>Sorry, slip of the tongue. 'the -irtf- in the title indicates 
>>it's been adopted as a *research* group... draft, which is 
>>what I meant to indicate.
>>
>>You asked if this draft has changed. It has. My announcement 
>>of the draft in:
>>http://maillists.intel-research.net/pipermail/dtn-interest/2008
>>-February/003020.html
>>did not call out those changes. As I said below, my fault. I 
>>didn't attempt to draw any attention to its content to attract 
>>interest. So, here's a summary of the important bits.
>>
>>Even using the 'rework existing ciphersuites to add new 
>>ciphersuites for reliability only' method that we've now 
>>carefully explored in a couple of different ways before writing:
>>http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>>we've found a couple of problems that this approach cannot 
>>solve, which the draft talks about:
>>
>>1. We've identified a problem with the concept of Custody 
>>Transfer, in that unless the (nth) recipient along can be sure 
>>it has the bundle unaltered and unerrored, its custody receipt 
>>back to the n-1th node really isn't worth much. As it stands 
>>in the existing Bundle Protocol, Custody Transfer ignores 
>>errors creeping in, because it can't detect them. We think 
>>Custody Transfer needs to have protection against errors to be 
>>at all meaningful; a node can't detect errors with encrypted 
>>bundles that it is relaying but doesn't have the keys for.
>>
>>2. We've identified cases where resends across the network are 
>>possible much faster for reliability-only clear-ciphersuite 
>>bundles than secured encrypted bundles, because a node along 
>>the path can perform a end-to-end reliability check on the 
>>clear bundle using the checksum, detect errors introduced 
>>earlier, and get a resend of the bundle earlier with a tighter 
>>and faster control loop. With encrypted payloads where 
>>intermediate nodes don't have the keys, this check of the 
>>payload is only possible at a node with the key, leading to a 
>>longer control loop as the now-errored payload still has to be 
>>forwarded to its security destination before the error can be 
>>picked up. In disconnected DTNs, lengthening this loop is far 
>>more significant than it is in the terrestrial internet where 
>>added hops only add milliseconds (say, comparing the IPv4 
>>at-every-node and IPv6-at-destination-only header checks). Use 
>>of secured bundles can lead to a network performance problem 
>>that discourages us!
>> e of security or of third-party untrusted-node relaying of 
>>secured bundles in DTNs. 
>>
>>So, in the approach in the draft, introducing reliability 
>>without security to the Bundle Protocol for reliable, 
>>unencrypted, payloads, brings benefits that security alone in 
>>the BP can't have for encrypted payloads (meaningful Custody 
>>Transfer, shortened control loops).
>>
>>We have identified two approaches to avoiding these two problems:
>>
>>A. End-to-end bundle security within an outer end-to-end 
>>reliability wrapper for intermediate nodes use to to check 
>>bundles and detect errors before forwarding is one way around 
>>this performance problem, and it also makes for meaningful 
>>Custody Transfer. This would be a major change in how the 
>>bundle protocol is structured (analogous to the push/pop stuff 
>>discussed with Peter on this list a while back, pushing an 
>>outer e2e reliability checksum around an encrypted-e2e bundle 
>>payload.) We haven't attempted to look at an implementation 
>>that would do this in more detail.
>>
>>B. The other way around these two issues is to only ever 
>>forward through trusted nodes which have all the keys, so that 
>>those nodes can check the content for introduced errors (or 
>>tampering) and where Custody Transfer becomes meaningful again 
>>as bundles can be checked for errors before being relayed on, 
>>with early resends requested in tighter control loops if 
>>errors are detected.
>>
>>
>>>And the sarcasm is neither welcome nor effective. It just makes
>>>you look silly and IMO makes it less likely your ideas will gain
>>>ready (or any) acceptance.
>>
>>The ideas should stand on their own merit - once they're 
>>clearly presented and understood by the group. Our written 
>>conclusions in this draft form the starting point for any 
>>discussion at the meeting, and we can summarise them neatly 
>>and concisely in pictures in five minutes before the 
>>discussion. Believe me, the stuff you've just waded through 
>>reading above, which took us months to be able to even 
>>articulate, is better in pictures...
>>
>>L.
>>
>>>Stephen.
>>>
>>>> draft before the meeting. (My fault for assuming you'd read 
>>the draft. We had to read your latest security drafts to write 
>>it!) There's an important control loop/network performance 
>>argument that needs to be presented and discussed.
>>>
>>>> 
>>>> I include a copy of your latest agenda below, along with 
>>drafts where I know them, which are always worth including in 
>>the agendas. Reading the drafts before the talks increases 
>>understanding immensely. A discussion without a talk on the 
>>issues first, by those who have actually studied the issues 
>>closely enough to write them down coherently, to attempt to 
>>bring those who haven't up to speed and set the topics for 
>>discussion is really not worth having. Well-thought-out 
>>written arguments are the starting point for discussion here.
>>>> 
>>>> (The previous presentation in Chicago was on the very different
>>>>  http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
>>>> different name, different approach, completely rewritten since.)
>>>> 
>>>> L.
>>>> 
>>>> DTNRG IETF-71 Meeting
>>>> 
>>>> Last changed on 20080301
>>>> 
>>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in 
>>the Franklin 5 room.
>>>> 
>>>> We're planning to do some BP/LTP interop starting on 
>>Thursday after the meeting slot and continuing into Friday morning.
>>>> Agenda
>>>> Time    Topic   Who (link to slides)
>>>> 0900-0905       Welcome & agenda bash   Chairs
>>>> 0905-0930       DTNRG document status/news/interop plans    
>>    Chairs & others
>>>> 0940-1000       Security/Integrity chat         Howard Weiss (tbc)
>>>>                       
>>http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 
>>needs presenting first
>>>> 1000-1010       DTN reference code      Mike Demmer
>>>> 1010-1020       Future reference implementation(s)      Chris Small
>>>> 1020-1030       N4C project     Elwyn Davies/Avri Doria
>>>>                       (related to 
>>http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00 I'm guessing.)
>>>> 1030-1040       UK-DMC  Will Ivancic
>>>>                       (results from implementing 
>>http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
>>>> 1040-1050       Intentional Naming      Pritwish Basu
>>>> 1050-1100       Using HTTP      Lloyd Wood
>>>>                       
>>http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
>>>> 1100-1110       Telemetry Control Protocol      Mike Petkevich
>>>> 1110-1130       DARPA DTN work  Preston Marshall
>>>> 
>>>>> S.
>>>>>
>>>>> PS: the 20 minutes left over was notional - I'd of course
>>>>> forgotten a couple of slots that'd been requested earlier.
>>>>> Now fixed. [1]
>>>>>
>>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html

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

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

Content-class: urn:content-classes:message
Date: Wed, 5 Mar 2008 13:01:35 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: [dtn-interest] comments on draft-irtf-dtnrg-bundle-checksum-01
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Wesley, Lloyd, and Will,

I've read through your bundle_checksum_01 draft.

I agree that it would be nice to have a mechanism that enables every
node in the network to  verify whether a bundle that it receives for
forwarding or delivery has had any errors  introduced into it. As you
point out, there is no point in wasting network resources  forwarding a
bundle across the network if it will only be discarded at its
destination  because it fails an integrity check. Furthermore, there is
no point in taking custody of a  bundle for storing and later
forwarding if it will only be discared at its destination  because it
fails an integrity check. This is basically the reasoning behind using
the Bundle  Authentication Block (BAB). The idea is to identify and
discard erroneous bundles at the  first node at which they are
received.

You assert that computing checksums on a hop-by-hop basis would be
inadequate because this  would allow errors that are introduced within
a bundle node's memory, storage, or forwarding  system to go unnoticed.
My first thought is that I wonder how much of a concern this really
is. I don't know; I'm just wondering. Defining a hop-by-hop "checksum"
(I'm using this term  as shorthand for any unkeyed or NULL-keyed
ciphersuite) for use in the BAB may not be ideal,  but it seems a lot
less fraught with complexities than defining an an end-to-end checksum
that has the property that it can be verified at any intermediate node.
An  end-to-end checksum could be used in conjunction with a BAB
checksum to ensure that errors  that are missed by use of the BAB
checksum are found at the destination. The use of both a  BAB checksum
and a PIB (end-to-end) checksum in combination would allow all errors
that were not introduced in the  nodes themselves to be discovered
immediately, and all other errors to be discovered at the  destination.
So, performing checksumming in the BAB may be something to reconsider.
(It also has  the added benefit of protecting all the mutable fields in
the bundle.) If you have already  considered this carefully, or if this
was already discussed and dismissed at the last DTNRG meeting, which I
missed, my apologies.

You want to use the Payload Integrity Block (PIB) to compute checksums
at the source and  verify them at the destination because this is the
only way to ensure integrity along the  entire path. While verifying at
the destination may be relatively easy, computing checksums  at the
source and being able to verify them at any node along the way to the
destination is much harder, as you have discovered. 

The main question that stands out for me as I read your draft is how it
will interact with  fragmentation, and I don't think the answer is
favorable. Suppose a bundle is generated  by an application and custody
transfer is requested. According to your draft, the bundle must have a
PIB checksum attached to it. Then suppose at some later node the bundle
is fragmented  into two parts. These two parts will themselves each be
a bundle, one having a payload block  with the first n bytes of the
original payload and the other having a payload block with the  last m
bytes of the original payload. The first fragment will have the PIB
checksum in it.  When these fragments are forwarded to separate
next-hop nodes, the node that receives the  first fragment will not be
able to verify the PIB checksum in it because the payload in that
fragment is not the payload over which the PIB checksum was calculated.
If this node tries to  perform the PIB checksum verification, it will
end up discarding the bundle. The PIB checksum  can only be verified at
a node that has all fragments and is able to reassemble them so as to
recover the entire original payload.

In Appendix A you list several problems that "are known to plague
mutable canonicalization".  I wish to address each of these: 

1. I can't find the first problem that you list (the claim that there
are 3 fields in the wrong  order) in the current (05) I-D. Perhaps this
was a problem in a previous draft that has since  been fixed. If not,
can you please point out the page?

2. The second problem you list is contrived. I don't think it is fair
to fault the mutable  canonicalization algorithm for zeroing out
reserved bits that aren't yet used because they  may someday be used
and will at that point need to be protected. Of course if the reserved
bit become defined and they won't be mutable, the algorithm will need
to be changed to  protect them. The BSP says this itself on page 30:
"We omit the reserved flags because we  cannot determine if they will
change in transit. The masks specified above may have to be  revised if
additional flags are defined and they need to be protected."

3. The third problem that you cite is a complaint that the "bundle is a
fragment" bit is  unprotected. This bit is mutable. It can't be
protected with an end-to-end ciphersuite. What  alternative do you
suggest?

4. The fourth problem that you cite is that the canonicalization
procedure is too complex. Well,  it is complex, but we didn't
deliberately try to make it that way. It would be great if you  could
come up with a simpler alternative. 

Again, I'm not sure what was discussed at the previous DTNRG meeting
with regard to the  previous version of this checksum ciphersuite
draft, but it seems that what you really want  and need to is to have
checksum ciphersuites for both the BAB and the PSB and use them in
combination. At intermediate nodes, only the BAB ciphersuite could be
guaranteed to be  verified. The PIB ciphersuite could only be
guaranteed to be verified at the destination,  assuming all fragments
have been delivered there, or at intermediate nodes that have all
fragments and that can reassemble. There are probably other issues that
need to be addressed if you take this approach and I'm not claiming to
have thought it through completely, but it seems that this might be a
good direction to explore to get a best-fit solution to the problem
that you are trying to solve.

Thank you for acknowledging me in your draft. I hope my comments
continue to be helpful.
-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 Lloyd
Wood
>Sent: Saturday, March 01, 2008 4:52 PM
>To: Delay Tolerant Networking Interest List
>Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
>
>At Saturday 01/03/2008 18:24 +0000, Stephen Farrell wrote:
>>Lloyd Wood wrote:
>>> At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:
>>>> I was assuming we'd just have the chat without PPT since we
>>>> already had a presentation on this before - has it changed
>>>> significantly?
>>> 
>>> http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>>> 
>>> Yes, this draft has changed significantly. Good you asked, 
>otherwise the chairs and others might not be aware of this and 
>might not think to read this working group 
>>
>>This is not an IETF working group. Rather basic differences 
>exist between IRTF RGs and IETF WGs.
>
>Sorry, slip of the tongue. 'the -irtf- in the title indicates 
>it's been adopted as a *research* group... draft, which is 
>what I meant to indicate.
>
>You asked if this draft has changed. It has. My announcement 
>of the draft in:
>http://maillists.intel-research.net/pipermail/dtn-interest/2008
>-February/003020.html
>did not call out those changes. As I said below, my fault. I 
>didn't attempt to draw any attention to its content to attract 
>interest. So, here's a summary of the important bits.
>
>Even using the 'rework existing ciphersuites to add new 
>ciphersuites for reliability only' method that we've now 
>carefully explored in a couple of different ways before writing:
>http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>we've found a couple of problems that this approach cannot 
>solve, which the draft talks about:
>
>1. We've identified a problem with the concept of Custody 
>Transfer, in that unless the (nth) recipient along can be sure 
>it has the bundle unaltered and unerrored, its custody receipt 
>back to the n-1th node really isn't worth much. As it stands 
>in the existing Bundle Protocol, Custody Transfer ignores 
>errors creeping in, because it can't detect them. We think 
>Custody Transfer needs to have protection against errors to be 
>at all meaningful; a node can't detect errors with encrypted 
>bundles that it is relaying but doesn't have the keys for.
>
>2. We've identified cases where resends across the network are 
>possible much faster for reliability-only clear-ciphersuite 
>bundles than secured encrypted bundles, because a node along 
>the path can perform a end-to-end reliability check on the 
>clear bundle using the checksum, detect errors introduced 
>earlier, and get a resend of the bundle earlier with a tighter 
>and faster control loop. With encrypted payloads where 
>intermediate nodes don't have the keys, this check of the 
>payload is only possible at a node with the key, leading to a 
>longer control loop as the now-errored payload still has to be 
>forwarded to its security destination before the error can be 
>picked up. In disconnected DTNs, lengthening this loop is far 
>more significant than it is in the terrestrial internet where 
>added hops only add milliseconds (say, comparing the IPv4 
>at-every-node and IPv6-at-destination-only header checks). Use 
>of secured bundles can lead to a network performance problem 
>that discourages us!
> e of security or of third-party untrusted-node relaying of 
>secured bundles in DTNs. 
>
>So, in the approach in the draft, introducing reliability 
>without security to the Bundle Protocol for reliable, 
>unencrypted, payloads, brings benefits that security alone in 
>the BP can't have for encrypted payloads (meaningful Custody 
>Transfer, shortened control loops).
>
>We have identified two approaches to avoiding these two problems:
>
>A. End-to-end bundle security within an outer end-to-end 
>reliability wrapper for intermediate nodes use to to check 
>bundles and detect errors before forwarding is one way around 
>this performance problem, and it also makes for meaningful 
>Custody Transfer. This would be a major change in how the 
>bundle protocol is structured (analogous to the push/pop stuff 
>discussed with Peter on this list a while back, pushing an 
>outer e2e reliability checksum around an encrypted-e2e bundle 
>payload.) We haven't attempted to look at an implementation 
>that would do this in more detail.
>
>B. The other way around these two issues is to only ever 
>forward through trusted nodes which have all the keys, so that 
>those nodes can check the content for introduced errors (or 
>tampering) and where Custody Transfer becomes meaningful again 
>as bundles can be checked for errors before being relayed on, 
>with early resends requested in tighter control loops if 
>errors are detected.
>
>
>>And the sarcasm is neither welcome nor effective. It just makes
>>you look silly and IMO makes it less likely your ideas will gain
>>ready (or any) acceptance.
>
>The ideas should stand on their own merit - once they're 
>clearly presented and understood by the group. Our written 
>conclusions in this draft form the starting point for any 
>discussion at the meeting, and we can summarise them neatly 
>and concisely in pictures in five minutes before the 
>discussion. Believe me, the stuff you've just waded through 
>reading above, which took us months to be able to even 
>articulate, is better in pictures...
>
>L.
>
>>Stephen.
>>
>>> draft before the meeting. (My fault for assuming you'd read 
>the draft. We had to read your latest security drafts to write 
>it!) There's an important control loop/network performance 
>argument that needs to be presented and discussed.
>>
>>> 
>>> I include a copy of your latest agenda below, along with 
>drafts where I know them, which are always worth including in 
>the agendas. Reading the drafts before the talks increases 
>understanding immensely. A discussion without a talk on the 
>issues first, by those who have actually studied the issues 
>closely enough to write them down coherently, to attempt to 
>bring those who haven't up to speed and set the topics for 
>discussion is really not worth having. Well-thought-out 
>written arguments are the starting point for discussion here.
>>> 
>>> (The previous presentation in Chicago was on the very different
>>>  http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
>>> different name, different approach, completely rewritten since.)
>>> 
>>> L.
>>> 
>>> DTNRG IETF-71 Meeting
>>> 
>>> Last changed on 20080301
>>> 
>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in 
>the Franklin 5 room.
>>> 
>>> We're planning to do some BP/LTP interop starting on 
>Thursday after the meeting slot and continuing into Friday morning.
>>> Agenda
>>> Time    Topic   Who (link to slides)
>>> 0900-0905       Welcome & agenda bash   Chairs
>>> 0905-0930       DTNRG document status/news/interop plans    
>    Chairs & others
>>> 0940-1000       Security/Integrity chat         Howard Weiss (tbc)
>>>                       
>http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 
>needs presenting first
>>> 1000-1010       DTN reference code      Mike Demmer
>>> 1010-1020       Future reference implementation(s)      Chris Small
>>> 1020-1030       N4C project     Elwyn Davies/Avri Doria
>>>                       (related to 
>http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00 I'm guessing.)
>>> 1030-1040       UK-DMC  Will Ivancic
>>>                       (results from implementing 
>http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
>>> 1040-1050       Intentional Naming      Pritwish Basu
>>> 1050-1100       Using HTTP      Lloyd Wood
>>>                       
>http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
>>> 1100-1110       Telemetry Control Protocol      Mike Petkevich
>>> 1110-1130       DARPA DTN work  Preston Marshall
>>> 
>>>> S.
>>>>
>>>> PS: the 20 minutes left over was notional - I'd of course
>>>> forgotten a couple of slots that'd been requested earlier.
>>>> Now fixed. [1]
>>>>
>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>
>>>> Lloyd Wood wrote:
>>>>> Stephen,
>>>>>
>>>>> A presentation on the bundle reliability and performance 
>issues described in
>>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
>>>>> now it's been written up since the last RG meet as an 
>actual research group item, would be a very good idea. This is 
>important, and needs to be before Howie's tbc discussion. Wes 
>and/or I will present this.
>>>>>
>>>>> There is a spare 20 minutes in the agenda below, so this 
>can easily be accommodated.
>>>>>
>>>>> (and 'Bill' is Will Ivancic.)
>>>>>
>>>>> thanks,
>>>>>
>>>>> L.
>>>>>
>>>>> Draft agenda of 29 February:
>>>>> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>>
>>>>> Last changed on 20080229
>>>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, 
>in the Franklin 5 room.
>>>>> We're planning to do some BP/LTP interop starting on 
>Thursday after the meeting slot and continuing into Friday morning.
>>>>>
>>>>> 0900-0905 Welcome & agenda bash Chairs 
>>>>> 0905-0930 DTNRG document status/news/interop plans Chairs 
>& others 
>>>>> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
>>>>> 1000-1010 DTN reference code Mike Demmer 
>>>>> 1010-1020 Future reference implementation(s) Chris Small 
>>>>> 1020-1030 N4C project Elwyn Davies/Avri Doria 
>>>>> 1030-1040 UK-DMC Bill Ivancic 
>>>>> 1040-1055 Intentional Naming Pritwish Basu 
>>>>> 1055-1110 Using HTTP Lloyd Wood
>>>>>
>>>>> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
>>>>>
>>>>>> ...now posted. [1]
>>>>>>
>>>>>> Let Kevin & I know if you'd like any changes/additions.
>>>>>>
>>>>>> Cheers,
>>>>>> Stephen.
>>>>>>
>>>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>>
>>>>> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>> 
>>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

>>> 
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>> 
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
><http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Wed, 05 Mar 2008 17:45:54 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] seurity considerations
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Wednesday 05/03/2008 11:59 -0500, Symington, Susan F. wrote:
>Nasir,
>
>There are two security I-Ds for DTN. If you are not already familiar
>with them, they are:
>
>draft-irtf-dtnrg-sec-overview-04
>draft-irtf-dtnrg-bundle-security-05

See also
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
which comments extensively on the latter.

L.

>-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 
>>[email-masked]
>>Sent: Wednesday, March 05, 2008 9:48 AM
>>To: [email-masked]
>>Subject: seurity considerations
>>
>>Hello, 
>>I am looking into the security aspects of delay tolerant 
>>networks. I am thinking 
>>to work on the provision of a security architecture which will 
>>be able to meet minimum level 
>>of service. The assumptions can be very much restrict like, 
>>1. Attacker is very strong. He can do any thing to compromise 
>>the security of our network which can be a sensor network or internet.
>
>>2. Heterogeneous networks and also secure routers, gateways etc. 
>>3. The future internet will be compatible with our services. 
>>
>>For such a secure system, we will have to consider provision 
>>of security at all layers of network and as DTN will be overlay on 
>>existing internet, so we have to consider security aspects of 
>>underlying protocols as well. But, going towards wireless internet 
>>as sensor nodes information will be included in internet in 
>>future. Our security architecture will be able to provide the most 
>>security primitives like authentication, privacy, 
>>non-repudiation, data security etc. The provision of these 
>>services will use 
>>preventive as well as detection and recovery methods. I am thiinking, 
>>1. if we make a group which have target of security of DTN 
>>aware networks, we can progress well. 
>>2. If already such group, how I can know the present state of 
>>their work. As DTN work group website does not provide enought 
>>information. 
>>
>>best regards,
>>Nasir Mumtaz 
>>University of Surrey 
>>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

Content-class: urn:content-classes:message
Date: Wed, 5 Mar 2008 11:59:46 -0500
From: "Symington, Susan F." <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] seurity considerations
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Nasir,

There are two security I-Ds for DTN. If you are not already familiar
with them, they are:

draft-irtf-dtnrg-sec-overview-04
draft-irtf-dtnrg-bundle-security-05

-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 
>[email-masked]
>Sent: Wednesday, March 05, 2008 9:48 AM
>To: [email-masked]
>Subject: seurity considerations
>
>Hello, 
>I am looking into the security aspects of delay tolerant 
>networks. I am thinking 
>to work on the provision of a security architecture which will 
>be able to meet minimum level 
>of service. The assumptions can be very much restrict like, 
>1. Attacker is very strong. He can do any thing to compromise 
>the security of our network which can be a sensor network or internet.

>2. Heterogeneous networks and also secure routers, gateways etc. 
>3. The future internet will be compatible with our services. 
>
>For such a secure system, we will have to consider provision 
>of security at all layers of network and as DTN will be overlay on 
>existing internet, so we have to consider security aspects of 
>underlying protocols as well. But, going towards wireless internet 
>as sensor nodes information will be included in internet in 
>future. Our security architecture will be able to provide the most 
>security primitives like authentication, privacy, 
>non-repudiation, data security etc. The provision of these 
>services will use 
>preventive as well as detection and recovery methods. I am thiinking, 
>1. if we make a group which have target of security of DTN 
>aware networks, we can progress well. 
>2. If already such group, how I can know the present state of 
>their work. As DTN work group website does not provide enought 
>information. 
>
>best regards,
>Nasir Mumtaz 
>University of Surrey 
>

Date: Wed, 05 Mar 2008 15:09:22 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] seurity considerations
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Hi Nasir,

There's already a dtn-security mailing list that we used
before when doing the initial security work. If we're going
to be fairly active maybe we should start to use that again.

What do folks think? Probably worth a mention next week.

Stephen.

[email-masked] wrote:
> Hello, 
> I am looking into the security aspects of delay tolerant networks. I am thinking 
> to work on the provision of a security architecture which will be able to meet minimum level 
> of service. The assumptions can be very much restrict like, 
> 1. Attacker is very strong. He can do any thing to compromise the security of our network which can be a sensor network or internet. 
> 2. Heterogeneous networks and also secure routers, gateways etc. 
> 3. The future internet will be compatible with our services. 
> 
> For such a secure system, we will have to consider provision of security at all layers of network and as DTN will be overlay on 
> existing internet, so we have to consider security aspects of underlying protocols as well. But, going towards wireless internet 
> as sensor nodes information will be included in internet in future. Our security architecture will be able to provide the most 
> security primitives like authentication, privacy, non-repudiation, data security etc. The provision of these services will use 
> preventive as well as detection and recovery methods. I am thiinking, 
> 1. if we make a group which have target of security of DTN aware networks, we can progress well. 
> 2. If already such group, how I can know the present state of their work. As DTN work group website does not provide enought information. 
> 
> best regards,
> Nasir Mumtaz 
> University of Surrey 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Wed, 5 Mar 2008 14:48:05 -0000
From: <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] seurity considerations
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

This is a multi-part message in MIME format.

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

Hello,=20
I am looking into the security aspects of delay tolerant networks. I am =
thinking=20
to work on the provision of a security architecture which will be able =
to meet minimum level=20
of service. The assumptions can be very much restrict like,=20
1. Attacker is very strong. He can do any thing to compromise the =
security of our network which can be a sensor network or internet.=20
2. Heterogeneous networks and also secure routers, gateways etc.=20
3. The future internet will be compatible with our services.=20

For such a secure system, we will have to consider provision of security =
at all layers of network and as DTN will be overlay on=20
existing internet, so we have to consider security aspects of underlying =
protocols as well. But, going towards wireless internet=20
as sensor nodes information will be included in internet in future. Our =
security architecture will be able to provide the most=20
security primitives like authentication, privacy, non-repudiation, data =
security etc. The provision of these services will use=20
preventive as well as detection and recovery methods. I am thiinking,=20
1. if we make a group which have target of security of DTN aware =
networks, we can progress well.=20
2. If already such group, how I can know the present state of their =
work. As DTN work group website does not provide enought information.=20

best regards,
Nasir Mumtaz=20
University of Surrey=20

------_=_NextPart_001_01C87ECF.EB918622
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C87ECF.EB918622--

From: Hans Kruse <[email-masked]>
Date: Tue, 4 Mar 2008 08:01:28 -0500
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] free beer (and the future of the DTN reference implementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Same for me -- I am planning to attend Thursday only but won't leave  
until Friday (very am).

On Mar 3, 2008, at 7:41 PM, Scott Burleigh wrote:

> Christopher Small wrote:
>> I'm organizing a relaxed discussion / bull session at IETF to discuss
>> the future of the DTN reference implementation. (More below.) I'll  
>> buy
>> the beer (or, at the very least, the first round). If you're  
>> interested
>> in participating in the discussion, please let me know if you can  
>> make
>> it (a) Wednesday evening, (b) Thursday evening, or (c) either one,  
>> given
>> advanced notice.
>>
> I should be there for Thursday evening, but not Wednesday.
>
> Scott
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

Content-class: urn:content-classes:message
Date: Mon, 3 Mar 2008 21:54:23 -0600
From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
To: "Delay Tolerant Networking Interest List" <[email-masked]>
Subject: Re: [dtn-interest] free beer (and the future of the DTN referenceimplementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

If you hold it after the Plenary and it is at a Bar with food, that
would be good.

Thursday may be better and it would be good is Scott were there.
Depending on how NASA funding flows, we may have some options.  I think
University maintenance would be best for a number of reasons we can
discuss.  Ohio University may be interested.  I'll have to check.

/Will
NASA Glenn

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Christopher Small
> Sent: Monday, March 03, 2008 4:58 PM
> To: Delay Tolerant Networking Interest List
> Subject: [dtn-interest] free beer (and the future of the DTN 
> referenceimplementation)
> 
> I'm organizing a relaxed discussion / bull session at IETF to 
> discuss the future of the DTN reference implementation. .....

Date: Mon, 03 Mar 2008 16:41:48 -0800
From: Scott Burleigh <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] free beer (and the future of the DTN reference implementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Christopher Small wrote:
> I'm organizing a relaxed discussion / bull session at IETF to discuss 
> the future of the DTN reference implementation. (More below.) I'll buy 
> the beer (or, at the very least, the first round). If you're interested 
> in participating in the discussion, please let me know if you can make 
> it (a) Wednesday evening, (b) Thursday evening, or (c) either one, given 
> advanced notice.
>   
I should be there for Thursday evening, but not Wednesday.

Scott

Date: Mon, 03 Mar 2008 16:58:02 -0500
From: Christopher Small <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] free beer (and the future of the DTN reference implementation)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I'm organizing a relaxed discussion / bull session at IETF to discuss 
the future of the DTN reference implementation. (More below.) I'll buy 
the beer (or, at the very least, the first round). If you're interested 
in participating in the discussion, please let me know if you can make 
it (a) Wednesday evening, (b) Thursday evening, or (c) either one, given 
advanced notice.

The topic of discussion (for which I also have a slot at the meeting) is 
as follows:

DTN2, the reference implementation, has been a tremendous success. 
People are using it in several research projects, DARPA funded a major 
refactoring to make experimentation easier, Mike Demmer, the primary 
author, has been working long hours and writing reams of code.  But what 
of the future? At some point Mike will graduate and (probably) not be 
able to spend as much time maintaining DTN2. DARPA's mission is to speed 
the maturation of nascent technology, not support it forever.

What will happen to the reference implementation? The community has 
benefited greatly from all the work that has gone into DTN2. What can we 
do to make sure that the work continues? Will an army of volunteers take 
it over? Or will it be pushed out to Sourceforge, and left to fend for 
itself?

And tightly linked to that question is what we, as a community, want the 
reference implementation to do for us, going forward. There are a number 
of (contradictory) roles that it could play, including being a platform 
for experimenting with the protocol, as a platform for experimenting 
with routing, as a teaching tool for understanding how the bundle 
protocol works, and use as a building block for constructing DTNs. Which 
way shall we steer the RI?

So, let me know if you'd like to participate in a relaxed discussion of 
these issues, and when you could make it. I'll try to find a suitable 
venue (i.e. good beer and not far from the site) and will pass along 
details (either via email if we meet on Wednesday evening, or at the 
DTNRG meeting if we meet on Thursday evening).

- Chris

-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research                           617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Date: Sun, 2 Mar 2008 12:07:11 -0800 (PST)
From: Golnaz Honarpisheh <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] (no subject)
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

--0-1923865501-1204488431=:8292
Content-Type: text/plain; charset=us-ascii

I am interested to get these documents by email.
Thanks

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

--0-1923865501-1204488431=:8292
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>I am interested to get these documents by email.</DIV>
<DIV>Thanks</DIV></div><br>
      <hr size=1>Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile. <a href="http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ "> Try it now.</a></body></html>
--0-1923865501-1204488431=:8292--

Date: Sun, 02 Mar 2008 01:16:09 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] noting UK DTN PhD place
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

http://www.jobs.ac.uk/jobs/ZH402/EPSRC_PhD_Studentship/
http://www.wanrg.cs.nott.ac.uk/op.html

I see that there's a new PhD studentship in DTN routing going at the University of Nottingham, UK; closes for applications end of the month. Hadn't seen any mention previously on this list (though there was mention to this list of another place in the same group back in April 2006). DTN research places are imo still rare enough to be worth noting; DTN research places outside the US doubly so.

cheers,

L.

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

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

Date: Sun, 02 Mar 2008 00:32:07 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Saturday 01/03/2008 23:35 +0000, Stephen Farrell wrote:
>Lloyd Wood wrote:
>>> And the sarcasm is neither welcome nor effective. It just makes
>>> you look silly and IMO makes it less likely your ideas will gain
>>> ready (or any) acceptance.
>> 
>> The ideas should stand on their own merit 
>
>They do that much better if properly presented, rather
>than being served with repetitious acrimony.

Stephen, I think you're reading far too much into anything I write.

So we agree that proper presentation of these ideas at the meeting is a good idea, then.
http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
I'm looking forward to your thoughtful comments on the ideas.

L.

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

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

Date: Sat, 01 Mar 2008 23:35:55 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Lloyd Wood wrote:
>> And the sarcasm is neither welcome nor effective. It just makes
>> you look silly and IMO makes it less likely your ideas will gain
>> ready (or any) acceptance.
> 
> The ideas should stand on their own merit 

They do that much better if properly presented, rather
than being served with repetitious acrimony.
S.

Date: Sat, 01 Mar 2008 21:52:08 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Saturday 01/03/2008 18:24 +0000, Stephen Farrell wrote:
>Lloyd Wood wrote:
>> At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:
>>> I was assuming we'd just have the chat without PPT since we
>>> already had a presentation on this before - has it changed
>>> significantly?
>> 
>> http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
>> 
>> Yes, this draft has changed significantly. Good you asked, otherwise the chairs and others might not be aware of this and might not think to read this working group 
>
>This is not an IETF working group. Rather basic differences exist between IRTF RGs and IETF WGs.

Sorry, slip of the tongue. 'the -irtf- in the title indicates it's been adopted as a *research* group... draft, which is what I meant to indicate.

You asked if this draft has changed. It has. My announcement of the draft in:
http://maillists.intel-research.net/pipermail/dtn-interest/2008-February/003020.html
did not call out those changes. As I said below, my fault. I didn't attempt to draw any attention to its content to attract interest. So, here's a summary of the important bits.

Even using the 'rework existing ciphersuites to add new ciphersuites for reliability only' method that we've now carefully explored in a couple of different ways before writing:
http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
we've found a couple of problems that this approach cannot solve, which the draft talks about:

1. We've identified a problem with the concept of Custody Transfer, in that unless the (nth) recipient along can be sure it has the bundle unaltered and unerrored, its custody receipt back to the n-1th node really isn't worth much. As it stands in the existing Bundle Protocol, Custody Transfer ignores errors creeping in, because it can't detect them. We think Custody Transfer needs to have protection against errors to be at all meaningful; a node can't detect errors with encrypted bundles that it is relaying but doesn't have the keys for.

2. We've identified cases where resends across the network are possible much faster for reliability-only clear-ciphersuite bundles than secured encrypted bundles, because a node along the path can perform a end-to-end reliability check on the clear bundle using the checksum, detect errors introduced earlier, and get a resend of the bundle earlier with a tighter and faster control loop. With encrypted payloads where intermediate nodes don't have the keys, this check of the payload is only possible at a node with the key, leading to a longer control loop as the now-errored payload still has to be forwarded to its security destination before the error can be picked up. In disconnected DTNs, lengthening this loop is far more significant than it is in the terrestrial internet where added hops only add milliseconds (say, comparing the IPv4 at-every-node and IPv6-at-destination-only header checks). Use of secured bundles can lead to a network performance problem that discourages use of security or of third-party untrusted-node relaying of secured bundles in DTNs. 

So, in the approach in the draft, introducing reliability without security to the Bundle Protocol for reliable, unencrypted, payloads, brings benefits that security alone in the BP can't have for encrypted payloads (meaningful Custody Transfer, shortened control loops).

We have identified two approaches to avoiding these two problems:

A. End-to-end bundle security within an outer end-to-end reliability wrapper for intermediate nodes use to to check bundles and detect errors before forwarding is one way around this performance problem, and it also makes for meaningful Custody Transfer. This would be a major change in how the bundle protocol is structured (analogous to the push/pop stuff discussed with Peter on this list a while back, pushing an outer e2e reliability checksum around an encrypted-e2e bundle payload.) We haven't attempted to look at an implementation that would do this in more detail.

B. The other way around these two issues is to only ever forward through trusted nodes which have all the keys, so that those nodes can check the content for introduced errors (or tampering) and where Custody Transfer becomes meaningful again as bundles can be checked for errors before being relayed on, with early resends requested in tighter control loops if errors are detected.

>And the sarcasm is neither welcome nor effective. It just makes
>you look silly and IMO makes it less likely your ideas will gain
>ready (or any) acceptance.

The ideas should stand on their own merit - once they're clearly presented and understood by the group. Our written conclusions in this draft form the starting point for any discussion at the meeting, and we can summarise them neatly and concisely in pictures in five minutes before the discussion. Believe me, the stuff you've just waded through reading above, which took us months to be able to even articulate, is better in pictures...

L.

>Stephen.
>
>> draft before the meeting. (My fault for assuming you'd read the draft. We had to read your latest security drafts to write it!) There's an important control loop/network performance argument that needs to be presented and discussed.
>
>> 
>> I include a copy of your latest agenda below, along with drafts where I know them, which are always worth including in the agendas. Reading the drafts before the talks increases understanding immensely. A discussion without a talk on the issues first, by those who have actually studied the issues closely enough to write them down coherently, to attempt to bring those who haven't up to speed and set the topics for discussion is really not worth having. Well-thought-out written arguments are the starting point for discussion here.
>> 
>> (The previous presentation in Chicago was on the very different
>>  http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
>> different name, different approach, completely rewritten since.)
>> 
>> L.
>> 
>> DTNRG IETF-71 Meeting
>> 
>> Last changed on 20080301
>> 
>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>> 
>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>> Agenda
>> Time    Topic   Who (link to slides)
>> 0900-0905       Welcome & agenda bash   Chairs
>> 0905-0930       DTNRG document status/news/interop plans        Chairs & others
>> 0940-1000       Security/Integrity chat         Howard Weiss (tbc)
>>                       http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 needs presenting first
>> 1000-1010       DTN reference code      Mike Demmer
>> 1010-1020       Future reference implementation(s)      Chris Small
>> 1020-1030       N4C project     Elwyn Davies/Avri Doria
>>                       (related to http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00 I'm guessing.)
>> 1030-1040       UK-DMC  Will Ivancic
>>                       (results from implementing http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
>> 1040-1050       Intentional Naming      Pritwish Basu
>> 1050-1100       Using HTTP      Lloyd Wood
>>                       http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
>> 1100-1110       Telemetry Control Protocol      Mike Petkevich
>> 1110-1130       DARPA DTN work  Preston Marshall
>> 
>>> S.
>>>
>>> PS: the 20 minutes left over was notional - I'd of course
>>> forgotten a couple of slots that'd been requested earlier.
>>> Now fixed. [1]
>>>
>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>
>>> Lloyd Wood wrote:
>>>> Stephen,
>>>>
>>>> A presentation on the bundle reliability and performance issues described in
>>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
>>>> now it's been written up since the last RG meet as an actual research group item, would be a very good idea. This is important, and needs to be before Howie's tbc discussion. Wes and/or I will present this.
>>>>
>>>> There is a spare 20 minutes in the agenda below, so this can easily be accommodated.
>>>>
>>>> (and 'Bill' is Will Ivancic.)
>>>>
>>>> thanks,
>>>>
>>>> L.
>>>>
>>>> Draft agenda of 29 February:
>>>> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>
>>>> Last changed on 20080229
>>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>>>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>>>>
>>>> 0900-0905 Welcome & agenda bash Chairs 
>>>> 0905-0930 DTNRG document status/news/interop plans Chairs & others 
>>>> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
>>>> 1000-1010 DTN reference code Mike Demmer 
>>>> 1010-1020 Future reference implementation(s) Chris Small 
>>>> 1020-1030 N4C project Elwyn Davies/Avri Doria 
>>>> 1030-1040 UK-DMC Bill Ivancic 
>>>> 1040-1055 Intentional Naming Pritwish Basu 
>>>> 1055-1110 Using HTTP Lloyd Wood
>>>>
>>>> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
>>>>
>>>>> ...now posted. [1]
>>>>>
>>>>> Let Kevin & I know if you'd like any changes/additions.
>>>>>
>>>>> Cheers,
>>>>> Stephen.
>>>>>
>>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>>
>>>> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
>> 
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

Date: Sat, 01 Mar 2008 18:24:30 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

Lloyd,

Lloyd Wood wrote:
> At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:
> 
>> I was assuming we'd just have the chat without PPT since we
>> already had a presentation on this before - has it changed
>> significantly?
> 
> http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt
> 
> Yes, this draft has changed significantly. Good you asked, otherwise the chairs and others might not be aware of this and might not think to read this working group 

This is not an IETF working group. Rather basic differences exist
between IRTF RGs and IETF WGs.

And the sarcasm is neither welcome nor effective. It just makes
you look silly and IMO makes it less likely your ideas will gain
ready (or any) acceptance.

Stephen.

> draft before the meeting. (My fault for assuming you'd read the draft. We had to read your latest security drafts to write it!) There's an important control loop/network performance argument that needs to be presented and discussed.

> 
> I include a copy of your latest agenda below, along with drafts where I know them, which are always worth including in the agendas. Reading the drafts before the talks increases understanding immensely. A discussion without a talk on the issues first, by those who have actually studied the issues closely enough to write them down coherently, to attempt to bring those who haven't up to speed and set the topics for discussion is really not worth having. Well-thought-out written arguments are the starting point for discussion here.
> 
> (The previous presentation in Chicago was on the very different
>  http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
> different name, different approach, completely rewritten since.)
> 
> L.
> 
> DTNRG IETF-71 Meeting
> 
> Last changed on 20080301
> 
> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
> 
> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
> Agenda
> Time    Topic   Who (link to slides)
> 0900-0905       Welcome & agenda bash   Chairs
> 0905-0930       DTNRG document status/news/interop plans        Chairs & others
> 0940-1000       Security/Integrity chat         Howard Weiss (tbc)
>                       http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 needs presenting first
> 1000-1010       DTN reference code      Mike Demmer
> 1010-1020       Future reference implementation(s)      Chris Small
> 1020-1030       N4C project     Elwyn Davies/Avri Doria
>                       (related to http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00  I'm guessing.)
> 1030-1040       UK-DMC  Will Ivancic
>                       (results from implementing http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
> 1040-1050       Intentional Naming      Pritwish Basu
> 1050-1100       Using HTTP      Lloyd Wood
>                       http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
> 1100-1110       Telemetry Control Protocol      Mike Petkevich
> 1110-1130       DARPA DTN work  Preston Marshall
> 
>> S.
>>
>> PS: the 20 minutes left over was notional - I'd of course
>> forgotten a couple of slots that'd been requested earlier.
>> Now fixed. [1]
>>
>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>
>> Lloyd Wood wrote:
>>> Stephen,
>>>
>>> A presentation on the bundle reliability and performance issues described in
>>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
>>> now it's been written up since the last RG meet as an actual research group item, would be a very good idea. This is important, and needs to be before Howie's tbc discussion. Wes and/or I will present this.
>>>
>>> There is a spare 20 minutes in the agenda below, so this can easily be accommodated.
>>>
>>> (and 'Bill' is Will Ivancic.)
>>>
>>> thanks,
>>>
>>> L.
>>>
>>> Draft agenda of 29 February:
>>> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>
>>> Last changed on 20080229
>>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>>>
>>> 0900-0905 Welcome & agenda bash Chairs 
>>> 0905-0930 DTNRG document status/news/interop plans Chairs & others 
>>> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
>>> 1000-1010 DTN reference code Mike Demmer 
>>> 1010-1020 Future reference implementation(s) Chris Small 
>>> 1020-1030 N4C project Elwyn Davies/Avri Doria 
>>> 1030-1040 UK-DMC Bill Ivancic 
>>> 1040-1055 Intentional Naming Pritwish Basu 
>>> 1055-1110 Using HTTP Lloyd Wood
>>>
>>> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
>>>
>>>> ...now posted. [1]
>>>>
>>>> Let Kevin & I know if you'd like any changes/additions.
>>>>
>>>> Cheers,
>>>> Stephen.
>>>>
>>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>>>
>>> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> <http://info.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Sat, 01 Mar 2008 16:26:22 +0000
To: Delay Tolerant Networking Interest List <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

At Saturday 01/03/2008 12:23 +0000, Stephen Farrell wrote:

>I was assuming we'd just have the chat without PPT since we
>already had a presentation on this before - has it changed
>significantly?

http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-checksum-01.txt

Yes, this draft has changed significantly. Good you asked, otherwise the chairs and others might not be aware of this and might not think to read this working group draft before the meeting. (My fault for assuming you'd read the draft. We had to read your latest security drafts to write it!) There's an important control loop/network performance argument that needs to be presented and discussed.

I include a copy of your latest agenda below, along with drafts where I know them, which are always worth including in the agendas. Reading the drafts before the talks increases understanding immensely. A discussion without a talk on the issues first, by those who have actually studied the issues closely enough to write them down coherently, to attempt to bring those who haven't up to speed and set the topics for discussion is really not worth having. Well-thought-out written arguments are the starting point for discussion here.

(The previous presentation in Chicago was on the very different
 http://tools.ietf.org/html/draft-eddy-dtnrg-checksum-00
different name, different approach, completely rewritten since.)

L.

DTNRG IETF-71 Meeting

Last changed on 20080301

Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.

We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
Agenda
Time    Topic   Who (link to slides)
0900-0905       Welcome & agenda bash   Chairs
0905-0930       DTNRG document status/news/interop plans        Chairs & others
0940-1000       Security/Integrity chat         Howard Weiss (tbc)
                      http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01 needs presenting first
1000-1010       DTN reference code      Mike Demmer
1010-1020       Future reference implementation(s)      Chris Small
1020-1030       N4C project     Elwyn Davies/Avri Doria
                      (related to http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-00  I'm guessing.)
1030-1040       UK-DMC  Will Ivancic
                      (results from implementing http://tools.ietf.org/html/draft-wood-dtnrg-saratoga-03 from orbit)
1040-1050       Intentional Naming      Pritwish Basu
1050-1100       Using HTTP      Lloyd Wood
                      http://tools.ietf.org/html/draft-wood-dtrng-http-dtn-delivery-01
1100-1110       Telemetry Control Protocol      Mike Petkevich
1110-1130       DARPA DTN work  Preston Marshall

>S.
>
>PS: the 20 minutes left over was notional - I'd of course
>forgotten a couple of slots that'd been requested earlier.
>Now fixed. [1]
>
>[1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>
>Lloyd Wood wrote:
>> Stephen,
>> 
>> A presentation on the bundle reliability and performance issues described in
>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
>> now it's been written up since the last RG meet as an actual research group item, would be a very good idea. This is important, and needs to be before Howie's tbc discussion. Wes and/or I will present this.
>> 
>> There is a spare 20 minutes in the agenda below, so this can easily be accommodated.
>> 
>> (and 'Bill' is Will Ivancic.)
>> 
>> thanks,
>> 
>> L.
>> 
>> Draft agenda of 29 February:
>> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>> 
>> Last changed on 20080229
>> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
>> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
>> 
>> 0900-0905 Welcome & agenda bash Chairs 
>> 0905-0930 DTNRG document status/news/interop plans Chairs & others 
>> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
>> 1000-1010 DTN reference code Mike Demmer 
>> 1010-1020 Future reference implementation(s) Chris Small 
>> 1020-1030 N4C project Elwyn Davies/Avri Doria 
>> 1030-1040 UK-DMC Bill Ivancic 
>> 1040-1055 Intentional Naming Pritwish Basu 
>> 1055-1110 Using HTTP Lloyd Wood
>> 
>> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
>> 
>>> ...now posted. [1]
>>>
>>> Let Kevin & I know if you'd like any changes/additions.
>>>
>>> Cheers,
>>> Stephen.
>>>
>>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
>> 
>> 
>> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> 
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

Date: Sat, 01 Mar 2008 12:23:20 +0000
From: Stephen Farrell <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Draft DTNRG Philly Agenda...
Reply-To: Delay Tolerant Networking Interest List <[email-masked]>

I was assuming we'd just have the chat without PPT since we
already had a presentation on this before - has it changed
significantly?

S.

PS: the 20 minutes left over was notional - I'd of course
forgotten a couple of slots that'd been requested earlier.
Now fixed. [1]

[1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html

Lloyd Wood wrote:
> Stephen,
> 
> A presentation on the bundle reliability and performance issues described in
> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-01
> now it's been written up since the last RG meet as an actual research group item, would be a very good idea. This is important, and needs to be before Howie's tbc discussion. Wes and/or I will present this.
> 
> There is a spare 20 minutes in the agenda below, so this can easily be accommodated.
> 
> (and 'Bill' is Will Ivancic.)
> 
> thanks,
> 
> L.
> 
> Draft agenda of 29 February:
> http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
> 
> Last changed on 20080229
> Our meeting slot is THURSDAY 0900-1130, March 13, 2008, in the Franklin 5 room.
> We're planning to do some BP/LTP interop starting on Thursday after the meeting slot and continuing into Friday morning.
> 
> 0900-0905 Welcome & agenda bash Chairs 
> 0905-0930 DTNRG document status/news/interop plans Chairs & others 
> 0940-1000 Security/Integrity chat Howard Weiss (tbc) 
> 1000-1010 DTN reference code Mike Demmer 
> 1010-1020 Future reference implementation(s) Chris Small 
> 1020-1030 N4C project Elwyn Davies/Avri Doria 
> 1030-1040 UK-DMC Bill Ivancic 
> 1040-1055 Intentional Naming Pritwish Basu 
> 1055-1110 Using HTTP Lloyd Wood
> 
> At Friday 29/02/2008 18:05 +0000, Stephen Farrell wrote:
> 
>> ...now posted. [1]
>>
>> Let Kevin & I know if you'd like any changes/additions.
>>
>> Cheers,
>> Stephen.
>>
>> [1] http://www.ietf.org/proceedings/08mar/agenda/DTNRG.html
> 
> 
> Saratoga: 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://maillists.intel-research.net/mailman/listinfo/dtn-interest
>