Subject: [dtn-interest] Re(2): mutable EIDs; a general rule would be nice
From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, Susan <[email-masked]>
Cc: dtn interest <[email-masked]>
Date: Mon, 29 Sep 2008 18:45:24 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

Hi all,

one interesting thought is to split the fixed and mutable parts. I'm not
quite sure how to do that easily but Stephen's comment about dictionary-
partitioning is interesting. 

Another is to specify [tbd] the length of the fixed portion and digest
only that much. A special scheme perhaps, encapsulating (prefix) the
regular EID?

A third, less attractive, would be to have the EID be a reference to the
real address in an extension block. That would require all nodes to be
aware of the redirection thing -- not a good thought right now.

Cheers.....Peter

On Mon, Sep 29, 2008, Stephen Farrell <[email-masked]> wrote:

>
>As you might have guessed from the fact that Susan included an
>example of mine, I agree with the goal of allowing mutable parts
>of EIDs. It looks quite useful and it appears that at least
>two of us have independently come up with the requirement at
>roughly the same time.
>
>I also agree that it'd be great if the BSP integrity ciphersuites
>(and hence I guess any e2e checksums) worked well with mutable
>EIDs.
>
>However, I do doubt that we can agree a single scheme for
>splitting any EID into mutable and immutable parts (which
>need not partition nicely, e.g. with those awful BiDi
>strings or moral equivalents). I guess I just don't think
>we're far enough along with broadly accepted concrete naming
>schemes to get this done right now.
>
>If I'm wrong, great. However, I suspect at this stage we
>might have to live without support for mixing mutable
>EIDs and integrity in a single bundle.
>
>Stephen.
>
>PS: This reminds me of a (rejected:-) proposal I made (for
>different reasons) for partitioning up the dictionary - a
>kludge like that might sort-of work, if someone needed both
>mutable EIDs and security right now.
>
>Symington, Susan F. wrote:
>> The Bundle Protocol defines EIDs to have the general structure of
>> 
>> < scheme name > : < scheme-specific part >, says that the scheme is the
>> set of rules for parsing and interpreting the SSP, and pretty much
>> leaves things open from there.
>> 
>>  
>> 
>> In the Bundle Security Protocol (BSP), as currently drafted, we assume
>> that EIDs are non-mutable. However, this is not necessarily a valid
>> assumption. One may want to have a scheme that defines an SSP that has
>> both a non-mutable portion and a mutable portion. The mutable portion
>> might be used for purposes of mobility. Stephen Farrell offers the
>> following example of a possible EID:
>> 
>>  
>> 
>> "dtn://foo.bar/baz?LASTSEENAT=10.0.0.1"
>> 
>>  
>> 
>> where "LASTSEENAT=10.0.0.1" is a mutable part. (The exact definition of
>> the scheme is not what is important at this point. What is important is
>> that we recognize that EIDs may have non-mutable parts and we make sure
>> that the specifications are written correctly so as to allow for this
>> possibility.)
>> 
>>  
>> 
>> As far as the BSP is concerned, we need to revise the mutable
>> canonicalization section of the BSP to allow for the possibility that
>> EIDs may have mutable parts, because these parts of the EIDs will need
>> to be left out of the mutable canonical form. Making this change is not
>> difficult and in fact attached is a draft set of revisions for doing so.
>> What does get tricky, though, is that if every scheme has a different
>> way of denoting which parts of the EID are mutable and which are
>> non-mutable, then any given implementation of the BSP would have to be
>> equipped with a different set of rules for how to perform the
>> canonicalization for each scheme. If scheme Alpha says that all
>> characters that follow the "|" character in the SSP are mutable, then
>> the BSP needs to know that for this scheme, all characters that follow
>> the "|" in the SSP get left out of the mutable canonical form of the
>> primary bundle block. If scheme Beta says that all characters that
>> follow the  "?" character are mutable, then the BSP would have to know
>> that for this scheme, all characters that follow the "?" in the SSP get
>> left out of the mutable canonical form of the primary bundle block.
>>  Clearly, this is undesirable; we don't want to have to make changes to
>> BSP implementations every time a new scheme is defined.
>> 
>>  
>> 
>> It would be a lot nicer if we could agree on a general rule that all
>> EIDs would follow for how to indicate which parts of an EID are mutable
>> and which are non-mutable.
>> 
>>  
>> 
>> Attached is a word file that contains the revisions that I believe are
>> needed to the BSP to enable security to work the way we intend for it to
>> work even if EIDs are mutable. These revisions apply only to the BSP so
>> if you aren't particularly interested in security, then you may not be
>> interested in them. What should be of general interest though, is that
>> we have identified a need to define a general mechanism that all schemes
>> should use to indicate what parts of an SSP are mutable (if any). I hope
>> we can agree that one is needed and choose one.
>> 
>>  
>> 
>> If you wish to reply and comment on the actual revisions to the BSP that
>> are attached, I think we should conduct that discussion on the
>> dtn-security list, so please send those responses to dtn-security
>> instead of  dtn-interest.
>> 
>>  
>> 
>> If you wish to reply regarding the need to define and agree on a
>> convention that all schemes will follow to denote which parts of their
>> SSPs are mutable, then that discussion should probably stay here in
>> dtn-interest.
>> 
>>  
>> 
>> Thanks.
>> 
>>  
>> 
>> -susan
>> 
>> *****************************************************************
>> 
>> Susan Symington
>> 
>> The MITRE Corporation
>> 
>> [email-masked]
>> 
>> 703-983-7209 (voice)
>> 
>> 703-983-7142 (fax)
>> 
>> ******************************************************************
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> 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: Mon, 29 Sep 2008 17:41:34 -0400
From: "Rajesh Krishnan" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] mutable EIDs; a general rule would be nice

Susan,

Is there a requirement from any DTN stakeholders to record, protect,
and carry end-to-end the entire destination EID (with all attributes
intact) exactly as specified by the source?   For example, recovery
from mis-routing might need this.

An alternative is to hold the mutations -- with audit records per
mutation if needed -- in a meta-data extension block.   Definitely not
as nice as encoding mutables in the EID :(

Best Regards,
Rajesh

On Mon, Sep 29, 2008 at 4:26 PM, Symington, Susan F. <[email-masked]> wrote:
> The Bundle Protocol defines EIDs to have the general structure of
>
> < scheme name > : < scheme-specific part >, says that the scheme is the set
> of rules for parsing and interpreting the SSP, and pretty much leaves things
> open from there.
>
>
>
> In the Bundle Security Protocol (BSP), as currently drafted, we assume that
> EIDs are non-mutable. However, this is not necessarily a valid assumption.
> One may want to have a scheme that defines an SSP that has both a
> non-mutable portion and a mutable portion. The mutable portion might be used
> for purposes of mobility. Stephen Farrell offers the following example of a
> possible EID:
>
>
>
> "dtn://foo.bar/baz?LASTSEENAT=10.0.0.1"
>
>
>
> where "LASTSEENAT=10.0.0.1" is a mutable part. (The exact definition of the
> scheme is not what is important at this point. What is important is that we
> recognize that EIDs may have non-mutable parts and we make sure that the
> specifications are written correctly so as to allow for this possibility.)
>
>
>
> As far as the BSP is concerned, we need to revise the mutable
> canonicalization section of the BSP to allow for the possibility that EIDs
> may have mutable parts, because these parts of the EIDs will need to be left
> out of the mutable canonical form. Making this change is not difficult and
> in fact attached is a draft set of revisions for doing so. What does get
> tricky, though, is that if every scheme has a different way of denoting
> which parts of the EID are mutable and which are non-mutable, then any given
> implementation of the BSP would have to be equipped with a different set of
> rules for how to perform the canonicalization for each scheme. If scheme
> Alpha says that all characters that follow the "|" character in the SSP are
> mutable, then the BSP needs to know that for this scheme, all characters
> that follow the "|" in the SSP get left out of the mutable canonical form of
> the primary bundle block. If scheme Beta says that all characters that
> follow the  "?" character are mutable, then the BSP would have to know that
> for this scheme, all characters that follow the "?" in the SSP get left out
> of the mutable canonical form of the primary bundle block.  Clearly, this is
> undesirable; we don't want to have to make changes to BSP implementations
> every time a new scheme is defined.
>
>
>
> It would be a lot nicer if we could agree on a general rule that all EIDs
> would follow for how to indicate which parts of an EID are mutable and which
> are non-mutable.
>
>
>
> Attached is a word file that contains the revisions that I believe are
> needed to the BSP to enable security to work the way we intend for it to
> work even if EIDs are mutable. These revisions apply only to the BSP so if
> you aren't particularly interested in security, then you may not be
> interested in them. What should be of general interest though, is that we
> have identified a need to define a general mechanism that all schemes should
> use to indicate what parts of an SSP are mutable (if any). I hope we can
> agree that one is needed and choose one.
>
>
>
> If you wish to reply and comment on the actual revisions to the BSP that are
> attached, I think we should conduct that discussion on the dtn-security
> list, so please send those responses to dtn-security instead of
>  dtn-interest.
>
>
>
> If you wish to reply regarding the need to define and agree on a convention
> that all schemes will follow to denote which parts of their SSPs are
> mutable, then that discussion should probably stay here in dtn-interest.
>
>
>
> Thanks.
>
>
>
> -susan
>
> *****************************************************************
>
> Susan Symington
>
> The MITRE Corporation
>
> [email-masked]
>
> 703-983-7209 (voice)
>
> 703-983-7142 (fax)
>
> ******************************************************************
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

Date: Mon, 29 Sep 2008 22:29:16 +0100
From: Stephen Farrell <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] mutable EIDs; a general rule would be nice

As you might have guessed from the fact that Susan included an
example of mine, I agree with the goal of allowing mutable parts
of EIDs. It looks quite useful and it appears that at least
two of us have independently come up with the requirement at
roughly the same time.

I also agree that it'd be great if the BSP integrity ciphersuites
(and hence I guess any e2e checksums) worked well with mutable
EIDs.

However, I do doubt that we can agree a single scheme for
splitting any EID into mutable and immutable parts (which
need not partition nicely, e.g. with those awful BiDi
strings or moral equivalents). I guess I just don't think
we're far enough along with broadly accepted concrete naming
schemes to get this done right now.

If I'm wrong, great. However, I suspect at this stage we
might have to live without support for mixing mutable
EIDs and integrity in a single bundle.

Stephen.

PS: This reminds me of a (rejected:-) proposal I made (for
different reasons) for partitioning up the dictionary - a
kludge like that might sort-of work, if someone needed both
mutable EIDs and security right now.

Symington, Susan F. wrote:
> The Bundle Protocol defines EIDs to have the general structure of
> 
> < scheme name > : < scheme-specific part >, says that the scheme is the
> set of rules for parsing and interpreting the SSP, and pretty much
> leaves things open from there.
> 
>  
> 
> In the Bundle Security Protocol (BSP), as currently drafted, we assume
> that EIDs are non-mutable. However, this is not necessarily a valid
> assumption. One may want to have a scheme that defines an SSP that has
> both a non-mutable portion and a mutable portion. The mutable portion
> might be used for purposes of mobility. Stephen Farrell offers the
> following example of a possible EID:
> 
>  
> 
> "dtn://foo.bar/baz?LASTSEENAT=10.0.0.1"
> 
>  
> 
> where "LASTSEENAT=10.0.0.1" is a mutable part. (The exact definition of
> the scheme is not what is important at this point. What is important is
> that we recognize that EIDs may have non-mutable parts and we make sure
> that the specifications are written correctly so as to allow for this
> possibility.)
> 
>  
> 
> As far as the BSP is concerned, we need to revise the mutable
> canonicalization section of the BSP to allow for the possibility that
> EIDs may have mutable parts, because these parts of the EIDs will need
> to be left out of the mutable canonical form. Making this change is not
> difficult and in fact attached is a draft set of revisions for doing so.
> What does get tricky, though, is that if every scheme has a different
> way of denoting which parts of the EID are mutable and which are
> non-mutable, then any given implementation of the BSP would have to be
> equipped with a different set of rules for how to perform the
> canonicalization for each scheme. If scheme Alpha says that all
> characters that follow the “|” character in the SSP are mutable, then
> the BSP needs to know that for this scheme, all characters that follow
> the “|” in the SSP get left out of the mutable canonical form of the
> primary bundle block. If scheme Beta says that all characters that
> follow the  “?” character are mutable, then the BSP would have to know
> that for this scheme, all characters that follow the “?” in the SSP get
> left out of the mutable canonical form of the primary bundle block.
>  Clearly, this is undesirable; we don’t want to have to make changes to
> BSP implementations every time a new scheme is defined.
> 
>  
> 
> It would be a lot nicer if we could agree on a general rule that all
> EIDs would follow for how to indicate which parts of an EID are mutable
> and which are non-mutable.
> 
>  
> 
> Attached is a word file that contains the revisions that I believe are
> needed to the BSP to enable security to work the way we intend for it to
> work even if EIDs are mutable. These revisions apply only to the BSP so
> if you aren’t particularly interested in security, then you may not be
> interested in them. What should be of general interest though, is that
> we have identified a need to define a general mechanism that all schemes
> should use to indicate what parts of an SSP are mutable (if any). I hope
> we can agree that one is needed and choose one.
> 
>  
> 
> If you wish to reply and comment on the actual revisions to the BSP that
> are attached, I think we should conduct that discussion on the
> dtn-security list, so please send those responses to dtn-security
> instead of  dtn-interest.
> 
>  
> 
> If you wish to reply regarding the need to define and agree on a
> convention that all schemes will follow to denote which parts of their
> SSPs are mutable, then that discussion should probably stay here in
> dtn-interest.
> 
>  
> 
> Thanks.
> 
>  
> 
> -susan
> 
> *****************************************************************
> 
> Susan Symington
> 
> The MITRE Corporation
> 
> [email-masked]
> 
> 703-983-7209 (voice)
> 
> 703-983-7142 (fax)
> 
> ******************************************************************
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Date: Mon, 29 Sep 2008 16:26:35 -0400
From: "Symington, Susan F." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] mutable EIDs; a general rule would be nice

This is a multi-part message in MIME format.

------_=_NextPart_001_01C92271.AA0960DD
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C92271.AA0960DD"

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

The Bundle Protocol defines EIDs to have the general structure of=20

< scheme name > : < scheme-specific part >, says that the scheme is the
set of rules for parsing and interpreting the SSP, and pretty much
leaves things open from there.=20

=20

In the Bundle Security Protocol (BSP), as currently drafted, we assume
that EIDs are non-mutable. However, this is not necessarily a valid
assumption. One may want to have a scheme that defines an SSP that has
both a non-mutable portion and a mutable portion. The mutable portion
might be used for purposes of mobility. Stephen Farrell offers the
following example of a possible EID:=20

=20

"dtn://foo.bar/baz?LASTSEENAT=3D10.0.0.1"

=20

where "LASTSEENAT=3D10.0.0.1" is a mutable part. (The exact definition =
of
the scheme is not what is important at this point. What is important is
that we recognize that EIDs may have non-mutable parts and we make sure
that the specifications are written correctly so as to allow for this
possibility.)

=20

As far as the BSP is concerned, we need to revise the mutable
canonicalization section of the BSP to allow for the possibility that
EIDs may have mutable parts, because these parts of the EIDs will need
to be left out of the mutable canonical form. Making this change is not
difficult and in fact attached is a draft set of revisions for doing
so. What does get tricky, though, is that if every scheme has a
different way of denoting which parts of the EID are mutable and which
are non-mutable, then any given implementation of the BSP would have to
be equipped with a different set of rules for how to perform the
canonicalization for each scheme. If scheme Alpha says that all
characters that follow the "|" character in the SSP are mutable, then
the BSP needs to know that for this scheme, all characters that follow
the "|" in the SSP get left out of the mutable canonical form of the
primary bundle block. If scheme Beta says that all characters that
follow the  "?" character are mutable, then the BSP would have to know
that for this scheme, all characters that follow the "?" in the SSP get
left out of the mutable canonical form of the primary bundle block.
Clearly, this is undesirable; we don't want to have to make changes to
BSP implementations every time a new scheme is defined.

=20

It would be a lot nicer if we could agree on a general rule that all
EIDs would follow for how to indicate which parts of an EID are mutable
and which are non-mutable.=20

=20

Attached is a word file that contains the revisions that I believe are
needed to the BSP to enable security to work the way we intend for it
to work even if EIDs are mutable. These revisions apply only to the BSP
so if you aren't particularly interested in security, then you may not
be interested in them. What should be of general interest though, is
that we have identified a need to define a general mechanism that all
schemes should use to indicate what parts of an SSP are mutable (if
any). I hope we can agree that one is needed and choose one.

=20

If you wish to reply and comment on the actual revisions to the BSP
that are attached, I think we should conduct that discussion on the
dtn-security list, so please send those responses to dtn-security
instead of  dtn-interest.

=20

If you wish to reply regarding the need to define and agree on a
convention that all schemes will follow to denote which parts of their
SSPs are mutable, then that discussion should probably stay here in
dtn-interest.

=20

Thanks.

=20

-susan

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

Susan Symington

The MITRE Corporation

[email-masked]

703-983-7209 (voice)

703-983-7142 (fax)

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

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

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-family:"Century","serif"'>The =
Bundle
Protocol defines EIDs to have the general structure of =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Century","serif"'>&lt; =
scheme name
&gt; : &lt; scheme-specific part &gt;, says that the scheme is the set =
of rules
for parsing and interpreting the SSP, and pretty much leaves things open =
from
there. <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-family:"Century","serif"'>In =
the Bundle
Security Protocol (BSP), as currently drafted, we assume that EIDs are
non-mutable. However, this is not necessarily a valid assumption. One =
may want
to have a scheme that defines an SSP that has both a non-mutable portion =
and a
mutable portion. The mutable portion might be used for purposes of =
mobility. Stephen
Farrell offers the following example of a possible EID: =
<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-family:"Century","serif"'>&quot;dtn://foo.bar/baz?LASTSEENA=
T=3D10.0.0.1&quot;<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-family:"Century","serif"'>where =
&quot;LASTSEENAT=3D10.0.0.1&quot;
is a mutable part. (The exact definition of the scheme is not what is =
important
at this point. What is important is that we recognize that EIDs may have
non-mutable parts and we make sure that the specifications are written
correctly so as to allow for this possibility.)<o:p></o:p></span></p>

<p class=3DMsoPlainText><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Century","serif"'>As =
far as the
BSP is concerned, we need to revise the mutable canonicalization section =
of the
BSP to allow for the possibility that EIDs may have mutable parts, =
because these
parts of the EIDs will need to be left out of the mutable canonical =
form.
Making this change is not difficult and in fact attached is a draft set =
of
revisions for doing so. What does get tricky, though, is that if every =
scheme
has a different way of denoting which parts of the EID are mutable and =
which
are non-mutable, then any given implementation of the BSP would have to =
be
equipped with a different set of rules for how to perform the =
canonicalization
for each scheme. If scheme Alpha says that all characters that follow =
the
&#8220;|&#8221; character in the SSP are mutable, then the BSP needs to =
know
that for this scheme, all characters that follow the &#8220;|&#8221; in =
the SSP
get left out of the mutable canonical form of the primary bundle block. =
If
scheme Beta says that all characters that follow the =
&nbsp;&#8220;?&#8221;
character are mutable, then the BSP would have to know that for this =
scheme,
all characters that follow the &#8220;?&#8221; in the SSP get left out =
of the mutable
canonical form of the primary bundle block. &nbsp;Clearly, this is =
undesirable;
we don&#8217;t want to have to make changes to BSP implementations every =
time a
new scheme is defined.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoPlainText><span style=3D'font-family:"Century","serif"'>It =
would be a
lot nicer if we could agree on a general rule that all EIDs would follow =
for
how to indicate which parts of an EID are mutable and which are =
non-mutable. <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'>Attached is a
word file that contains the revisions that I believe are needed to the =
BSP to
enable security to work the way we intend for it to work even if EIDs =
are
mutable. These revisions apply only to the BSP so if you aren&#8217;t
particularly interested in security, then you may not be interested in =
them.
What should be of general interest though, is that we have identified a =
need to
define a general mechanism that all schemes should use to indicate what =
parts
of an SSP are mutable (if any). I hope we can agree that one is needed =
and
choose one.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Century","serif"'>If =
you wish to
reply and comment on the actual revisions to the BSP that are attached, =
I think
we should conduct that discussion on the dtn-security list, so please =
send those
responses to dtn-security instead of =
&nbsp;dtn-interest.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Century","serif"'>If =
you wish to reply
regarding the need to define and agree on a convention that all schemes =
will
follow to denote which parts of their SSPs are mutable, then that =
discussion
should probably stay here in dtn-interest.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'>Thanks.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-family:"Century","serif"'>-susan<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>*************=
****************************************************</span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Courier New"'>Susan
Symington</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Courier New"'>The
MITRE Corporation</span><span =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Courier =
New"'>[email-masked]</span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Courier New"'>703-983-7209
(voice)</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:12.0pt;font-family:"Courier New"'>703-983-7142
(fax)</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>*************=
*****************************************************</span><o:p></o:p></=
p>

</div>

</body>

</html>

------_=_NextPart_002_01C92271.AA0960DD--

------_=_NextPart_001_01C92271.AA0960DD
Content-Type: application/msword;
	name="bsp-mutable-EIDs-revision.doc"
Content-Transfer-Encoding: base64
Content-Description: bsp-mutable-EIDs-revision.doc
Content-Disposition: attachment;
	filename="bsp-mutable-EIDs-revision.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAARQAAAAAAAAAA
EAAARwAAAAEAAAD+////AAAAAEYAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////AQAAAP7///8DAAAABAAA
AAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

------_=_NextPart_001_01C92271.AA0960DD--

Date: Thu, 18 Sep 2008 09:18:27 -0700
From: "Michael Demmer" <[email-masked]>
Sender: [email-masked]
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, dtn-users mailing list <[email-masked]>, Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] dtn on sourceforge and 2.6.0 release

What actually happened is that prior to the 2.5 release, I (and
others) had modified the code so that it actually implemented version
6 of the bundle protocol, but had not updated the version number in
the code accordingly. We discovered this at the last interoperability
meeting at IETF.

So in the 2.6 release, I fixed the code so advertises the correct
version of the protocol.

-m

On Thu, Sep 18, 2008 at 9:04 AM, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:
>
> Mike,
>
> I figured other people are interested, so I'll ask here.
>
> 2.5 and 2.6 do not interoperate.  I appears to be due to version number
> mismatch.
>
> Looking at the code list, there doesn't appear to be any obvious
> changes.  When dtn-2 was move to sourceforge did just the version number
> change, or were there other changes.  I thought that a fixed field may
> have changed to an SDNV field.
>
> /will
>
>
> ******************************
> William D. Ivancic
> Phone 216-433-3494
> Fax 216-433-8705
> Networking Lab 216-433-2620
> DTN Lab 216-433-2981
> Mobile 440-503-4892
> http://roland.grc.nasa.gov/~ivancic
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On
>> Behalf Of Michael Demmer
>> Sent: Tuesday, August 12, 2008 2:27 PM
>> To: Michael Demmer
>> Cc: Delay Tolerant Networking Interest List; dtn-users mailing list
>> Subject: [dtn-interest] dtn on sourceforge and 2.6.0 release
>>
>>
>> Continuing the transition I mentioned a couple of months ago,
>> I've set up the mercurial repositories on sourceforge and
>> updated the relevant wiki pages on http://www.dtnrg.org
>> accordingly to refer to the new source repository locations.
>>
>> For the impatient, you can access the repositories directly
>> at http://dtn.sourceforge.net/hg
>>   and you can contribute changes by registering for a
>> sourceforge account and requesting to be added to the dtn
>> project as a developer.
>>
>> I've also transitioned the release management to use the
>> sourceforge mechanisms.
>>
>> I also put together a 2.6.0 release of DTN2 that can be
>> obtained from
>> https://sourceforge.net/project/showfiles.php?group_id=101657
>> .
>>
>> Highlights include:
>>
>> - Updated the source control system to mercurial, splitting the oasys
>>    library into a fully separate package and changing the
>> configuration,
>>    build, and packaging accordingly.
>>
>> - Added a session layer with a publish / subscribe based interface and
>>    multicast capabilities as well as the ability to order bundles by
>>    sequence identifier and express that prior transmissions should be
>>    proactively deleted in-network.
>>
>> - Updated DTLSR to support the session layer and route advertisements
>>    as well as miscellaneous other bug fixes.
>>
>> - Restructured the core forwarding path and the router <-> convergence
>>    layer interface, getting rid of the BUSY state management and
>>    (hopefully) improving stability and scalability.
>>
>> - Changed the contract between the core forwarding logic and the
>>    router implementation to give the router better control over when
>>    bundles are deleted from the system.
>>
>> - Changed the Bundle class internals to make all member variables
>>    private, adding accessor functions for manipulation and state
>>    retrieval and improve efficiency in internal storage.
>>
>> - Added additional API function accesses through the SWIG
>> interface and
>>    parse status reports that are returned to the app. Also removed the
>>    limitation on the size of bundles that can be returned in memory.
>>
>> - Added a fix so that bundles aren't delivered twice to the same
>>    registration and changes to the core forwarding path to support
>>    modified topologies.
>>
>> - Incorporated patches from BBN to fix bugs during shutdown, more
>>    efficient comparisons, memory leak and dangling pointer fixes, and
>>    modified handling of duplicate bundles.
>>
>> - Fixed a bunch of bugs in the dtntunnel application.
>>
>> - Incorporated various updates to the prophet implementation from Jeff
>>    Wilson.
>>
>> - Various other minor updates and bugfixes including Mac OS X 10.5
>>    (Leopard) compatibility.
>>
>> Finally, my apologies for the delay in this transition. I
>> actually set up the sourceforge repositories a while ago, but
>> never got around to updating the wiki pages or sending this email out.
>>
>> -mike
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>

Content-class: urn:content-classes:message
Date: Thu, 18 Sep 2008 11:04:16 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Michael Demmer" <[email-masked]>, "Michael Demmer" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-interest] dtn on sourceforge and 2.6.0 release

Mike,

I figured other people are interested, so I'll ask here.

2.5 and 2.6 do not interoperate.  I appears to be due to version number
mismatch.

Looking at the code list, there doesn't appear to be any obvious
changes.  When dtn-2 was move to sourceforge did just the version number
change, or were there other changes.  I thought that a fixed field may
have changed to an SDNV field.

/will

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Michael Demmer
> Sent: Tuesday, August 12, 2008 2:27 PM
> To: Michael Demmer
> Cc: Delay Tolerant Networking Interest List; dtn-users mailing list
> Subject: [dtn-interest] dtn on sourceforge and 2.6.0 release
> 
> 
> Continuing the transition I mentioned a couple of months ago, 
> I've set up the mercurial repositories on sourceforge and 
> updated the relevant wiki pages on http://www.dtnrg.org 
> accordingly to refer to the new source repository locations.
> 
> For the impatient, you can access the repositories directly 
> at http://dtn.sourceforge.net/hg
>   and you can contribute changes by registering for a 
> sourceforge account and requesting to be added to the dtn 
> project as a developer.
> 
> I've also transitioned the release management to use the 
> sourceforge mechanisms.
> 
> I also put together a 2.6.0 release of DTN2 that can be 
> obtained from 
> https://sourceforge.net/project/showfiles.php?group_id=101657
> .
> 
> Highlights include:
> 
> - Updated the source control system to mercurial, splitting the oasys
>    library into a fully separate package and changing the 
> configuration,
>    build, and packaging accordingly.
> 
> - Added a session layer with a publish / subscribe based interface and
>    multicast capabilities as well as the ability to order bundles by
>    sequence identifier and express that prior transmissions should be
>    proactively deleted in-network.
> 
> - Updated DTLSR to support the session layer and route advertisements
>    as well as miscellaneous other bug fixes.
> 
> - Restructured the core forwarding path and the router <-> convergence
>    layer interface, getting rid of the BUSY state management and
>    (hopefully) improving stability and scalability.
> 
> - Changed the contract between the core forwarding logic and the
>    router implementation to give the router better control over when
>    bundles are deleted from the system.
> 
> - Changed the Bundle class internals to make all member variables
>    private, adding accessor functions for manipulation and state
>    retrieval and improve efficiency in internal storage.
> 
> - Added additional API function accesses through the SWIG 
> interface and
>    parse status reports that are returned to the app. Also removed the
>    limitation on the size of bundles that can be returned in memory.
> 
> - Added a fix so that bundles aren't delivered twice to the same
>    registration and changes to the core forwarding path to support
>    modified topologies.
> 
> - Incorporated patches from BBN to fix bugs during shutdown, more
>    efficient comparisons, memory leak and dangling pointer fixes, and
>    modified handling of duplicate bundles.
> 
> - Fixed a bunch of bugs in the dtntunnel application.
> 
> - Incorporated various updates to the prophet implementation from Jeff
>    Wilson.
> 
> - Various other minor updates and bugfixes including Mac OS X 10.5
>    (Leopard) compatibility.
> 
> Finally, my apologies for the delay in this transition. I 
> actually set up the sourceforge repositories a while ago, but 
> never got around to updating the wiki pages or sending this email out.
> 
> -mike
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Wed, 17 Sep 2008 13:44:30 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Kevin Fall" <[email-masked]>
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

Kevin

> -----Original Message-----
> From: Kevin Fall [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2008 11:47 AM
> To: Weiss, Howard
> Cc: Stephen Farrell; DTN Interest List; Lloyd Wood; Ivancic,William D.
> (GRC-RHN0)
> Subject: Re: [dtn-interest] Underlying Networks
> 
> 
> On Sep 17, 2008, at Sep 178:22 AMPDT, Weiss, Howard wrote:
> 
> > I agree with Stephen....
> >
> > Security at different layers serves different constituencies.  If
you
> > need writer-2-reader authentication and confidentiality, you're only
> > gonna get it at the application layer or via the object (data at
> > rest).
> 
> With all due respect to both of you...
> 
> >
> > If all you need is confidentiality and/or authentication between two
> > (defined) end-points (e.g., a security gateway), the network layer
> > works
> > great.
> 
> I think we've suffered from this sort of mental model.  "all you need"
> has been a recurring unfortunate notion.  All we needed were 4
> computers and 640KBytes of memory once upon a time.  Maybe we thought
> "all we needed" was security across a channel where there may be
> people trying to intercept our comms between two 'secure' facilities.
> But I am sure you can appreciate how hard it is now to draw boundaries
> of any sort.

Some have gotten into that mold.  But on the other hand, I have taught
myself to *never* say *never* - e.g., no one will *ever* need more than
a 130M disk drive, no one will *ever* need more than 8K of RAM, etc.
All I'm saying is that if we have an operational model that wants
security mechanims only the front doors, then network layer mechanims
provide a solution.  Its equivalent to only putting dead bolts on your
front door or all of the doors inside your house?  Certainly one is more
secure than the other, but it's the extra security and operational
burden needed?  A risk assessment can tell you and then you have to
decide whether or not you want to go thru the added pain.  Are there
better solutions?  Sure - moats can be effective.  Electrified razor
wire too.  But .... 

> > But at that layer, you're not gonna know that Mr. XXX sent
> > anything.  All you're gonna know is that it came from a 'trusted'
> > end-point (site Y).  That is, unless Mr. XXX did something at the
> > application layer to 'enable' authentication (e.g., digitally signed
> > the
> > object).
> 
> That, I think, is another problem with layers.  Perhaps a bit of a
> stretch, but if we look at http, one of the changes from 1.0 to 1.1
> was to include whole URLs, which helps intermediate proxies to make
> better decisions about what to cache or how to re-direct.  Layering
> that does what you are saying (i.e. removes info you really want to
> make decisions) I think doesn't help us too much.

But this is why we need different security for different situations.
There isn't a 100% universal solution for everyone and everything.

> > If we did things right, the OS would be capable of storing data at
> > rest
> > securely and therefore we wouldn't have to do much (if anything
more)
> > for protection during transmission.  The object would be encrypted
> > until
> > locally used and would be signed to ensure authenticity and
> integrity.
> >
> > 30+ years ago there were a few programs looking at capability-based
> > operating systems and cryptographic based storage systems.  But the
> > hardware wasn't there to support the security paradigms and they
> > whithered away for lack of performance.  Data security at rest is
> > 'hard'
> > because of key management but not insurmountable.
> 
> yes, that makes sense.  Do you think we're now in a regime where the
> end
> system performance is adequate to do this sort of thing?

Absolutely!  Look at the monster CPU(s) required to run Vista - for not
much performance gain over XP.  We had a lot of problems with early
window systems because of hardware (remember Windows 2 on 286-class
boxes?).  But we (consumers) wanted window systems and eventually the
hardware was available.  But did DOS still run faster on the same box as
Windows - yep but we "like" Windows so we'll take the hit.  Security is
a different beast.  We need lots of CPU cycles (or dedicated hardware)
and we try to make it invisible to the user.  We steal cycles for no
added functional gain.

> > If we encrypt and/or
> > sign a TByte of data today, how do we change keys later?  Obviously,
> > we
> > don't.  We use an object key that 'never' changes which is then
> > protected under an ever changing set of key-encryption-keys.  Of
> > course
> > we can also change the object key over time, but that means that we
> > have
> > to understand the binding between the keys and the objects in order
> to
> > get the data back.  And of course, there is the other hard problem -
> > secure key storage....
> 
> right.  But most things only need to be secured for so long, it
> seems...  so I think there's at least some hope.

Doubtful - stuff that goes on a disk (or other storage medium) stays on
the storage medium.  When was the last time you cleaned up your disk
space?  Who cares anymore when you can buy a 1TB disk for a few hundred
dollars?  Stuff may not need to be protected for "life" but who makes
that call?  And who is going to go back and review any of it?

regards

Howie

> 
> - K
> 
> 
> 
> >
> >
> > howie
> >
> >> -----Original Message-----
> >> From: [email-masked]
[mailto:dtn-
> >> [email-masked]] On Behalf Of Stephen
> >> Farrell
> >> Sent: Wednesday, September 17, 2008 8:09 AM
> >> To: Kevin Fall
> >> Cc: DTN Interest List; Lloyd Wood; Ivancic,William D. (GRC-RHN0)
> >> Subject: Re: [dtn-interest] Underlying Networks
> >>
> >>
> >>
> >> Kevin Fall wrote:
> >>
> >>> IMHO, there is a tendency to try and put security in at every
> layer.
> >>
> >> I agree that this is the case, but I'd defend it. I think we
> >> should define security mechanisms for each layer so that
> >> people experimenting with and eventually deploying DTN can
> >> choose what security (if any) to use.
> >>
> >>> Further, there is a tendency to try and protect the channel only
> >>> [where channel is layer dependent].  I think its likely that the
> >>> "best" architecture for security is some set of functions to try
> and
> >>> provide connectivity when being jammed or during DoS events, plus
> >>> another set of functions to be able to encode objects/messages in
> >> ways
> >>> that reliably indicate who they are authored by, and possibly to
> >>> encode them so as to be private.
> >>
> >> Maybe. However, the email world might offer evidence that that's
> >> not what people generally use - while IMAP/SSL is in common use,
> >> S/MIME and PGP are rarely used. A similar point could be made
> >> about web content though its earlier days there - HTTP/TLS is
> >> common, but content protection (e.g. XML signing) is rare. There
> >> is a reasonable argument that this situation is down to the
> >> available higher layer security tools offering crappy user
> >> interfaces, but nonetheless, those (IMAP/TLS etc) are the
> >> sorts of security mechanism that get used.
> >>
> >>>> But then, I have no idea what "object-based security" is. The
> >> object-
> >>>> capability model? I'm not jumping. Oh, does this mean we are in
> for
> >>>> another six months of involved security discussion? (Wes's doc
> tree
> >>>> draft suggests that many things depend on the existing security
> >> work.)
> >>>
> >>> It hasn't really been defined.  But think DRM as a sort of
> baseline.
> >>
> >> Eek! Why? (I.e., what's needed there over and above the kind
> >> of content protection that S/MIME or PGP could offer)
> >>
> >> S.
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >

Date: Wed, 17 Sep 2008 17:40:29 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: DTN Interest List <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

Kevin Fall wrote:
> 
> On Sep 17, 2008, at Sep 178:22 AMPDT, Weiss, Howard wrote:
> 
>> I agree with Stephen....
>>
>> Security at different layers serves different constituencies.  If you
>> need writer-2-reader authentication and confidentiality, you're only
>> gonna get it at the application layer or via the object (data at rest).
> 
> With all due respect to both of you...

Likewise:-)

Its ok that we disagree. If someone wants to produce a scheme for object
based DTN security I think that'd be great. (I'm less certain it'd be
great were that to look very like current DRM approaches, but I guess
I'll have to wait and see...)

If such a beast existed then I think we'd have the right set of security
mechanism options defined, object-level, BP-level and lower layers so
that people could choose to use what makes sense for them.

(Of course we'd still need key mgmt but that'd be very similar for
both object and BP security.)

Stephen.

From: Kevin Fall <[email-masked]>
To: "Weiss, Howard" <[email-masked]>
Date: Wed, 17 Sep 2008 08:47:18 -0700
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

On Sep 17, 2008, at Sep 178:22 AMPDT, Weiss, Howard wrote:

> I agree with Stephen....
>
> Security at different layers serves different constituencies.  If you
> need writer-2-reader authentication and confidentiality, you're only
> gonna get it at the application layer or via the object (data at  
> rest).

With all due respect to both of you...

>
> If all you need is confidentiality and/or authentication between two
> (defined) end-points (e.g., a security gateway), the network layer  
> works
> great.

I think we've suffered from this sort of mental model.  "all you need"  
has been a recurring unfortunate notion.  All we needed were 4  
computers and 640KBytes of memory once upon a time.  Maybe we thought  
"all we needed" was security across a channel where there may be  
people trying to intercept our comms between two 'secure' facilities.   
But I am sure you can appreciate how hard it is now to draw boundaries  
of any sort.

> But at that layer, you're not gonna know that Mr. XXX sent
> anything.  All you're gonna know is that it came from a 'trusted'
> end-point (site Y).  That is, unless Mr. XXX did something at the
> application layer to 'enable' authentication (e.g., digitally signed  
> the
> object).

That, I think, is another problem with layers.  Perhaps a bit of a  
stretch, but if we look at http, one of the changes from 1.0 to 1.1  
was to include whole URLs, which helps intermediate proxies to make  
better decisions about what to cache or how to re-direct.  Layering  
that does what you are saying (i.e. removes info you really want to  
make decisions) I think doesn't help us too much.

>
>
> If we did things right, the OS would be capable of storing data at  
> rest
> securely and therefore we wouldn't have to do much (if anything more)
> for protection during transmission.  The object would be encrypted  
> until
> locally used and would be signed to ensure authenticity and integrity.
>
> 30+ years ago there were a few programs looking at capability-based
> operating systems and cryptographic based storage systems.  But the
> hardware wasn't there to support the security paradigms and they
> whithered away for lack of performance.  Data security at rest is  
> 'hard'
> because of key management but not insurmountable.

yes, that makes sense.  Do you think we're now in a regime where the end
system performance is adequate to do this sort of thing?

> If we encrypt and/or
> sign a TByte of data today, how do we change keys later?  Obviously,  
> we
> don't.  We use an object key that 'never' changes which is then
> protected under an ever changing set of key-encryption-keys.  Of  
> course
> we can also change the object key over time, but that means that we  
> have
> to understand the binding between the keys and the objects in order to
> get the data back.  And of course, there is the other hard problem -
> secure key storage....

right.  But most things only need to be secured for so long, it  
seems...  so I think there's at least some hope.

- K

>
>
> howie
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Stephen
>> Farrell
>> Sent: Wednesday, September 17, 2008 8:09 AM
>> To: Kevin Fall
>> Cc: DTN Interest List; Lloyd Wood; Ivancic,William D. (GRC-RHN0)
>> Subject: Re: [dtn-interest] Underlying Networks
>>
>>
>>
>> Kevin Fall wrote:
>>
>>> IMHO, there is a tendency to try and put security in at every layer.
>>
>> I agree that this is the case, but I'd defend it. I think we
>> should define security mechanisms for each layer so that
>> people experimenting with and eventually deploying DTN can
>> choose what security (if any) to use.
>>
>>> Further, there is a tendency to try and protect the channel only
>>> [where channel is layer dependent].  I think its likely that the
>>> "best" architecture for security is some set of functions to try and
>>> provide connectivity when being jammed or during DoS events, plus
>>> another set of functions to be able to encode objects/messages in
>> ways
>>> that reliably indicate who they are authored by, and possibly to
>>> encode them so as to be private.
>>
>> Maybe. However, the email world might offer evidence that that's
>> not what people generally use - while IMAP/SSL is in common use,
>> S/MIME and PGP are rarely used. A similar point could be made
>> about web content though its earlier days there - HTTP/TLS is
>> common, but content protection (e.g. XML signing) is rare. There
>> is a reasonable argument that this situation is down to the
>> available higher layer security tools offering crappy user
>> interfaces, but nonetheless, those (IMAP/TLS etc) are the
>> sorts of security mechanism that get used.
>>
>>>> But then, I have no idea what "object-based security" is. The
>> object-
>>>> capability model? I'm not jumping. Oh, does this mean we are in for
>>>> another six months of involved security discussion? (Wes's doc tree
>>>> draft suggests that many things depend on the existing security
>> work.)
>>>
>>> It hasn't really been defined.  But think DRM as a sort of baseline.
>>
>> Eek! Why? (I.e., what's needed there over and above the kind
>> of content protection that S/MIME or PGP could offer)
>>
>> S.
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Date: Wed, 17 Sep 2008 11:22:55 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Kevin Fall" <[email-masked]>
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

I agree with Stephen....

Security at different layers serves different constituencies.  If you
need writer-2-reader authentication and confidentiality, you're only
gonna get it at the application layer or via the object (data at rest).
If all you need is confidentiality and/or authentication between two
(defined) end-points (e.g., a security gateway), the network layer works
great.  But at that layer, you're not gonna know that Mr. XXX sent
anything.  All you're gonna know is that it came from a 'trusted'
end-point (site Y).  That is, unless Mr. XXX did something at the
application layer to 'enable' authentication (e.g., digitally signed the
object).

If we did things right, the OS would be capable of storing data at rest
securely and therefore we wouldn't have to do much (if anything more)
for protection during transmission.  The object would be encrypted until
locally used and would be signed to ensure authenticity and integrity.
30+ years ago there were a few programs looking at capability-based
operating systems and cryptographic based storage systems.  But the
hardware wasn't there to support the security paradigms and they
whithered away for lack of performance.  Data security at rest is 'hard'
because of key management but not insurmountable.  If we encrypt and/or
sign a TByte of data today, how do we change keys later?  Obviously, we
don't.  We use an object key that 'never' changes which is then
protected under an ever changing set of key-encryption-keys.  Of course
we can also change the object key over time, but that means that we have
to understand the binding between the keys and the objects in order to
get the data back.  And of course, there is the other hard problem -
secure key storage....

howie

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Stephen
> Farrell
> Sent: Wednesday, September 17, 2008 8:09 AM
> To: Kevin Fall
> Cc: DTN Interest List; Lloyd Wood; Ivancic,William D. (GRC-RHN0)
> Subject: Re: [dtn-interest] Underlying Networks
> 
> 
> 
> Kevin Fall wrote:
> 
> > IMHO, there is a tendency to try and put security in at every layer.
> 
> I agree that this is the case, but I'd defend it. I think we
> should define security mechanisms for each layer so that
> people experimenting with and eventually deploying DTN can
> choose what security (if any) to use.
> 
> > Further, there is a tendency to try and protect the channel only
> > [where channel is layer dependent].  I think its likely that the
> > "best" architecture for security is some set of functions to try and
> > provide connectivity when being jammed or during DoS events, plus
> > another set of functions to be able to encode objects/messages in
> ways
> > that reliably indicate who they are authored by, and possibly to
> > encode them so as to be private.
> 
> Maybe. However, the email world might offer evidence that that's
> not what people generally use - while IMAP/SSL is in common use,
> S/MIME and PGP are rarely used. A similar point could be made
> about web content though its earlier days there - HTTP/TLS is
> common, but content protection (e.g. XML signing) is rare. There
> is a reasonable argument that this situation is down to the
> available higher layer security tools offering crappy user
> interfaces, but nonetheless, those (IMAP/TLS etc) are the
> sorts of security mechanism that get used.
> 
> >> But then, I have no idea what "object-based security" is. The
> object-
> >> capability model? I'm not jumping. Oh, does this mean we are in for
> >> another six months of involved security discussion? (Wes's doc tree
> >> draft suggests that many things depend on the existing security
> work.)
> >
> > It hasn't really been defined.  But think DRM as a sort of baseline.
> 
> Eek! Why? (I.e., what's needed there over and above the kind
> of content protection that S/MIME or PGP could offer)
> 
> S.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 17 Sep 2008 08:37:47 -0400
From: "Rajesh Krishnan" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] LTP rfcs

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

Congratulations!

-Rajesh

On Wed, Sep 17, 2008 at 8:11 AM, Stephen Farrell
<[email-masked]>wrote:

>
> The LTP specs have *finally* turned into RFCs:
>
> http://www.rfc-editor.org/rfc/rfc5325.txt
> http://www.rfc-editor.org/rfc/rfc5326.txt
> http://www.rfc-editor.org/rfc/rfc5327.txt
>
> Well done to all involved!
>
> Regards,
> Stephen.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

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

<div dir="ltr">Congratulations!<br><br>-Rajesh<br><br><div class="gmail_quote">On Wed, Sep 17, 2008 at 8:11 AM, Stephen Farrell <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
The LTP specs have *finally* turned into RFCs:<br>
<br>
<a href="http://www.rfc-editor.org/rfc/rfc5325.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc5325.txt</a><br>
<a href="http://www.rfc-editor.org/rfc/rfc5326.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc5326.txt</a><br>
<a href="http://www.rfc-editor.org/rfc/rfc5327.txt" target="_blank">http://www.rfc-editor.org/rfc/rfc5327.txt</a><br>
<br>
Well done to all involved!<br>
<br>
Regards,<br>
Stephen.<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" target="_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
</blockquote></div><br></div>

------=_Part_9327_30096764.1221655067850--

Date: Wed, 17 Sep 2008 08:37:02 -0400
From: "Rajesh Krishnan" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

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

On Wed, Sep 17, 2008 at 8:09 AM, Stephen Farrell
<[email-masked]>wrote:

>
>
> Kevin Fall wrote:
>

>
> > Further, there is a tendency to try and protect the channel only
> > [where channel is layer dependent].  I think its likely that the
> > "best" architecture for security is some set of functions to try and
> > provide connectivity when being jammed or during DoS events, plus
> > another set of functions to be able to encode objects/messages in ways
> > that reliably indicate who they are authored by, and possibly to
> > encode them so as to be private.
>
> Maybe. However, the email world might offer evidence that that's
> not what people generally use - while IMAP/SSL is in common use,
> S/MIME and PGP are rarely used. A similar point could be made
> about web content though its earlier days there - HTTP/TLS is
> common, but content protection (e.g. XML signing) is rare. There
> is a reasonable argument that this situation is down to the
> available higher layer security tools offering crappy user
> interfaces, but nonetheless, those (IMAP/TLS etc) are the
> sorts of security mechanism that get used.

Hysteresis from the end-to-end phone call and currently dominant
client-server paradigm?

When end-to-end connectivity is available, some assurance that the
other end is who they claim to be and that the channel is secure may
provide sufficient confidence for many users.  When continuous
end-to-end connectivity to source and trusted third party is unavailable,
protecting the content will take on an added significance.  (As an analogy
consider being served at a restaurant vs. purchasing pre-packaged food where
we have all sorts of tamper-evident seals and FDA approval/warnings
are felt necessary.   Service model vs. content model.)

Sensitivity to (or liability from) loss of personal devices containing
(different kinds of) regulated  information may motivate increased
attention to protecting content items individually.

I recommend Van's Google talk "A New Way to Look at Networking"
http://video.google.com/videoplay?docid=-6972678839686672840

Best Regards,
Rajesh

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

<div dir="ltr"><br><br><div class="gmail_quote">On Wed, Sep 17, 2008 at 8:09 AM, Stephen Farrell <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Kevin Fall wrote:&nbsp;<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
&gt; Further, there is a tendency to try and protect the channel only<br>
&gt; [where channel is layer dependent]. &nbsp;I think its likely that the<br>
&gt; &quot;best&quot; architecture for security is some set of functions to try and<br>
&gt; provide connectivity when being jammed or during DoS events, plus<br>
&gt; another set of functions to be able to encode objects/messages in ways<br>
&gt; that reliably indicate who they are authored by, and possibly to<br>
&gt; encode them so as to be private.<br>
<br>
Maybe. However, the email world might offer evidence that that&#39;s<br>
not what people generally use - while IMAP/SSL is in common use,<br>
S/MIME and PGP are rarely used. A similar point could be made<br>
about web content though its earlier days there - HTTP/TLS is<br>
common, but content protection (e.g. XML signing) is rare. There<br>
is a reasonable argument that this situation is down to the<br>
available higher layer security tools offering crappy user<br>
interfaces, but nonetheless, those (IMAP/TLS etc) are the<br>
sorts of security mechanism that get used.</blockquote><div><br>Hysteresis from the end-to-end phone call and currently dominant <br>client-server paradigm?<br>
<br>When end-to-end connectivity is available, some assurance that the <br>other end is who they claim to be and that the channel is secure may <br>provide sufficient confidence for many users.&nbsp; When continuous <br>end-to-end connectivity to source and trusted third party is unavailable, <br>
protecting the content will take on an added significance.&nbsp; (As an analogy <br>consider being served at a restaurant vs. purchasing pre-packaged food where<br>we have all sorts of tamper-evident seals and FDA approval/warnings<br>
are felt necessary.&nbsp;&nbsp; Service model vs. content model.) <br><br>Sensitivity to (or liability from) loss of personal devices containing <br>(different kinds of) regulated&nbsp; information may motivate increased <br>attention to protecting content items individually.<br>
<br>I recommend Van&#39;s Google talk &quot;A New Way to Look at Networking&quot; <br><a href="http://video.google.com/videoplay?docid=-6972678839686672840">http://video.google.com/videoplay?docid=-6972678839686672840</a><br>
<br>Best Regards,<br>Rajesh<br></div></div></div>

------=_Part_9319_11546179.1221655022689--

Date: Wed, 17 Sep 2008 13:11:55 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] LTP rfcs

The LTP specs have *finally* turned into RFCs:

http://www.rfc-editor.org/rfc/rfc5325.txt
http://www.rfc-editor.org/rfc/rfc5326.txt
http://www.rfc-editor.org/rfc/rfc5327.txt

Well done to all involved!

Regards,
Stephen.

Date: Wed, 17 Sep 2008 13:09:07 +0100
From: Stephen Farrell <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

Kevin Fall wrote:

> IMHO, there is a tendency to try and put security in at every layer.   

I agree that this is the case, but I'd defend it. I think we
should define security mechanisms for each layer so that
people experimenting with and eventually deploying DTN can
choose what security (if any) to use.

> Further, there is a tendency to try and protect the channel only  
> [where channel is layer dependent].  I think its likely that the  
> "best" architecture for security is some set of functions to try and  
> provide connectivity when being jammed or during DoS events, plus  
> another set of functions to be able to encode objects/messages in ways  
> that reliably indicate who they are authored by, and possibly to  
> encode them so as to be private.

Maybe. However, the email world might offer evidence that that's
not what people generally use - while IMAP/SSL is in common use,
S/MIME and PGP are rarely used. A similar point could be made
about web content though its earlier days there - HTTP/TLS is
common, but content protection (e.g. XML signing) is rare. There
is a reasonable argument that this situation is down to the
available higher layer security tools offering crappy user
interfaces, but nonetheless, those (IMAP/TLS etc) are the
sorts of security mechanism that get used.

>> But then, I have no idea what "object-based security" is. The object- 
>> capability model? I'm not jumping. Oh, does this mean we are in for  
>> another six months of involved security discussion? (Wes's doc tree  
>> draft suggests that many things depend on the existing security work.)
> 
> It hasn't really been defined.  But think DRM as a sort of baseline.

Eek! Why? (I.e., what's needed there over and above the kind
of content protection that S/MIME or PGP could offer)

S.

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 16 Sep 2008 23:12:11 +0100
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

>>>> The e2e arguments strongly favouring the application hold in  
>>>> networks with closed control loops and tight coupling.
>>>
>>> but it holds in other networks too.  For example, when you place a  
>>> package into the postal network, you have some particular  
>>> expectation as to the general type of performance you will get.   
>>> And if you have an important document, say, you will keep a copy  
>>> at home in case your favorite postal carrier loses it somewhere.
>>
>> Of course. But saying 'leave it to the app!' presumes a closed loop  
>> and tight coupling.
>
> No, I do not agree with that statement at all.

Let me rephrase that slightly. Saying 'leave reliability _only_ to the  
app!' presumes a closed loop and tight coupling. Once the loop is  
opened between endpoint applications, the network assisting with  
reliability improves performance.

(For the postal service analogy - we could have mailboxes open to the  
weather and passersby, and just resend anything that gets soggy/ 
stolen, because hey, we keep copies. But we don't. The network assists.)

> There might be some performance requirements for a particular system  
> that requires a certain closeness of coupling, but to generalize  
> that to saying that closed loop with tight coupling is required in  
> order to put reliability actions within the application is an  
> unjustified leap.
>
>> Performance considerations may indicate that that is not enough
>
> Yes, agree.... for a particular set of performance requirements it  
> might not be enough.
>
>> - though in the closed-loop terrestrial internet where reachability  
>> is easy and resends are cheap, it is often adequate. (I can observe  
>> that spending a lot of time thinking about satellite PEPs helps  
>> with considering performance and what the terrestrial internet gets  
>> away with.)
>
> And I can observe that what has guided my thinking is 40-minute  
> round-trip times, or perhaps worse, unknown unbounded RTT's.  Then a  
> bunch of stuff becomes really hard.  And one thing I came to  
> appreciate in that environment is that even data that gets corrupted  
> in transit is still wanted by some people.

Yes - if you're postprocessing sensor data heavily, running it through  
filters etc. actively looking for corruption, or have a good idea what  
the data should look like with calibration (Earth remote sensing falls  
into that category) any data can be better than none, and corruption  
may be easy to spot.

But it is useful to know how and where the data was corrupted - and it  
is useful to know whether the metadata/headers to that data are  
trustworthy or not. If you have received two sensor data sets in  
parallel and you can't tell which data belongs in which set, the value  
of both sets is lessened considerably. (Analogous to the insidious NFS  
corruption discussed in the e2e papers.)

L.

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

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

From: Kevin Fall <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Tue, 16 Sep 2008 14:25:09 -0700
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

On Sep 16, 2008, at Sep 161:52 PMPDT, Lloyd Wood wrote:

>
> On 16 Sep 2008, at 19:06, Kevin Fall wrote:
>> I think of DTN as a "I will try very hard to get some data from  
>> here to there" type of transport.  If you protect that part ("the  
>> channel" if you will), using either checksums or cryptographic  
>> measures, you haven't solved the real data integrity problem(s) we  
>> have.  What I mean is that to really get at the integrity problem,  
>> we need to protect data at rest and in motion, and doing checksums  
>> or even cryptographic methods solely on the communication channel  
>> is not really sufficient.
>
> Yes. That is why relying on the convergence layer adaptors or per- 
> hop Bundle Authentication Block security for reliability of what is  
> sent is not sufficient. Those only cover the comms piece across  
> individual hops, while long-term storage in nodes is not covered by  
> those at all.

?  But I have never suggested relying on the reliability of CL's is  
sufficient for e2e reliability.  It can enhance it, but not provide  
it.  For precisely the bits of the e2e arguments we have both quoted,  
CLs are a useful partial piece of the solution that we can put into  
the network subsystem, but doing so is not sufficient.

>
>
> As it happens, this is _exactly_ the point we tried to make in the  
> detailed worked example in the checksum slides at:
> http://www.ietf.org/proceedings/08mar/DTNRG.html
> where we show what happens if there is corruption 'at rest', and how  
> end-to-end application performance is affected.

>
>
> (We were not given time to present that example in that session. It  
> took me days to work out and draw, too.

Well, I do not think there is much in the way of controversy, but your  
time is appreciated.

> I'd be grateful if you'd work through it and make sure you grok it.  
> It's written up near the end of the checksum draft in the aptly- 
> named '4. Performance Considerations' section.
> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-02#section-4
> in the -00 version it was in the security considerations section - I  
> came to the conclusion you've just articulated while sitting on a  
> beach in the Maldives last September, a whole year ago, and stuck it  
> in -00 when I got back.
> Oh, we'd appreciate feedback from all on this -02 version of the  
> draft before we send out -03.)
>
> A checksum wrapping an internal secured payload after security has  
> been applied allows protecting the data at rest, and allows checking  
> that the bundle is okay and uncorrupted -- even at third-party  
> untrusted nodes that do not have the appropriate security keys.

If I understand you, I might just agree... but its not clear to me  
this is part of the bundle protocol.

>
>
> (Doing this wrapping is not a security risk - just as an Ethernet  
> frame and CRC wrapping an IPsec packet does not put the IPsec  
> payload at risk. The router handles the CRC, and can't parse the  
> IPsec payload content.)

sure

>
>
>
>> I submit that if we had a more object-based security mechanism for  
>> most security issues we'd be far better off in the Internet today,  
>> with far fewer (e.g.) credit cards being hauled off to bad places.
>>
>> Now, before you all jump, object-based security isn't quite  
>> enough.  That's because the DoS class of attacks is, to me, rather  
>> different and it is useful to think of attacks on your ability to  
>> use a channel as being quite distinct from those that attempt to  
>> perform masquerades or to eavesdrop.   There's more to say here,  
>> but its something I've been thinking about for quite some time...
>
> I think that it helps to also be able to look at the overall  
> engineering of the system without bringing security in at every  
> point. I think it's fair to say that focusing solely on security can  
> colour one's thinking, and can perhaps even blind in certain ways.  
> And it certainly leads to a lot of security protocols.

IMHO, there is a tendency to try and put security in at every layer.   
Further, there is a tendency to try and protect the channel only  
[where channel is layer dependent].  I think its likely that the  
"best" architecture for security is some set of functions to try and  
provide connectivity when being jammed or during DoS events, plus  
another set of functions to be able to encode objects/messages in ways  
that reliably indicate who they are authored by, and possibly to  
encode them so as to be private.

>
>
> But then, I have no idea what "object-based security" is. The object- 
> capability model? I'm not jumping. Oh, does this mean we are in for  
> another six months of involved security discussion? (Wes's doc tree  
> draft suggests that many things depend on the existing security work.)

It hasn't really been defined.  But think DRM as a sort of baseline.

I'm not suggesting we throw out all the existing security work; I  
understand a number of people want the message-carrying layer to  
provide it.  But for my own personal interests, I'd like to imagine a  
world where security is mostly done above the messaging layer [and not  
in it].

>
>
>
>>> The e2e arguments strongly favouring the application hold in  
>>> networks with closed control loops and tight coupling.
>>
>> but it holds in other networks too.  For example, when you place a  
>> package into the postal network, you have some particular  
>> expectation as to the general type of performance you will get.   
>> And if you have an important document, say, you will keep a copy at  
>> home in case your favorite postal carrier loses it somewhere.
>
> Of course. But saying 'leave it to the app!' presumes a closed loop  
> and tight coupling.

No, I do not agree with that statement at all.  There might be some  
performance requirements for a particular system that requires a  
certain closeness of coupling, but to generalize that to saying that  
closed loop with tight coupling is required in order to put  
reliability actions within the application is an unjustified leap.

> Performance considerations may indicate that that is not enough

Yes, agree.... for a particular set of performance requirements it  
might not be enough.

> - though in the closed-loop terrestrial internet where reachability  
> is easy and resends are cheap, it is often adequate. (I can observe  
> that spending a lot of time thinking about satellite PEPs helps with  
> considering performance and what the terrestrial internet gets away  
> with.)

And I can observe that what has guided my thinking is 40-minute round- 
trip times, or perhaps worse, unknown unbounded RTT's.  Then a bunch  
of stuff becomes really hard.  And one thing I came to appreciate in  
that environment is that even data that gets corrupted in transit is  
still wanted by some people.

- K

>
>
>
>>> The application alone can give reliability, but the application  
>>> alone can't give performance. Which is why wireless mobiles  
>>> implement ARQ, etc.
>>
>> agreed.  In fact, I'd expand a little...  When you have a link  
>> using ARQ, its certainly believable that the relatively lower RTT  
>> [versus e2e] makes retransmission there comparatively efficient.
>
> yes - there's a well known ARQ/FEC tradeoff. Short delays favour  
> ARQ, while long delays favour FEC.
>
> Application resends are effectively application-level ARQ - which  
> aren't efficient across long-delay disconnected subnets, while path- 
> level FEC (rateless etc.) is expensive in terms of link capacity  
> needed to support it, and often ill-matched with the underlying  
> links and channels.
>
>
>> I'd further argue that its appropriate for some particular checksum  
>> to be used in that context as the link will have some particular  
>> error conditions that hopefully the link layer protocol designers  
>> know a bunch about.
>
> That's really an issue for coding of the link, not for checksums, to  
> address the (physical) channel conditions and turn them into  
> acceptable (logical) link conditions. Deciding what loss is  
> acceptable and where the checksum/coding and ARQ/FEC tradeoffs lie  
> is certainly a link design issue.
>
>
>> The place you and I differ, I think, is that I'd rather leave full  
>> e2e data integrity to either the application or the application as  
>> augmented by some library.
>
> ...whereas I'm very aware that that is the ultimate fallback, but  
> often does not give sufficient performance across the network.
>
> If performance wasn't needed, bundling wouldn't even have the  
> 'custody transfer' concept. (Which currently lacks a content  
> reliability check before the ack, so can't really be trusted imo.)
>
>
>> The reason comes from the e2e argument, and is covered in my  
>> previous e-mail and yours.
>>
>>>
>>> When the control loops are open and coupling is loose, as is the  
>>> case across multiple hops of many DTN networks where the endpoint  
>>> applications may never interact directly in the same connected  
>>> net, that above quoted sentence becomes very important.
>>
>> interesting.  So, if I get what you are trying to say, let me  
>> attempt to re-phrase.... you would say something like---
>> Although the application ultimately knows what it needs to do,  
>> sometimes it is so far removed or disconnected from the underlying  
>> infrastructure that it has to give up its control and become fully  
>> dependent on the underlying mechanisms.
>>
>> Would you agree with that statement?
>
> I would, but would add that even when the application is not  
> entirely removed or disconnected, there are good performance reasons  
> for not leaving things entirely to the app. Such as our previously  
> worked example. Or use of custody transfer.
>
>
>>> Good to see the relevant literature being read.
>>>
>>> Actually, following the e2e argument, the onus falls on the user,  
>>> not the application. Or the user's boss who delegated the task to  
>>> him...
>>
>> well, that may indeed be true.  Hitting "reload" on the browser is  
>> indeed one way of re-trying a e2e file transfer.
>
> HTTP, as deployed, is pretty loose as far as supporting e2e (end-to- 
> end or "edge-to-edge" between peer processes somewhere in the stack)  
> goes. Content-MD5: is rarely used, for example. TCP is really just a  
> stream; HTTP gives a chunked (pipelined) stream where web browsers  
> go to work on incomplete chunks they haven't bothered to check.
>
> L.
>
>> - K
>>> L.
>>>
>>> On 16 Sep 2008, at 01:02, Kevin Fall wrote:
>>>
>>>> No, I wouldn't exactly agree [I'm sure you are shocked. :P...].   
>>>> Quoting from the e2e argument paper:
>>>>
>>>> The function in question can completely and correctly be  
>>>> implemented only with the
>>>> knowledge and help of the application standing at the end points  
>>>> of the communication
>>>> system. Therefore, providing that questioned function as a  
>>>> feature of the communication
>>>> system itself is not possible. (Sometimes an incomplete version  
>>>> of the function provided
>>>> by the communication system may be useful as a performance  
>>>> enhancement.)
>>>>
>>>> This argument in fact argues that the function cannot reside
>>>> in the communication system [which an overlay is one of].   
>>>> Further reading just drives the point home
>>>> further:
>>>>
>>>> ...The
>>>> application program follows the simple steps above in  
>>>> transferring the file from A to B. Then, as
>>>> a final additional step, the part of the file transfer  
>>>> application residing in host B reads the
>>>> transferred file copy back from its disk storage system into its  
>>>> own memory, recalculates the
>>>> checksum, and sends this value back to host A, where it is  
>>>> compared with the checksum of the
>>>> original. Only if the two checksums agree does the file transfer  
>>>> application declare the transaction
>>>> committed. If the comparison fails, something went wrong, and a  
>>>> retry from the beginning might
>>>> be attempted.
>>>> If failures really are fairly rare, this technique will normally  
>>>> work on the first try; occasionally a
>>>> second or even third try might be required; one would probably  
>>>> consider two or more failures on
>>>> the same file transfer attempt as indicating that some part of  
>>>> the system is in need of repair.
>>>> Now let us consider the usefulness of a common proposal, namely  
>>>> that the communication
>>>> system provide, internally, a guarantee of reliable data  
>>>> transmission. It might accomplish this
>>>> guarantee by providing selective redundancy in the form of packet  
>>>> checksums, sequence number
>>>> checking, and internal retry mechanisms, for example. With  
>>>> sufficient care, the probability of
>>>> undetected bit errors can be reduced to any desirable level. The  
>>>> question is whether or not this
>>>> attempt to be helpful on the part of the communication system is  
>>>> useful to the careful file transfer
>>>> application.
>>>> The answer is that threat number four may have been eliminated,  
>>>> but the careful file transfer
>>>> application must still counter the remaining threats, so it  
>>>> should still provide its own retries based
>>>> on an end-to-end checksum of the file.
>>>>
>>>> So, to really be following the 'end-to-end argument' you need to  
>>>> take action at the application.  Note that TCP/IP would thus not  
>>>> qualify, despite all the suggestions to the contrary...
>>>>
>>>> - K
>>>>
>>>> On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:
>>>>
>>>>>
>>>>> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>>>>>
>>>>>> well, this is somewhat true, but in being an overlay you can
>>>>>> implement countermeasures that mitigate some of the problems.
>>>>>
>>>>> such as the end-to-end principle being a countermeasure against an
>>>>> unreliable underlying network infrastructure?
>>>>>
>>>>> L.
>>>>>
>>>>>>
>>>>>>
>>>>>> For example, the RON overlay would do routing that was arguably
>>>>>> 'better' than that provided by BGP.
>>>>>> DTN can, for example, can make more than one copy of a message,
>>>>>> which may improve the probability of ultimately delivery.
>>>>>>
>>>>>> The Amherst folks also observe that even an unauthenticated DTN  
>>>>>> is
>>>>>> relatively more secure than the alternative:
>>>>>> http://portal.acm.org/citation.cfm? 
>>>>>> id=1288116&jmp=cit&coll=&dl=ACM
>>>>>>
>>>>>> - K
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]
>>>>>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>>>>>> Sent: Monday, September 15, 2008 8:34 AM
>>>>>> To: [email-masked]
>>>>>> Subject: [dtn-interest] Underlying Networks
>>>>>>
>>>>>> Would it be fair to say that the DTN architecture , as a network
>>>>>> overlay, (and probably any network overlay - DTN or otherwise)
>>>>>> inherits
>>>>>> and can exploit all to good characteristics of the underlying  
>>>>>> network,
>>>>>> but also inherits and can be exploited by the bad.  Some examples
>>>>>> would
>>>>>> be security, routing, discovery etc....
>>>>>>
>>>>>>
>>>>>> /will
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
>

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 16 Sep 2008 21:52:10 +0100
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

On 16 Sep 2008, at 19:06, Kevin Fall wrote:
> I think of DTN as a "I will try very hard to get some data from here  
> to there" type of transport.  If you protect that part ("the  
> channel" if you will), using either checksums or cryptographic  
> measures, you haven't solved the real data integrity problem(s) we  
> have.  What I mean is that to really get at the integrity problem,  
> we need to protect data at rest and in motion, and doing checksums  
> or even cryptographic methods solely on the communication channel is  
> not really sufficient.

Yes. That is why relying on the convergence layer adaptors or per-hop  
Bundle Authentication Block security for reliability of what is sent  
is not sufficient. Those only cover the comms piece across individual  
hops, while long-term storage in nodes is not covered by those at all.

As it happens, this is _exactly_ the point we tried to make in the  
detailed worked example in the checksum slides at:
http://www.ietf.org/proceedings/08mar/DTNRG.html
where we show what happens if there is corruption 'at rest', and how  
end-to-end application performance is affected.

(We were not given time to present that example in that session. It  
took me days to work out and draw, too. I'd be grateful if you'd work  
through it and make sure you grok it. It's written up near the end of  
the checksum draft in the aptly-named '4. Performance Considerations'  
section.
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum-02#section-4
in the -00 version it was in the security considerations section - I  
came to the conclusion you've just articulated while sitting on a  
beach in the Maldives last September, a whole year ago, and stuck it  
in -00 when I got back.
Oh, we'd appreciate feedback from all on this -02 version of the draft  
before we send out -03.)

A checksum wrapping an internal secured payload after security has  
been applied allows protecting the data at rest, and allows checking  
that the bundle is okay and uncorrupted -- even at third-party  
untrusted nodes that do not have the appropriate security keys.

(Doing this wrapping is not a security risk - just as an Ethernet  
frame and CRC wrapping an IPsec packet does not put the IPsec payload  
at risk. The router handles the CRC, and can't parse the IPsec payload  
content.)

>  I submit that if we had a more object-based security mechanism for  
> most security issues we'd be far better off in the Internet today,  
> with far fewer (e.g.) credit cards being hauled off to bad places.
>
> Now, before you all jump, object-based security isn't quite enough.   
> That's because the DoS class of attacks is, to me, rather different  
> and it is useful to think of attacks on your ability to use a  
> channel as being quite distinct from those that attempt to perform  
> masquerades or to eavesdrop.   There's more to say here, but its  
> something I've been thinking about for quite some time...

I think that it helps to also be able to look at the overall  
engineering of the system without bringing security in at every point.  
I think it's fair to say that focusing solely on security can colour  
one's thinking, and can perhaps even blind in certain ways. And it  
certainly leads to a lot of security protocols.

But then, I have no idea what "object-based security" is. The object- 
capability model? I'm not jumping. Oh, does this mean we are in for  
another six months of involved security discussion? (Wes's doc tree  
draft suggests that many things depend on the existing security work.)

>> The e2e arguments strongly favouring the application hold in  
>> networks with closed control loops and tight coupling.
>
> but it holds in other networks too.  For example, when you place a  
> package into the postal network, you have some particular  
> expectation as to the general type of performance you will get.  And  
> if you have an important document, say, you will keep a copy at home  
> in case your favorite postal carrier loses it somewhere.

Of course. But saying 'leave it to the app!' presumes a closed loop  
and tight coupling. Performance considerations may indicate that that  
is not enough - though in the closed-loop terrestrial internet where  
reachability is easy and resends are cheap, it is often adequate. (I  
can observe that spending a lot of time thinking about satellite PEPs  
helps with considering performance and what the terrestrial internet  
gets away with.)

>> The application alone can give reliability, but the application  
>> alone can't give performance. Which is why wireless mobiles  
>> implement ARQ, etc.
>
> agreed.  In fact, I'd expand a little...  When you have a link using  
> ARQ, its certainly believable that the relatively lower RTT [versus  
> e2e] makes retransmission there comparatively efficient.

yes - there's a well known ARQ/FEC tradeoff. Short delays favour ARQ,  
while long delays favour FEC.

Application resends are effectively application-level ARQ - which  
aren't efficient across long-delay disconnected subnets, while path- 
level FEC (rateless etc.) is expensive in terms of link capacity  
needed to support it, and often ill-matched with the underlying links  
and channels.

>  I'd further argue that its appropriate for some particular checksum  
> to be used in that context as the link will have some particular  
> error conditions that hopefully the link layer protocol designers  
> know a bunch about.

That's really an issue for coding of the link, not for checksums, to  
address the (physical) channel conditions and turn them into  
acceptable (logical) link conditions. Deciding what loss is acceptable  
and where the checksum/coding and ARQ/FEC tradeoffs lie is certainly a  
link design issue.

> The place you and I differ, I think, is that I'd rather leave full  
> e2e data integrity to either the application or the application as  
> augmented by some library.

...whereas I'm very aware that that is the ultimate fallback, but  
often does not give sufficient performance across the network.

If performance wasn't needed, bundling wouldn't even have the 'custody  
transfer' concept. (Which currently lacks a content reliability check  
before the ack, so can't really be trusted imo.)

> The reason comes from the e2e argument, and is covered in my  
> previous e-mail and yours.
>
>>
>> When the control loops are open and coupling is loose, as is the  
>> case across multiple hops of many DTN networks where the endpoint  
>> applications may never interact directly in the same connected net,  
>> that above quoted sentence becomes very important.
>
> interesting.  So, if I get what you are trying to say, let me  
> attempt to re-phrase.... you would say something like---
> Although the application ultimately knows what it needs to do,  
> sometimes it is so far removed or disconnected from the underlying  
> infrastructure that it has to give up its control and become fully  
> dependent on the underlying mechanisms.
>
> Would you agree with that statement?

I would, but would add that even when the application is not entirely  
removed or disconnected, there are good performance reasons for not  
leaving things entirely to the app. Such as our previously worked  
example. Or use of custody transfer.

>> Good to see the relevant literature being read.
>>
>> Actually, following the e2e argument, the onus falls on the user,  
>> not the application. Or the user's boss who delegated the task to  
>> him...
>
> well, that may indeed be true.  Hitting "reload" on the browser is  
> indeed one way of re-trying a e2e file transfer.

HTTP, as deployed, is pretty loose as far as supporting e2e (end-to- 
end or "edge-to-edge" between peer processes somewhere in the stack)  
goes. Content-MD5: is rarely used, for example. TCP is really just a  
stream; HTTP gives a chunked (pipelined) stream where web browsers go  
to work on incomplete chunks they haven't bothered to check.

L.

> - K
>> L.
>>
>> On 16 Sep 2008, at 01:02, Kevin Fall wrote:
>>
>>> No, I wouldn't exactly agree [I'm sure you are shocked. :P...].   
>>> Quoting from the e2e argument paper:
>>>
>>> The function in question can completely and correctly be  
>>> implemented only with the
>>> knowledge and help of the application standing at the end points  
>>> of the communication
>>> system. Therefore, providing that questioned function as a feature  
>>> of the communication
>>> system itself is not possible. (Sometimes an incomplete version of  
>>> the function provided
>>> by the communication system may be useful as a performance  
>>> enhancement.)
>>>
>>> This argument in fact argues that the function cannot reside
>>> in the communication system [which an overlay is one of].  Further  
>>> reading just drives the point home
>>> further:
>>>
>>> ...The
>>> application program follows the simple steps above in transferring  
>>> the file from A to B. Then, as
>>> a final additional step, the part of the file transfer application  
>>> residing in host B reads the
>>> transferred file copy back from its disk storage system into its  
>>> own memory, recalculates the
>>> checksum, and sends this value back to host A, where it is  
>>> compared with the checksum of the
>>> original. Only if the two checksums agree does the file transfer  
>>> application declare the transaction
>>> committed. If the comparison fails, something went wrong, and a  
>>> retry from the beginning might
>>> be attempted.
>>> If failures really are fairly rare, this technique will normally  
>>> work on the first try; occasionally a
>>> second or even third try might be required; one would probably  
>>> consider two or more failures on
>>> the same file transfer attempt as indicating that some part of the  
>>> system is in need of repair.
>>> Now let us consider the usefulness of a common proposal, namely  
>>> that the communication
>>> system provide, internally, a guarantee of reliable data  
>>> transmission. It might accomplish this
>>> guarantee by providing selective redundancy in the form of packet  
>>> checksums, sequence number
>>> checking, and internal retry mechanisms, for example. With  
>>> sufficient care, the probability of
>>> undetected bit errors can be reduced to any desirable level. The  
>>> question is whether or not this
>>> attempt to be helpful on the part of the communication system is  
>>> useful to the careful file transfer
>>> application.
>>> The answer is that threat number four may have been eliminated,  
>>> but the careful file transfer
>>> application must still counter the remaining threats, so it should  
>>> still provide its own retries based
>>> on an end-to-end checksum of the file.
>>>
>>> So, to really be following the 'end-to-end argument' you need to  
>>> take action at the application.  Note that TCP/IP would thus not  
>>> qualify, despite all the suggestions to the contrary...
>>>
>>> - K
>>>
>>> On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:
>>>
>>>>
>>>> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>>>>
>>>>> well, this is somewhat true, but in being an overlay you can
>>>>> implement countermeasures that mitigate some of the problems.
>>>>
>>>> such as the end-to-end principle being a countermeasure against an
>>>> unreliable underlying network infrastructure?
>>>>
>>>> L.
>>>>
>>>>>
>>>>>
>>>>> For example, the RON overlay would do routing that was arguably
>>>>> 'better' than that provided by BGP.
>>>>> DTN can, for example, can make more than one copy of a message,
>>>>> which may improve the probability of ultimately delivery.
>>>>>
>>>>> The Amherst folks also observe that even an unauthenticated DTN is
>>>>> relatively more secure than the alternative:
>>>>> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>>>>>
>>>>> - K
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]
>>>>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>>>>> Sent: Monday, September 15, 2008 8:34 AM
>>>>> To: [email-masked]
>>>>> Subject: [dtn-interest] Underlying Networks
>>>>>
>>>>> Would it be fair to say that the DTN architecture , as a network
>>>>> overlay, (and probably any network overlay - DTN or otherwise)
>>>>> inherits
>>>>> and can exploit all to good characteristics of the underlying  
>>>>> network,
>>>>> but also inherits and can be exploited by the bad.  Some examples
>>>>> would
>>>>> be security, routing, discovery etc....
>>>>>
>>>>>
>>>>> /will

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

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

From: Kevin Fall <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Tue, 16 Sep 2008 11:06:45 -0700
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

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

On Sep 15, 2008, at Sep 155:21 PMPDT, Lloyd Wood wrote:

> Note the:
>> (Sometimes an incomplete version of the function provided
>> by the communication system may be useful as a performance  
>> enhancement.)
>
>
> indicating that the function can, in fact, reside in the comms  
> system in a way. As it commonly does with TCP/IP and the pseudoheader.

Right.  The "in a way" is interesting to me.  The paper uses the  
phrase 'incomplete version' as you have excerpted.  This is true by  
the construction they have used.  For example, yes, you can put the  
pseudoheader cksum in TCP and IP, but if the TCP checksum isn't strong  
enough, or there are errors in the Application-API interface  
implementation, you still don't have what you really want.  For DTN, I  
was compelled more by the e2e argument in the paper than by the use of  
checksums in TCP or other common protocols.  Also, you may be  
interested to know that I didn't want [some of the] security  
[features] in the DTN protocols either.  (I seem to have lost that  
one, but I digress).  But here is why:

I think of DTN as a "I will try very hard to get some data from here  
to there" type of transport.  If you protect that part ("the channel"  
if you will), using either checksums or cryptographic measures, you  
haven't solved the real data integrity problem(s) we have.  What I  
mean is that to really get at the integrity problem, we need to  
protect data at rest and in motion, and doing checksums or even  
cryptographic methods solely on the communication channel is not  
really sufficient.  I submit that if we had a more object-based  
security mechanism for most security issues we'd be far better off in  
the Internet today, with far fewer (e.g.) credit cards being hauled  
off to bad places.

Now, before you all jump, object-based security isn't quite enough.   
That's because the DoS class of attacks is, to me, rather different  
and it is useful to think of attacks on your ability to use a channel  
as being quite distinct from those that attempt to perform masquerades  
or to eavesdrop.   There's more to say here, but its something I've  
been thinking about for quite some time...

>
> The e2e arguments strongly favouring the application hold in  
> networks with closed control loops and tight coupling.

but it holds in other networks too.  For example, when you place a  
package into the postal network, you have some particular expectation  
as to the general type of performance you will get.  And if you have  
an important document, say, you will keep a copy at home in case your  
favorite postal carrier loses it somewhere.

>
> The application alone can give reliability, but the application  
> alone can't give performance. Which is why wireless mobiles  
> implement ARQ, etc.

agreed.  In fact, I'd expand a little...  When you have a link using  
ARQ, its certainly believable that the relatively lower RTT [versus  
e2e] makes retransmission there comparatively efficient.  I'd further  
argue that its appropriate for some particular checksum to be used in  
that context as the link will have some particular error conditions  
that hopefully the link layer protocol designers know a bunch about.   
The place you and I differ, I think, is that I'd rather leave full e2e  
data integrity to either the application or the application as  
augmented by some library.  The reason comes from the e2e argument,  
and is covered in my previous e-mail and yours.

>
> When the control loops are open and coupling is loose, as is the  
> case across multiple hops of many DTN networks where the endpoint  
> applications may never interact directly in the same connected net,  
> that above quoted sentence becomes very important.

interesting.  So, if I get what you are trying to say, let me attempt  
to re-phrase.... you would say something like---
Although the application ultimately knows what it needs to do,  
sometimes it is so far removed or disconnected from the underlying  
infrastructure that it has to give up its control and become fully  
dependent on the underlying mechanisms.

Would you agree with that statement?

>
> Good to see the relevant literature being read.
>
> Actually, following the e2e argument, the onus falls on the user,  
> not the application. Or the user's boss who delegated the task to  
> him...

well, that may indeed be true.  Hitting "reload" on the browser is  
indeed one way of re-trying a e2e file transfer.

- K

>
> L.
>
> On 16 Sep 2008, at 01:02, Kevin Fall wrote:
>
>> No, I wouldn't exactly agree [I'm sure you are shocked. :P...].   
>> Quoting from the e2e argument paper:
>>
>> The function in question can completely and correctly be  
>> implemented only with the
>> knowledge and help of the application standing at the end points of  
>> the communication
>> system. Therefore, providing that questioned function as a feature  
>> of the communication
>> system itself is not possible. (Sometimes an incomplete version of  
>> the function provided
>> by the communication system may be useful as a performance  
>> enhancement.)
>>
>> This argument in fact argues that the function cannot reside
>> in the communication system [which an overlay is one of].  Further  
>> reading just drives the point home
>> further:
>>
>> ...The
>> application program follows the simple steps above in transferring  
>> the file from A to B. Then, as
>> a final additional step, the part of the file transfer application  
>> residing in host B reads the
>> transferred file copy back from its disk storage system into its  
>> own memory, recalculates the
>> checksum, and sends this value back to host A, where it is compared  
>> with the checksum of the
>> original. Only if the two checksums agree does the file transfer  
>> application declare the transaction
>> committed. If the comparison fails, something went wrong, and a  
>> retry from the beginning might
>> be attempted.
>> If failures really are fairly rare, this technique will normally  
>> work on the first try; occasionally a
>> second or even third try might be required; one would probably  
>> consider two or more failures on
>> the same file transfer attempt as indicating that some part of the  
>> system is in need of repair.
>> Now let us consider the usefulness of a common proposal, namely  
>> that the communication
>> system provide, internally, a guarantee of reliable data  
>> transmission. It might accomplish this
>> guarantee by providing selective redundancy in the form of packet  
>> checksums, sequence number
>> checking, and internal retry mechanisms, for example. With  
>> sufficient care, the probability of
>> undetected bit errors can be reduced to any desirable level. The  
>> question is whether or not this
>> attempt to be helpful on the part of the communication system is  
>> useful to the careful file transfer
>> application.
>> The answer is that threat number four may have been eliminated, but  
>> the careful file transfer
>> application must still counter the remaining threats, so it should  
>> still provide its own retries based
>> on an end-to-end checksum of the file.
>>
>> So, to really be following the 'end-to-end argument' you need to  
>> take action at the application.  Note that TCP/IP would thus not  
>> qualify, despite all the suggestions to the contrary...
>>
>> - K
>>
>> On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:
>>
>>>
>>> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>>>
>>>> well, this is somewhat true, but in being an overlay you can
>>>> implement countermeasures that mitigate some of the problems.
>>>
>>> such as the end-to-end principle being a countermeasure against an
>>> unreliable underlying network infrastructure?
>>>
>>> L.
>>>
>>>>
>>>>
>>>> For example, the RON overlay would do routing that was arguably
>>>> 'better' than that provided by BGP.
>>>> DTN can, for example, can make more than one copy of a message,
>>>> which may improve the probability of ultimately delivery.
>>>>
>>>> The Amherst folks also observe that even an unauthenticated DTN is
>>>> relatively more secure than the alternative:
>>>> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>>>>
>>>> - K
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]
>>>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>>>> Sent: Monday, September 15, 2008 8:34 AM
>>>> To: [email-masked]
>>>> Subject: [dtn-interest] Underlying Networks
>>>>
>>>> Would it be fair to say that the DTN architecture , as a network
>>>> overlay, (and probably any network overlay - DTN or otherwise)
>>>> inherits
>>>> and can exploit all to good characteristics of the underlying  
>>>> network,
>>>> but also inherits and can be exploited by the bad.  Some examples
>>>> would
>>>> be security, routing, discovery etc....
>>>>
>>>>
>>>> /will
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>>
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>>
>>> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--Apple-Mail-41-615553197
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; "><br><div><div>On Sep 15, 2008, =
at Sep 155:21 PMPDT, Lloyd Wood wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Note the:<br><div><blockquote =
type=3D"cite"><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">(Sometimes an incomplete version of the function =
provided<span style=3D"font: normal normal normal 12px/normal Helvetica; =
">&nbsp;</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">by the communication system may be useful as a =
performance =
enhancement.)</div></blockquote></div><div><br></div><div>indicating =
that the function can, in fact, reside in the comms system in a way. As =
it commonly does with TCP/IP and the =
pseudoheader.</div></div></blockquote><div><br></div><div>Right. =
&nbsp;The "in a way" is interesting to me. &nbsp;The paper uses the =
phrase 'incomplete version' as you have excerpted. &nbsp;This is true by =
the construction they have used. &nbsp;For example, yes, you can put the =
pseudoheader cksum in TCP and IP, but if the TCP checksum isn't strong =
enough, or there are errors in the Application-API interface =
implementation, you still don't have what you really want. &nbsp;For =
DTN, I was compelled more by the e2e argument in the paper than by the =
use of checksums in TCP or other common protocols. &nbsp;Also, you may =
be interested to know that I didn't want [some of the] security =
[features] in the DTN protocols either. &nbsp;(I seem to have lost that =
one, but I digress). &nbsp;But here is why:</div><div><br></div><div>I =
think of DTN as a "I will try very hard to get some data from here to =
there" type of transport. &nbsp;If you protect that part ("the channel" =
if you will), using either checksums or cryptographic measures, you =
haven't solved the real data integrity problem(s) we have. &nbsp;What I =
mean is that to really get at the integrity problem, we need to protect =
data at rest and in motion, and doing checksums or even cryptographic =
methods solely on the communication channel is not really sufficient. =
&nbsp;I submit that if we had a more object-based security mechanism for =
most security issues we'd be far better off in the Internet today, with =
far fewer (e.g.) credit cards being hauled off to bad =
places.</div><div><br></div><div>Now, before you all jump, object-based =
security isn't quite enough. &nbsp;That's because the DoS class of =
attacks is, to me, rather different and it is useful to think of attacks =
on your ability to use a channel as being quite distinct from those that =
attempt to perform masquerades or to eavesdrop. &nbsp; There's more to =
say here, but its something I've been thinking about for quite some =
time...</div><br><blockquote type=3D"cite"><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><br></div><div>The e2e arguments =
strongly&nbsp;favouring the application hold in networks with closed =
control loops and tight =
coupling.</div></div></blockquote><div><br></div>but it holds in other =
networks too. &nbsp;For example, when you place a package into the =
postal network, you have some particular expectation as to the general =
type of performance you will get. &nbsp;And if you have an important =
document, say, you will keep a copy at home in case your favorite postal =
carrier loses it somewhere.</div><div><br><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><br></div><div>The =
application alone can give reliability, but the application alone can't =
give performance. Which is why wireless mobiles implement ARQ, =
etc.</div></div></blockquote><div><br></div>agreed. &nbsp;In fact, I'd =
expand a little... &nbsp;When you have a link using ARQ, its certainly =
believable that the relatively lower RTT [versus e2e] makes =
retransmission there comparatively efficient. &nbsp;I'd further argue =
that its appropriate for some particular checksum to be used in that =
context as the link will have some particular error conditions that =
hopefully the link layer protocol designers know a bunch about. =
&nbsp;The place you and I differ, I think, is that I'd rather leave full =
e2e data integrity to either the application or the application as =
augmented by some library. &nbsp;The reason comes from the e2e argument, =
and is covered in my previous e-mail and =
yours.</div><div><br><blockquote type=3D"cite"><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><br></div><div>When the control loops are open =
and coupling is loose, as is the case across multiple hops of many DTN =
networks where the endpoint applications may never interact directly in =
the same connected net, that above quoted sentence becomes very =
important.</div></div></blockquote><div><br></div>interesting. &nbsp;So, =
if I get what you are trying to say, let me attempt to re-phrase.... you =
would say something like---</div><div>Although the application =
ultimately knows what it needs to do, sometimes it is so far removed or =
disconnected from the underlying infrastructure that it has to give up =
its control and become fully dependent on the underlying =
mechanisms.</div><div><br></div><div>Would you agree with that =
statement?</div><div><br><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><br></div><div>Good to see =
the relevant literature being read.</div><div><br></div><div>Actually, =
following the e2e argument, the onus falls on the user, not the =
application. Or the user's boss who delegated the task to =
him...</div></div></blockquote><div><br></div><div>well, that may indeed =
be true. &nbsp;Hitting "reload" on the browser is indeed one way of =
re-trying a e2e file transfer.</div><div><br></div><div>- =
K</div><br><blockquote type=3D"cite"><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><br></div><div>L.</div><div><br><div><div>On =
16 Sep 2008, at 01:02, Kevin Fall wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">No, I wouldn't exactly agree =
[I'm sure you are shocked. :P...]. &nbsp;Quoting from the e2e argument =
paper:<div><br></div><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">The function in question can completely and =
correctly be implemented only with the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">knowledge and help of the application =
standing at the end points of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system. Therefore, providing that =
questioned function as a feature of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system itself is not possible. =
(Sometimes an incomplete version of the function provided<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">by the =
communication system may be useful as a performance =
enhancement.)</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">This argument in fact argues that the =
function cannot reside</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">in the communication system [which an overlay =
is one of]. &nbsp;Further reading just drives the point =
home</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"5"><span class=3D"Apple-style-span" style=3D"font-size: =
18px;">further:</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">...The<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application program follows the simple steps above in transferring the =
file from A to B. Then, as<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">a final additional step, the part of =
the file transfer application residing in host B reads the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">transferred file copy back from its disk storage system into its own =
memory, recalculates the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checksum, and sends this value back =
to host A, where it is compared with the checksum of the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">original. Only if the two checksums agree does the file transfer =
application declare the transaction<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">committed. If the comparison fails, =
something went wrong, and a retry from the beginning might<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">be =
attempted.<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">If =
failures really are fairly rare, this technique will normally work on =
the first try; occasionally a<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">second or even third try might be =
required; one would probably consider two or more failures on<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">the =
same file transfer attempt as indicating that some part of the system is =
in need of repair.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">Now let us consider the usefulness of =
a common proposal, namely that the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system provide, internally, a =
guarantee of reliable data transmission. It might accomplish this<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">guarantee by providing selective redundancy in the form of packet =
checksums, sequence number<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checking, and internal retry =
mechanisms, for example. With sufficient care, the probability of<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">undetected bit errors can be reduced to any desirable level. The =
question is whether or not this<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">attempt to be helpful on the part of =
the communication system is useful to the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">The answer is that threat number four =
may have been eliminated, but the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application must still counter the remaining threats, so it should =
still provide its own retries based<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">on an end-to-end checksum of the =
file.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">So, to really be following the 'end-to-end =
argument' you need to take action at the application. &nbsp;Note that =
TCP/IP would thus not qualify, despite all the suggestions to the =
contrary...</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;">- =
K</span></font></div></span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><br></div><div><div>On Sep 15, 2008, =
at Sep 154:38 PMPDT, Lloyd Wood wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>On =
15 Sep 2008, at 23:25, Fall, Kevin wrote:<br><br><blockquote =
type=3D"cite">well, this is somewhat true, but in being an overlay you =
can &nbsp;<br></blockquote><blockquote type=3D"cite">implement =
countermeasures that mitigate some of the =
problems.<br></blockquote><br>such as the end-to-end principle being a =
countermeasure against an &nbsp;<br>unreliable underlying network =
infrastructure?<br><br>L.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">For example, =
the RON overlay would do routing that was arguably =
&nbsp;<br></blockquote><blockquote type=3D"cite">'better' than that =
provided by BGP.<br></blockquote><blockquote type=3D"cite">DTN can, for =
example, can make more than one copy of a message, =
&nbsp;<br></blockquote><blockquote type=3D"cite">which may improve the =
probability of ultimately delivery.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The Amherst =
folks also observe that even an unauthenticated DTN is =
&nbsp;<br></blockquote><blockquote type=3D"cite">relatively more secure =
than the alternative:<br></blockquote><blockquote type=3D"cite"><a =
href=3D"http://portal.acm.org/citation.cfm?id=3D1288116&amp;jmp=3Dcit&amp;=
coll=3D&amp;dl=3DACM">http://portal.acm.org/citation.cfm?id=3D1288116&amp;=
jmp=3Dcit&amp;coll=3D&amp;dl=3DACM</a><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">- =
K<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-----Original Message-----<br></blockquote><blockquote =
type=3D"cite">From: <a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> [<a =
href=3D"mailto:[email-masked]">mailto:d=
[email-masked]</a> =
<br></blockquote><blockquote type=3D"cite">] On Behalf Of Ivancic, =
William D. (GRC-RHN0)<br></blockquote><blockquote type=3D"cite">Sent: =
Monday, September 15, 2008 8:34 AM<br></blockquote><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br></blockquote><blockquote type=3D"cite">Subject: =
[dtn-interest] Underlying Networks<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Would it be =
fair to say that the DTN architecture , as a =
network<br></blockquote><blockquote type=3D"cite">overlay, (and probably =
any network overlay - DTN or otherwise) =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">inherits<br></blockquote><blockquote type=3D"cite">and can =
exploit all to good characteristics of the underlying =
network,<br></blockquote><blockquote type=3D"cite">but also inherits and =
can be exploited by the bad. &nbsp;Some examples =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">would<br></blockquote><blockquote type=3D"cite">be =
security, routing, discovery etc....<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">/will<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br>DTN work: <a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a><br><br>&lt;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br><br><br><b=
r><br><br>_______________________________________________<br>dtn-interest =
mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
<br></div></blockquote></div><br></div></div></blockquote></div><br><div =
apple-content-edited=3D"true"> <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; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div>DTN work:&nbsp;<a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a></div><div><br></div><div>&l=
t;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></div><div><br=
></div></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"> =
</div><br></div></div>_______________________________________________<br>d=
tn-interest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></blockquote></div><br></body></html>=

--Apple-Mail-41-615553197--

Content-class: urn:content-classes:message
Date: Tue, 16 Sep 2008 11:22:07 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

All,

Thanks for the discussion.  A simple yes or no would have done .....
Just kidding!

Actually, I was thinking along the lines of Kevin's response.  

I was also thinking about some ideas I think I heard that there isn't
really a need for things like DNS when, to me the Identity to name to
route to physical address becomes increasingly complex as one inherits
the underlying network.  But let's not discuss that in this thread.
Rather, a naming thread would be better.  

/will

> -----Original Message-----
> From: Fall, Kevin [mailto:[email-masked]] 
> Sent: Monday, September 15, 2008 6:25 PM
> To: Ivancic, William D. (GRC-RHN0); [email-masked]
> Subject: RE: Underlying Networks
> 
> well, this is somewhat true, but in being an overlay you can 
> implement countermeasures that mitigate some of the problems.
> 
> For example, the RON overlay would do routing that was 
> arguably 'better' than that provided by BGP.
> DTN can, for example, can make more than one copy of a 
> message, which may improve the probability of ultimately delivery.
> 
> The Amherst folks also observe that even an unauthenticated 
> DTN is relatively more secure than the alternative:
> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
> 
> - K
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On 
> Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Monday, September 15, 2008 8:34 AM
> To: [email-masked]
> Subject: [dtn-interest] Underlying Networks
> 
> Would it be fair to say that the DTN architecture , as a 
> network overlay, (and probably any network overlay - DTN or 
> otherwise) inherits and can exploit all to good 
> characteristics of the underlying network, but also inherits 
> and can be exploited by the bad.  Some examples would be 
> security, routing, discovery etc....
> 
> 
> /will
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

From: Lloyd Wood <[email-masked]>
To: "Symington, Susan F." <[email-masked]>
Date: Tue, 16 Sep 2008 16:31:44 +0100
Cc: [email-masked], Lloyd Wood <[email-masked]>, "Eddy, Wesley M. \(GRC-RCN0\)\[VZ\]" <[email-masked]>
Subject: Re: [dtn-interest] Meeting frequency

--Apple-Mail-3-606252688
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable

On 16 Sep 2008, at 15:29, Symington, Susan F. wrote:

> This is a good list. Thanks for putting it together. I have a few =20
> changes:
>
> 1.       I agree with Rajesh that it=92s probably better to move the =20=

> metadata block to the generic category. Also, just a few hours =20
> before you sent this list out I happened to update two of the I-Ds. =20=

> One of them was the metadata block. It now has a September 2008 =20
> date, and is called =93draft-irtf-dtnrg-bundle-metadata-block-00=94. =20=

> (You can already see that keeping this document up-to-date is going =20=

> to be a steady job.)

I suggest simply skipping including -nn in the body of the doc and =20
just insert urls of the form:
http://tools.ietf.org/html/draft-wood-dtnrg-saratoga

which provide a history. A full reference section can provide the =20
detailed -nn info, names, dates etc - useful as a snapshot of a point =20=

in time when the doc was rendered to text and submitted (especially if =20=

there are later major changes to docs lineage, adoption by the group =20
etc.), but not as immediately useful as the urls above for figuring =20
out what doc is being talked about.

An 'expired/historical docs' section would also be useful to indicate =20=

what docs don't need to be looked at, and why - per Susan's point 2 =20
below. e.g the eddy checksum drafts have been superseded by the irtf =20
draft, etc.

L.

> 2.       I would delete the draft that you have listed in the =20
> Multicast Extensions category and replace it with the following =20
> draft: draft-symington-dtnrg-bundle-multicast-custodial-04 (May =20
> 2008). The I-D that you have listed (noncustodial multicast) was =20
> abandoned as unnecessary when we ensured that the Bundle Protocol =20
> spec itself  supports non-custodial multicasting. You should =20
> probably call the Multicast Extensions category the =93Custodial =20
> Multicast Extensions=94 category, since the draft that I=92m asking =
you =20
> to put in there is specifically for custodial multicast. Right now, =20=

> the Bundle Protocol Spec supports non-custodial multicast as is, =20
> without requiring any extensions.
> 3.       There is one I-D missing: draft-irtf-dtnrg-bundle-previous-=20=

> hop-block-04 (September 2008). This should probably go in the =20
> generic category, though some might argue for it to go in the =20
> routing category. Basically, it is the block that enables a bundle =20
> protocol agent to learn the endpoint ID of the bundle protocol agent =20=

> that forwarded the bundle to it. An obvious use of this block is to =20=

> support flood routing, to ensure that a bundle is not forwarded back =20=

> out to the bundle protocol agent from which it was received. =20
> However, I imagine that there may be non-routing uses of this block.
>
> Thanks again. This document tree will be very helpful, not only for =20=

> new people but for all of us to keep track.
>
> -susan
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
> From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[email-masked]]
> Sent: Sunday, September 14, 2008 8:33 PM
> To: Stephen Farrell
> Cc: Symington, Susan F.; Lloyd Wood; [email-masked]
> Subject: RE: [dtn-interest] Meeting frequency
>
> Here's a first cut at a draft; it may be missing a couple docs =20
> still, so clue me in if I've forgotten anything.
>
>
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Fri 9/12/2008 1:35 PM
> To: Eddy, Wesley M. (GRC-RCN0)[VZ]
> Cc: Symington, Susan F.; Lloyd Wood; [email-masked]
> Subject: Re: [dtn-interest] Meeting frequency
>
> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>
> > In addition to the longer meeting, I think some kind of a "roadmap"
> > document that simply explains all the DTNRG documents and how they
> > fit together would help us target the important pieces to push
> > forward with.  There's definitely a dependency graph starting to
> > form between documents.  "Roadmap" is probably not the best word,
> > but it's what we used for the same kind of document on TCP (RFC
> > 4614); if there's a better name, let's use that :).  I think this
> > is an essential document as more people are coming into DTN work
> > and need to grasp the pieces of activity and how they relate.
>
> Obvious question:-) Was that you volunteering?
>
> While I agree with you that that'd be useful, esp. for new
> folks, right now I think I'd still emphasise the need to
> finish up some of the docs we've currently under way. But,
> if you've time to knock out an I-D, by all means do!
>
> S.
>

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

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

--Apple-Mail-3-606252688
Content-Type: text/html;
	charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><div>On 16 Sep 2008, at =
15:29, Symington, Susan F. wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; 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; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">This =
is a good list. Thanks for putting it together. I have a few =
changes:<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"text-indent: -0.25in; =
margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; =
color: rgb(31, 73, 125); "><span>1.<span style=3D"font: normal normal =
normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">I agree with Rajesh that it=92s probably better to =
move the metadata block to the generic category. Also, just a few hours =
before you sent this list out I happened to update two of the I-Ds. One =
of them was the metadata block. It now has a September 2008 date, and is =
called =93draft-irtf-dtnrg-bundle-metadata-block-00=94. (You can already =
see that keeping this document up-to-date is going to be a steady =
job.)</span></div></div></div></span></blockquote><div><br></div><div>I =
suggest simply skipping including -nn in the body of the doc and just =
insert urls of the form:</div><div><a =
href=3D"http://tools.ietf.org/html/draft-wood-dtnrg-saratoga">http://tools=
.ietf.org/html/draft-wood-dtnrg-saratoga</a></div><div><br></div><div>whic=
h provide a history. A full reference section can provide the detailed =
-nn info, names, dates etc - useful as a snapshot of a point in time =
when the doc was rendered to text and submitted (especially if there are =
later major changes to docs lineage, adoption by the group etc.), but =
not as immediately useful as the urls above for figuring out what doc is =
being talked about.</div><div><br></div><div>An 'expired/historical =
docs' section would also be useful to indicate what docs don't need to =
be looked at, and why - per Susan's point 2 below. e.g the eddy checksum =
drafts have been superseded by the irtf draft, =
etc.</div><div><br></div><div>L.</div><br><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; "><div lang=3D"EN-US" link=3D"blue" =
vlink=3D"purple"><div class=3D"Section1"><div style=3D"text-indent: =
-0.25in; margin-top: 0in; margin-right: 0in; margin-left: 0.5in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div><div =
style=3D"text-indent: -0.25in; margin-top: 0in; margin-right: 0in; =
margin-left: 0.5in; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-size: 11pt; =
font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><span>2.<span style=3D"font: normal normal normal 7pt/normal 'Times =
New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">I would delete the draft that you have listed in the =
Multicast Extensions category and replace it with the following draft: =
draft-symington-dtnrg-bundle-multicast-custodial-04 (May 2008). The I-D =
that you have listed (noncustodial multicast) was abandoned as =
unnecessary when we ensured that the Bundle Protocol spec itself =
&nbsp;supports non-custodial multicasting. You should probably call the =
Multicast Extensions category the =93Custodial Multicast Extensions=94 =
category, since the draft that I=92m asking you to put in there is =
specifically for custodial multicast. Right now, the Bundle Protocol =
Spec supports non-custodial multicast as is, without requiring any =
extensions.<o:p></o:p></span></div><div style=3D"text-indent: -0.25in; =
margin-top: 0in; margin-right: 0in; margin-left: 0.5in; margin-bottom: =
0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; =
"><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; =
color: rgb(31, 73, 125); "><span>3.<span style=3D"font: normal normal =
normal 7pt/normal 'Times New Roman'; =
">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span =
class=3D"Apple-converted-space">&nbsp;</span></span></span></span><span =
style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: =
rgb(31, 73, 125); ">There is one I-D missing: =
draft-irtf-dtnrg-bundle-previous-hop-block-04 (September 2008). This =
should probably go in the generic category, though some might argue for =
it to go in the routing category. Basically, it is the block that =
enables a bundle protocol agent to learn the endpoint ID of the bundle =
protocol agent that forwarded the bundle to it. An obvious use of this =
block is to support flood routing, to ensure that a bundle is not =
forwarded back out to the bundle protocol agent from which it was =
received. However, I imagine that there may be non-routing uses of this =
block.<o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">Thanks again. This document tree will be very helpful, not only for =
new people but for all of us to keep track.<o:p></o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); =
"><o:p>&nbsp;</o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); =
">-susan<o:p></o:p></span></div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-size: =
10pt; font-family: Arial, sans-serif; color: rgb(31, 73, 125); =
">*****************************************************************</span>=
<span style=3D"color: rgb(31, 73, 125); "><o:p></o:p></span></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-family: 'Courier New'; color: =
rgb(31, 73, 125); ">Susan Symington</span><span style=3D"color: rgb(31, =
73, 125); "><o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-family:=
 'Courier New'; color: rgb(31, 73, 125); ">The MITRE =
Corporation</span><span style=3D"color: rgb(31, 73, 125); =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-family: =
'Courier New'; color: rgb(31, 73, 125); "><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; text-decoration: =
underline; ">[email-masked]</a></span><span style=3D"color: rgb(31, 73, =
125); "><o:p></o:p></span></div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; "><span style=3D"font-family:=
 'Courier New'; color: rgb(31, 73, 125); ">703-983-7209 =
(voice)</span><span style=3D"color: rgb(31, 73, 125); =
"><o:p></o:p></span></div><div style=3D"margin-top: 0in; margin-right: =
0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; "><span style=3D"font-family: =
'Courier New'; color: rgb(31, 73, 125); ">703-983-7142 (fax)</span><span =
style=3D"color: rgb(31, 73, 125); "><o:p></o:p></span></div></div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 10pt; font-family: Arial, =
sans-serif; color: rgb(31, 73, 125); =
">******************************************************************</span=
><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; =
color: rgb(31, 73, 125); "><o:p></o:p></span></div><div =
style=3D"border-top-style: none; border-right-style: none; =
border-bottom-style: none; border-width: initial; border-color: initial; =
border-left-style: solid; border-left-color: blue; border-left-width: =
1.5pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; =
padding-left: 4pt; "><div><div style=3D"border-right-style: none; =
border-bottom-style: none; border-left-style: none; border-width: =
initial; border-color: initial; border-top-style: solid; =
border-top-color: rgb(181, 196, 223); border-top-width: 1pt; =
padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: =
0in; "><div style=3D"margin-top: 0in; margin-right: 0in; margin-left: =
0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><b><span style=3D"font-size: 10pt; font-family: Tahoma, =
sans-serif; ">From:</span></b><span style=3D"font-size: 10pt; =
font-family: Tahoma, sans-serif; "><span =
class=3D"Apple-converted-space">&nbsp;</span>Eddy, Wesley M. =
(GRC-RCN0)[VZ] [<a href=3D"mailto:[email-masked]" style=3D"color: =
blue; text-decoration: underline; =
">mailto:[email-masked]</a>]<span =
class=3D"Apple-converted-space">&nbsp;</span><br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Sunday, September 14, 2008 =
8:33 PM<br><b>To:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Stephen =
Farrell<br><b>Cc:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Symington, Susan F.; Lloyd =
Wood;<span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; =
">[email-masked]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>RE: [dtn-interest] Meeting =
frequency<o:p></o:p></span></div></div></div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div id=3D"idOWAReplyText67291"><div><div =
style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; =
margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New =
Roman', serif; "><span style=3D"font-size: 10pt; font-family: Arial, =
sans-serif; color: black; ">Here's a first cut at a draft; it may be =
missing a couple docs still, so clue me in if I've forgotten =
anything.</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
">&nbsp;<o:p></o:p></div></div></div><div><div style=3D"margin-top: 0in; =
margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: =
12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><div class=3D"MsoNormal" align=3D"center" =
style=3D"text-align: center; margin-top: 0in; margin-right: 0in; =
margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><hr size=3D"2" width=3D"100%" =
align=3D"center"></div><div style=3D"margin-top: 0in; margin-right: 0in; =
margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: =
'Times New Roman', serif; "><b><span style=3D"font-size: 10pt; =
font-family: Tahoma, sans-serif; ">From:</span></b><span =
style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "><span =
class=3D"Apple-converted-space">&nbsp;</span>Stephen Farrell [<a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; =
">mailto:[email-masked]</a>]<br><b>Sent:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Fri 9/12/2008 1:35 =
PM<br><b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span>Eddy, =
Wesley M. (GRC-RCN0)[VZ]<br><b>Cc:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Symington, Susan F.; Lloyd =
Wood;<span class=3D"Apple-converted-space">&nbsp;</span><a =
href=3D"mailto:[email-masked]" style=3D"color: blue; =
text-decoration: underline; =
">[email-masked]</a><br><b>Subject:</b><span =
class=3D"Apple-converted-space">&nbsp;</span>Re: [dtn-interest] Meeting =
frequency</span><o:p></o:p></div></div><div><div style=3D"margin-top: =
0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; =
font-size: 12pt; font-family: 'Times New Roman', serif; =
"><o:p>&nbsp;</o:p></div><p style=3D"margin-bottom: 12pt; margin-right: =
0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', =
serif; "><span style=3D"font-size: 10pt; ">Eddy, Wesley M. =
(GRC-RCN0)[VZ] wrote:<br><br>> In addition to the longer meeting, I =
think some kind of a "roadmap"<br>> document that simply explains all =
the DTNRG documents and how they<br>> fit together would help us target =
the important pieces to push<br>> forward with.&nbsp; There's definitely =
a dependency graph starting to<br>> form between documents.&nbsp; =
"Roadmap" is probably not the best word,<br>> but it's what we used for =
the same kind of document on TCP (RFC<br>> 4614); if there's a better =
name, let's use that :).&nbsp; I think this<br>> is an essential =
document as more people are coming into DTN work<br>> and need to grasp =
the pieces of activity and how they relate.<br><br>Obvious question:-) =
Was that you volunteering?<br><br>While I agree with you that that'd be =
useful, esp. for new<br>folks, right now I think I'd still emphasise the =
need to<br>finish up some of the docs we've currently under way. =
But,<br>if you've time to knock out an I-D, by all means =
do!<br><br>S.</span><o:p></o:p></p></div></div></div></div></span></blockq=
uote></div><br><div apple-content-edited=3D"true"> <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; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div>DTN work:&nbsp;<a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a></div><div><br></div><div>&l=
t;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></div><div><br=
></div></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"> </div><br></body></html>=

--Apple-Mail-3-606252688--

Content-class: urn:content-classes:message
Date: Tue, 16 Sep 2008 10:29:44 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Meeting frequency

This is a multi-part message in MIME format.

------_=_NextPart_001_01C91808.AA0A9BDE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This is a good list. Thanks for putting it together. I have a few
changes:

=20

1.       I agree with Rajesh that it's probably better to move the
metadata block to the generic category. Also, just a few hours before
you sent this list out I happened to update two of the I-Ds. One of
them was the metadata block. It now has a September 2008 date, and is
called "draft-irtf-dtnrg-bundle-metadata-block-00". (You can already
see that keeping this document up-to-date is going to be a steady job.)

2.       I would delete the draft that you have listed in the Multicast
Extensions category and replace it with the following draft:
draft-symington-dtnrg-bundle-multicast-custodial-04 (May 2008). The I-D
that you have listed (noncustodial multicast) was abandoned as
unnecessary when we ensured that the Bundle Protocol spec itself
supports non-custodial multicasting. You should probably call the
Multicast Extensions category the "Custodial Multicast Extensions"
category, since the draft that I'm asking you to put in there is
specifically for custodial multicast. Right now, the Bundle Protocol
Spec supports non-custodial multicast as is, without requiring any
extensions.

3.       There is one I-D missing:
draft-irtf-dtnrg-bundle-previous-hop-block-04 (September 2008). This
should probably go in the generic category, though some might argue for
it to go in the routing category. Basically, it is the block that
enables a bundle protocol agent to learn the endpoint ID of the bundle
protocol agent that forwarded the bundle to it. An obvious use of this
block is to support flood routing, to ensure that a bundle is not
forwarded back out to the bundle protocol agent from which it was
received. However, I imagine that there may be non-routing uses of this
block.=20

=20

Thanks again. This document tree will be very helpful, not only for new
people but for all of us to keep track.=20

=20

-susan

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

Susan Symington

The MITRE Corporation

[email-masked]

703-983-7209 (voice)

703-983-7142 (fax)

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

From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[email-masked]]=20
Sent: Sunday, September 14, 2008 8:33 PM
To: Stephen Farrell
Cc: Symington, Susan F.; Lloyd Wood; [email-masked]
Subject: RE: [dtn-interest] Meeting frequency

=20

Here's a first cut at a draft; it may be missing a couple docs still,
so clue me in if I've forgotten anything.

=20

=20

________________________________

From: Stephen Farrell [mailto:[email-masked]]
Sent: Fri 9/12/2008 1:35 PM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: Symington, Susan F.; Lloyd Wood; [email-masked]
Subject: Re: [dtn-interest] Meeting frequency

=20

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> In addition to the longer meeting, I think some kind of a "roadmap"
> document that simply explains all the DTNRG documents and how they
> fit together would help us target the important pieces to push
> forward with.  There's definitely a dependency graph starting to
> form between documents.  "Roadmap" is probably not the best word,
> but it's what we used for the same kind of document on TCP (RFC
> 4614); if there's a better name, let's use that :).  I think this
> is an essential document as more people are coming into DTN work
> and need to grasp the pieces of activity and how they relate.

Obvious question:-) Was that you volunteering?

While I agree with you that that'd be useful, esp. for new
folks, right now I think I'd still emphasise the need to
finish up some of the docs we've currently under way. But,
if you've time to knock out an I-D, by all means do!

S.

------_=_NextPart_001_01C91808.AA0A9BDE
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [dtn-interest] Meeting frequency</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1855994958;
	mso-list-type:hybrid;
	mso-list-template-ids:996155768 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This is a good list. Thanks for putting it together. I =
have a
few changes:<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>1.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree with Rajesh that it&#8217;s probably better to =
move the
metadata block to the generic category. Also, just a few hours before =
you sent
this list out I happened to update two of the I-Ds. One of them was the
metadata block. It now has a September 2008 date, and is called =
&#8220;draft-irtf-dtnrg-bundle-metadata-block-00&#8221;.
(You can already see that keeping this document up-to-date is going to =
be a
steady job.)<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>2.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I would delete the draft that you have listed in the =
Multicast
Extensions category and replace it with the following draft:
draft-symington-dtnrg-bundle-multicast-custodial-04 (May 2008). The I-D =
that
you have listed (noncustodial multicast) was abandoned as unnecessary =
when we ensured
that the Bundle Protocol spec itself &nbsp;supports non-custodial =
multicasting.
You should probably call the Multicast Extensions category the =
&#8220;Custodial
Multicast Extensions&#8221; category, since the draft that I&#8217;m =
asking you
to put in there is specifically for custodial multicast. Right now, the =
Bundle
Protocol Spec supports non-custodial multicast as is, without requiring =
any
extensions.<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>3.<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is one I-D missing:
draft-irtf-dtnrg-bundle-previous-hop-block-04 (September 2008). This =
should
probably go in the generic category, though some might argue for it to =
go in
the routing category. Basically, it is the block that enables a bundle =
protocol
agent to learn the endpoint ID of the bundle protocol agent that =
forwarded the
bundle to it. An obvious use of this block is to support flood routing, =
to
ensure that a bundle is not forwarded back out to the bundle protocol =
agent
from which it was received. However, I imagine that there may be =
non-routing
uses of this block. <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks again. This document tree will be very helpful, =
not only
for new people but for all of us to keep track. <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-susan<o:p></o:p></span></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#1F497D'>**********************************************************=
*******</span><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New";color:#1F497D'>Susan
Symington</span><span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New";color:#1F497D'>The
MITRE Corporation</span><span =
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New";color:#1F497D'>[email-masked]</span><span
style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New";color:#1F497D'>703-983-7209
(voice)</span><span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier =
New";color:#1F497D'>703-983-7142
(fax)</span><span style=3D'color:#1F497D'><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#1F497D'>**********************************************************=
********</span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p></o:p></span></p>

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

<div>

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

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Eddy, =
Wesley M.
(GRC-RCN0)[VZ] [mailto:[email-masked]] <br>
<b>Sent:</b> Sunday, September 14, 2008 8:33 PM<br>
<b>To:</b> Stephen Farrell<br>
<b>Cc:</b> Symington, Susan F.; Lloyd Wood; =
[email-masked]<br>
<b>Subject:</b> RE: [dtn-interest] Meeting =
frequency<o:p></o:p></span></p>

</div>

</div>

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

<div id=3DidOWAReplyText67291>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>Here's a first cut at a draft; it may be missing a couple =
docs
still, so clue me in if I've forgotten anything.</span><o:p></o:p></p>

</div>

<div>

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

</div>

</div>

<div>

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

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Stephen Farrell
[mailto:[email-masked]]<br>
<b>Sent:</b> Fri 9/12/2008 1:35 PM<br>
<b>To:</b> Eddy, Wesley M. (GRC-RCN0)[VZ]<br>
<b>Cc:</b> Symington, Susan F.; Lloyd Wood; =
[email-masked]<br>
<b>Subject:</b> Re: [dtn-interest] Meeting =
frequency</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

<p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>Eddy, =
Wesley M.
(GRC-RCN0)[VZ] wrote:<br>
<br>
&gt; In addition to the longer meeting, I think some kind of a
&quot;roadmap&quot;<br>
&gt; document that simply explains all the DTNRG documents and how =
they<br>
&gt; fit together would help us target the important pieces to push<br>
&gt; forward with.&nbsp; There's definitely a dependency graph starting =
to<br>
&gt; form between documents.&nbsp; &quot;Roadmap&quot; is probably not =
the best
word,<br>
&gt; but it's what we used for the same kind of document on TCP (RFC<br>
&gt; 4614); if there's a better name, let's use that :).&nbsp; I think =
this<br>
&gt; is an essential document as more people are coming into DTN =
work<br>
&gt; and need to grasp the pieces of activity and how they relate.<br>
<br>
Obvious question:-) Was that you volunteering?<br>
<br>
While I agree with you that that'd be useful, esp. for new<br>
folks, right now I think I'd still emphasise the need to<br>
finish up some of the docs we've currently under way. But,<br>
if you've time to knock out an I-D, by all means do!<br>
<br>
S.</span><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C91808.AA0A9BDE--

Date: Tue, 16 Sep 2008 10:13:46 +0100
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Underlying Networks

Hi Will,

Ivancic, William D. (GRC-RHN0) wrote:
> Would it be fair to say that the DTN architecture , as a network
> overlay, (and probably any network overlay - DTN or otherwise) inherits
> and can exploit all to good characteristics of the underlying network,
> but also inherits and can be exploited by the bad.  Some examples would
> be security, routing, discovery etc....

Interesting question with some interesting follow-ups.

I guess I'm not sure how I'd answer, so I'm wondering what
prompted the question?

S.

Content-class: urn:content-classes:message
Date: Mon, 15 Sep 2008 21:00:24 -0500
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Lloyd Wood" <[email-masked]>, "Kevin Fall" <[email-masked]>
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

This is a multi-part message in MIME format.

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

In mobility architectures, there is sometimes the concept of "delegation =
of signaling rights" which is basically the concept that some node that =
is more-capable or more-central within the network can take burden off =
of either the limited wireless links or the edge nodes themselves, by =
aggregating and proxying the various bits of signaling involved in =
mobility management.  This allows the architecture to function as it =
scales up in various terms, which would be impossible otherwise.
=20
DTN bundle protocol uses the notion of "delegation of retransmission =
rights" or "delegation of reliable transmission rights" to a similar =
end.  Though applications could ultimately be forced to be responsible, =
this doesn't scale, just like though mobiles can do their own signaling, =
it doesn't scale.  Also, removing the need for an ack channel and the =
need for storage while waiting for acks is a big win.  It allows the =
application on a challenged host with limited resources to send its data =
and move on with its mission.  Erasure coding has some tradeoffs and =
isn't always a win.
=20
=20

________________________________

From: [email-masked] on behalf of =
Lloyd Wood
Sent: Mon 9/15/2008 7:21 PM
To: Kevin Fall
Cc: DTN Interest List; Lloyd Wood; Ivancic, William D. (GRC-RHN0)
Subject: Re: [dtn-interest] Underlying Networks

Note the:

	(Sometimes an incomplete version of the function provided=20
	by the communication system may be useful as a performance =
enhancement.)

indicating that the function can, in fact, reside in the comms system in =
a way. As it commonly does with TCP/IP and the pseudoheader.

The e2e arguments strongly favouring the application hold in networks =
with closed control loops and tight coupling.

The application alone can give reliability, but the application alone =
can't give performance. Which is why wireless mobiles implement ARQ, =
etc.

When the control loops are open and coupling is loose, as is the case =
across multiple hops of many DTN networks where the endpoint =
applications may never interact directly in the same connected net, that =
above quoted sentence becomes very important.

Good to see the relevant literature being read.

Actually, following the e2e argument, the onus falls on the user, not =
the application. Or the user's boss who delegated the task to him...

L.

On 16 Sep 2008, at 01:02, Kevin Fall wrote:

	No, I wouldn't exactly agree [I'm sure you are shocked. :P...].  =
Quoting from the e2e argument paper:=20

	The function in question can completely and correctly be implemented =
only with the=20
	knowledge and help of the application standing at the end points of the =
communication=20
	system. Therefore, providing that questioned function as a feature of =
the communication=20
	system itself is not possible. (Sometimes an incomplete version of the =
function provided=20
	by the communication system may be useful as a performance =
enhancement.)

	This argument in fact argues that the function cannot reside
	in the communication system [which an overlay is one of].  Further =
reading just drives the point home
	further:
=09
=09
=09
	...The=20
	application program follows the simple steps above in transferring the =
file from A to B. Then, as=20
	a final additional step, the part of the file transfer application =
residing in host B reads the=20
	transferred file copy back from its disk storage system into its own =
memory, recalculates the=20
	checksum, and sends this value back to host A, where it is compared =
with the checksum of the=20
	original. Only if the two checksums agree does the file transfer =
application declare the transaction=20
	committed. If the comparison fails, something went wrong, and a retry =
from the beginning might=20
	be attempted.=20
	If failures really are fairly rare, this technique will normally work =
on the first try; occasionally a=20
	second or even third try might be required; one would probably consider =
two or more failures on=20
	the same file transfer attempt as indicating that some part of the =
system is in need of repair.=20
	Now let us consider the usefulness of a common proposal, namely that =
the communication=20
	system provide, internally, a guarantee of reliable data transmission. =
It might accomplish this=20
	guarantee by providing selective redundancy in the form of packet =
checksums, sequence number=20
	checking, and internal retry mechanisms, for example. With sufficient =
care, the probability of=20
	undetected bit errors can be reduced to any desirable level. The =
question is whether or not this=20
	attempt to be helpful on the part of the communication system is useful =
to the careful file transfer=20
	application.=20
	The answer is that threat number four may have been eliminated, but the =
careful file transfer=20
	application must still counter the remaining threats, so it should =
still provide its own retries based=20
	on an end-to-end checksum of the file.

	So, to really be following the 'end-to-end argument' you need to take =
action at the application.  Note that TCP/IP would thus not qualify, =
despite all the suggestions to the contrary...
=09
=09
	- K

	On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:

		On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
	=09
	=09

			well, this is somewhat true, but in being an overlay you can =20
		=09

			implement countermeasures that mitigate some of the problems.
		=09

		such as the end-to-end principle being a countermeasure against an =20
		unreliable underlying network infrastructure?
	=09
		L.
	=09
	=09

			For example, the RON overlay would do routing that was arguably =20
		=09

			'better' than that provided by BGP.
		=09

			DTN can, for example, can make more than one copy of a message, =20
		=09

			which may improve the probability of ultimately delivery.
		=09

			The Amherst folks also observe that even an unauthenticated DTN is =20
		=09

			relatively more secure than the alternative:
		=09

			=
http://portal.acm.org/citation.cfm?id=3D1288116&jmp=3Dcit&coll=3D&dl=3DAC=
M
		=09

			- K
		=09

			-----Original Message-----
		=09

			From: [email-masked] =
[mailto:[email-masked]=20
		=09

			] On Behalf Of Ivancic, William D. (GRC-RHN0)
		=09

			Sent: Monday, September 15, 2008 8:34 AM
		=09

			To: [email-masked]
		=09

			Subject: [dtn-interest] Underlying Networks
		=09

			Would it be fair to say that the DTN architecture , as a network
		=09

			overlay, (and probably any network overlay - DTN or otherwise) =20
		=09

			inherits
		=09

			and can exploit all to good characteristics of the underlying =
network,
		=09

			but also inherits and can be exploited by the bad.  Some examples =20
		=09

			would
		=09

			be security, routing, discovery etc....
		=09

			/will
		=09

			_______________________________________________
		=09

			dtn-interest mailing list
		=09

			[email-masked]
		=09

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

			_______________________________________________
		=09

			dtn-interest mailing list
		=09

			[email-masked]
		=09

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

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

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

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

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

<HTML dir=3Dltr><HEAD>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16711" name=3DGENERATOR></HEAD>=0A=
<BODY style=3D"WORD-WRAP: break-word">=0A=
<DIV id=3DidOWAReplyText63058 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>In mobility =
architectures, there is sometimes the concept of "delegation of =
signaling rights" which is basically the concept that some node that is =
more-capable or more-central within the network can take burden off of =
either the limited wireless links or the edge nodes themselves, by =
aggregating and proxying the various bits of signaling involved in =
mobility management.&nbsp; This allows the architecture to function as =
it scales up in various terms, which would be impossible =
otherwise.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>DTN bundle protocol uses the =
notion of "delegation of retransmission rights" or "delegation of =
reliable transmission rights" to a similar end.&nbsp; Though =
applications could ultimately be forced to be responsible, this =
doesn't&nbsp;scale, just like though mobiles can do their own signaling, =
it doesn't scale.&nbsp; Also, removing the need for an ack channel and =
the need for storage while waiting for acks is a big win.&nbsp; It =
allows the application on a challenged host with limited resources to =
send its data and move on with its mission.&nbsp; Erasure coding has =
some tradeoffs and isn't always a win.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked] on behalf of Lloyd =
Wood<BR><B>Sent:</B> Mon 9/15/2008 7:21 PM<BR><B>To:</B> Kevin =
Fall<BR><B>Cc:</B> DTN Interest List; Lloyd Wood; Ivancic, William D. =
(GRC-RHN0)<BR><B>Subject:</B> Re: [dtn-interest] Underlying =
Networks<BR></FONT><BR></DIV>=0A=
<DIV>Note the:<BR>=0A=
<DIV>=0A=
<BLOCKQUOTE type=3D"cite">=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">(Sometimes an incomplete =
version of the function provided<SPAN style=3D"FONT: 12px =
Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">by the communication system =
may be useful as a performance enhancement.)</DIV></BLOCKQUOTE></DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>indicating that the function can, in fact, reside in the comms =
system in a way. As it commonly does with TCP/IP and the =
pseudoheader.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>The e2e arguments strongly&nbsp;favouring the application hold in =
networks with closed control loops and tight coupling.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>The application alone can give reliability, but the application =
alone can't give performance. Which is why wireless mobiles implement =
ARQ, etc.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>When the control loops are open and coupling is loose, as is the =
case across multiple hops of many DTN networks where the endpoint =
applications may never interact directly in the same connected net, that =
above quoted sentence becomes very important.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Good to see the relevant literature being read.</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>Actually, following the e2e argument, the onus falls on the user, =
not the application. Or the user's boss who delegated the task to =
him...</DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>L.</DIV>=0A=
<DIV><BR>=0A=
<DIV>=0A=
<DIV>On 16 Sep 2008, at 01:02, Kevin Fall wrote:</DIV><BR =
class=3DApple-interchange-newline>=0A=
<BLOCKQUOTE type=3D"cite">=0A=
<DIV style=3D"WORD-WRAP: break-word">No, I wouldn't exactly agree [I'm =
sure you are shocked. :P...]. &nbsp;Quoting from the e2e argument paper: =0A=
<DIV><BR></DIV>=0A=
<DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">The function in question =
can completely and correctly be implemented only with the<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">knowledge and help of the =
application standing at the end points of the communication<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">system. Therefore, =
providing that questioned function as a feature of the =
communication<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">system itself is not =
possible. (Sometimes an incomplete version of the function provided<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">by the communication system =
may be useful as a performance enhancement.)</DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><BR></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: 18px">This argument in fact =
argues that the function cannot reside</SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: 18px">in the communication =
system [which an overlay is one of]. &nbsp;Further reading just drives =
the point home</SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: =
18px">further:</SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: =
18px"><BR></SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: 18px">=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">...The<SPAN style=3D"FONT: =
12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">application program follows =
the simple steps above in transferring the file from A to B. Then, =
as<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">a final additional step, =
the part of the file transfer application residing in host B reads =
the<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">transferred file copy back =
from its disk storage system into its own memory, recalculates the<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">checksum, and sends this =
value back to host A, where it is compared with the checksum of the<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">original. Only if the two =
checksums agree does the file transfer application declare the =
transaction<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">committed. If the =
comparison fails, something went wrong, and a retry from the beginning =
might<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">be attempted.<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">If failures really are =
fairly rare, this technique will normally work on the first try; =
occasionally a<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">second or even third try =
might be required; one would probably consider two or more failures =
on<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">the same file transfer =
attempt as indicating that some part of the system is in need of =
repair.<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">Now let us consider the =
usefulness of a common proposal, namely that the communication<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">system provide, internally, =
a guarantee of reliable data transmission. It might accomplish this<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">guarantee by providing =
selective redundancy in the form of packet checksums, sequence =
number<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">checking, and internal =
retry mechanisms, for example. With sufficient care, the probability =
of<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">undetected bit errors can =
be reduced to any desirable level. The question is whether or not =
this<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">attempt to be helpful on =
the part of the communication system is useful to the careful file =
transfer<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">application.<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">The answer is that threat =
number four may have been eliminated, but the careful file transfer<SPAN =
style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">application must still =
counter the remaining threats, so it should still provide its own =
retries based<SPAN style=3D"FONT: 12px Helvetica">&nbsp;</SPAN></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times">on an end-to-end checksum =
of the file.</DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><BR></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: 18px">So, to really be =
following the 'end-to-end argument' you need to take action at the =
application. &nbsp;Note that TCP/IP would thus not qualify, despite all =
the suggestions to the contrary...</SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: =
18px"><BR></SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><FONT =
class=3DApple-style-span face=3DHelvetica size=3D5><SPAN =
class=3DApple-style-span style=3D"FONT-SIZE: 18px">- =
K</SPAN></FONT></DIV></SPAN></FONT></DIV>=0A=
<DIV style=3D"MARGIN: 0px; FONT: 12px Times"><BR></DIV>=0A=
<DIV>=0A=
<DIV>On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:</DIV><BR =
class=3DApple-interchange-newline>=0A=
<BLOCKQUOTE type=3D"cite">=0A=
<DIV><BR>On 15 Sep 2008, at 23:25, Fall, Kevin wrote:<BR><BR>=0A=
<BLOCKQUOTE type=3D"cite">well, this is somewhat true, but in being an =
overlay you can &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">implement countermeasures that mitigate some =
of the problems.<BR></BLOCKQUOTE><BR>such as the end-to-end principle =
being a countermeasure against an &nbsp;<BR>unreliable underlying =
network infrastructure?<BR><BR>L.<BR><BR>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">For example, the RON overlay would do routing =
that was arguably &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">'better' than that provided by =
BGP.<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">DTN can, for example, can make more than one =
copy of a message, &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">which may improve the probability of =
ultimately delivery.<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">The Amherst folks also observe that even an =
unauthenticated DTN is &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">relatively more secure than the =
alternative:<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><A =
href=3D"http://portal.acm.org/citation.cfm?id=3D1288116&amp;jmp=3Dcit&amp=
;coll=3D&amp;dl=3DACM">http://portal.acm.org/citation.cfm?id=3D1288116&am=
p;jmp=3Dcit&amp;coll=3D&amp;dl=3DACM</A><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">- K<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">-----Original Message-----<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">From: <A =
href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</A> [<A =
href=3D"mailto:[email-masked]">mailto:=
[email-masked]</A> <BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">] On Behalf Of Ivancic, William D. =
(GRC-RHN0)<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">Sent: Monday, September 15, 2008 8:34 =
AM<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">To: <A =
href=3D"mailto:[email-masked]">[email-masked]=
.org</A><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">Subject: [dtn-interest] Underlying =
Networks<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">Would it be fair to say that the DTN =
architecture , as a network<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">overlay, (and probably any network overlay - =
DTN or otherwise) &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">inherits<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">and can exploit all to good characteristics of =
the underlying network,<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">but also inherits and can be exploited by the =
bad. &nbsp;Some examples &nbsp;<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">would<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">be security, routing, discovery =
etc....<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite">/will<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE =
type=3D"cite">_______________________________________________<BR></BLOCKQ=
UOTE>=0A=
<BLOCKQUOTE type=3D"cite">dtn-interest mailing list<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><A =
href=3D"mailto:[email-masked]">dtn-interest@ma=
illists.intel-research.net</A><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><A =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE =
type=3D"cite">_______________________________________________<BR></BLOCKQ=
UOTE>=0A=
<BLOCKQUOTE type=3D"cite">dtn-interest mailing list<BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><A =
href=3D"mailto:[email-masked]">dtn-interest@ma=
illists.intel-research.net</A><BR></BLOCKQUOTE>=0A=
<BLOCKQUOTE type=3D"cite"><A =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R></BLOCKQUOTE><BR>DTN work: <A =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://inf=
o.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR><BR>&lt;<A =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.=
uk/Personal/L.Wood/</A>&gt;&lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;<BR><BR><B=
R><BR><BR><BR>_______________________________________________<BR>dtn-inte=
rest mailing list<BR><A =
href=3D"mailto:[email-masked]">dtn-interest@ma=
illists.intel-research.net</A><BR><A =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R><BR></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></BLOCKQUOTE></DIV><BR>=0A=
<DIV><SPAN class=3DApple-style-span style=3D"WORD-SPACING: 0px; FONT: =
12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: =
0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: =
separate; orphans: 2; widows: 2">=0A=
<DIV style=3D"WORD-WRAP: break-word"><SPAN class=3DApple-style-span =
style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; =
COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2">=0A=
<DIV style=3D"WORD-WRAP: break-word"><SPAN class=3DApple-style-span =
style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; =
COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; =
LETTER-SPACING: normal; BORDER-COLLAPSE: separate; orphans: 2; widows: =
2">=0A=
<DIV style=3D"WORD-WRAP: break-word">=0A=
<DIV>DTN work:&nbsp;<A =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://inf=
o.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A></DIV>=0A=
<DIV><BR></DIV>=0A=
<DIV>&lt;<A =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.=
uk/Personal/L.Wood/</A>&gt;&lt;<A =
href=3D"mailto:[email-masked]">[email-masked]</A>&gt;</DIV>=0A=
<DIV><BR></DIV></DIV></SPAN><BR =
class=3DApple-interchange-newline></DIV></SPAN><BR =
class=3DApple-interchange-newline></DIV></SPAN><BR =
class=3DApple-interchange-newline></DIV><BR></DIV></DIV></BODY></HTML>
------_=_NextPart_001_01C9179F.FB9058B4--

From: Lloyd Wood <[email-masked]>
To: Kevin Fall <[email-masked]>
Date: Tue, 16 Sep 2008 01:21:29 +0100
Cc: DTN Interest List <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

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

Note the:
> (Sometimes an incomplete version of the function provided
> by the communication system may be useful as a performance  
> enhancement.)

indicating that the function can, in fact, reside in the comms system  
in a way. As it commonly does with TCP/IP and the pseudoheader.

The e2e arguments strongly favouring the application hold in networks  
with closed control loops and tight coupling.

The application alone can give reliability, but the application alone  
can't give performance. Which is why wireless mobiles implement ARQ,  
etc.

When the control loops are open and coupling is loose, as is the case  
across multiple hops of many DTN networks where the endpoint  
applications may never interact directly in the same connected net,  
that above quoted sentence becomes very important.

Good to see the relevant literature being read.

Actually, following the e2e argument, the onus falls on the user, not  
the application. Or the user's boss who delegated the task to him...

L.

On 16 Sep 2008, at 01:02, Kevin Fall wrote:

> No, I wouldn't exactly agree [I'm sure you are shocked. :P...].   
> Quoting from the e2e argument paper:
>
> The function in question can completely and correctly be implemented  
> only with the
> knowledge and help of the application standing at the end points of  
> the communication
> system. Therefore, providing that questioned function as a feature  
> of the communication
> system itself is not possible. (Sometimes an incomplete version of  
> the function provided
> by the communication system may be useful as a performance  
> enhancement.)
>
> This argument in fact argues that the function cannot reside
> in the communication system [which an overlay is one of].  Further  
> reading just drives the point home
> further:
>
> ...The
> application program follows the simple steps above in transferring  
> the file from A to B. Then, as
> a final additional step, the part of the file transfer application  
> residing in host B reads the
> transferred file copy back from its disk storage system into its own  
> memory, recalculates the
> checksum, and sends this value back to host A, where it is compared  
> with the checksum of the
> original. Only if the two checksums agree does the file transfer  
> application declare the transaction
> committed. If the comparison fails, something went wrong, and a  
> retry from the beginning might
> be attempted.
> If failures really are fairly rare, this technique will normally  
> work on the first try; occasionally a
> second or even third try might be required; one would probably  
> consider two or more failures on
> the same file transfer attempt as indicating that some part of the  
> system is in need of repair.
> Now let us consider the usefulness of a common proposal, namely that  
> the communication
> system provide, internally, a guarantee of reliable data  
> transmission. It might accomplish this
> guarantee by providing selective redundancy in the form of packet  
> checksums, sequence number
> checking, and internal retry mechanisms, for example. With  
> sufficient care, the probability of
> undetected bit errors can be reduced to any desirable level. The  
> question is whether or not this
> attempt to be helpful on the part of the communication system is  
> useful to the careful file transfer
> application.
> The answer is that threat number four may have been eliminated, but  
> the careful file transfer
> application must still counter the remaining threats, so it should  
> still provide its own retries based
> on an end-to-end checksum of the file.
>
> So, to really be following the 'end-to-end argument' you need to  
> take action at the application.  Note that TCP/IP would thus not  
> qualify, despite all the suggestions to the contrary...
>
> - K
>
> On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:
>
>>
>> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>>
>>> well, this is somewhat true, but in being an overlay you can
>>> implement countermeasures that mitigate some of the problems.
>>
>> such as the end-to-end principle being a countermeasure against an
>> unreliable underlying network infrastructure?
>>
>> L.
>>
>>>
>>>
>>> For example, the RON overlay would do routing that was arguably
>>> 'better' than that provided by BGP.
>>> DTN can, for example, can make more than one copy of a message,
>>> which may improve the probability of ultimately delivery.
>>>
>>> The Amherst folks also observe that even an unauthenticated DTN is
>>> relatively more secure than the alternative:
>>> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>>>
>>> - K
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]
>>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>>> Sent: Monday, September 15, 2008 8:34 AM
>>> To: [email-masked]
>>> Subject: [dtn-interest] Underlying Networks
>>>
>>> Would it be fair to say that the DTN architecture , as a network
>>> overlay, (and probably any network overlay - DTN or otherwise)
>>> inherits
>>> and can exploit all to good characteristics of the underlying  
>>> network,
>>> but also inherits and can be exploited by the bad.  Some examples
>>> would
>>> be security, routing, discovery etc....
>>>
>>>
>>> /will
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>>
>> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>

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

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

--Apple-Mail-1-551637862
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; ">Note the:<br><div><blockquote =
type=3D"cite"><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">(Sometimes an incomplete version of the function =
provided<span style=3D"font: normal normal normal 12px/normal Helvetica; =
">&nbsp;</span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">by the communication system may be useful as a =
performance =
enhancement.)</div></blockquote></div><div><br></div><div>indicating =
that the function can, in fact, reside in the comms system in a way. As =
it commonly does with TCP/IP and the =
pseudoheader.</div><div><br></div><div>The e2e arguments =
strongly&nbsp;favouring the application hold in networks with closed =
control loops and tight coupling.</div><div><br></div><div>The =
application alone can give reliability, but the application alone can't =
give performance. Which is why wireless mobiles implement ARQ, =
etc.</div><div><br></div><div>When the control loops are open and =
coupling is loose, as is the case across multiple hops of many DTN =
networks where the endpoint applications may never interact directly in =
the same connected net, that above quoted sentence becomes very =
important.</div><div><br></div><div>Good to see the relevant literature =
being read.</div><div><br></div><div>Actually, following the e2e =
argument, the onus falls on the user, not the application. Or the user's =
boss who delegated the task to =
him...</div><div><br></div><div>L.</div><div><br><div><div>On 16 Sep =
2008, at 01:02, Kevin Fall wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">No, I wouldn't exactly agree =
[I'm sure you are shocked. :P...]. &nbsp;Quoting from the e2e argument =
paper:<div><br></div><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">The function in question can completely and =
correctly be implemented only with the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">knowledge and help of the application =
standing at the end points of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system. Therefore, providing that =
questioned function as a feature of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system itself is not possible. =
(Sometimes an incomplete version of the function provided<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">by the =
communication system may be useful as a performance =
enhancement.)</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">This argument in fact argues that the =
function cannot reside</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">in the communication system [which an overlay =
is one of]. &nbsp;Further reading just drives the point =
home</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"5"><span class=3D"Apple-style-span" style=3D"font-size: =
18px;">further:</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">...The<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application program follows the simple steps above in transferring the =
file from A to B. Then, as<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">a final additional step, the part of =
the file transfer application residing in host B reads the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">transferred file copy back from its disk storage system into its own =
memory, recalculates the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checksum, and sends this value back =
to host A, where it is compared with the checksum of the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">original. Only if the two checksums agree does the file transfer =
application declare the transaction<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">committed. If the comparison fails, =
something went wrong, and a retry from the beginning might<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">be =
attempted.<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">If =
failures really are fairly rare, this technique will normally work on =
the first try; occasionally a<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">second or even third try might be =
required; one would probably consider two or more failures on<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">the =
same file transfer attempt as indicating that some part of the system is =
in need of repair.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">Now let us consider the usefulness of =
a common proposal, namely that the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system provide, internally, a =
guarantee of reliable data transmission. It might accomplish this<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">guarantee by providing selective redundancy in the form of packet =
checksums, sequence number<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checking, and internal retry =
mechanisms, for example. With sufficient care, the probability of<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">undetected bit errors can be reduced to any desirable level. The =
question is whether or not this<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">attempt to be helpful on the part of =
the communication system is useful to the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">The answer is that threat number four =
may have been eliminated, but the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application must still counter the remaining threats, so it should =
still provide its own retries based<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">on an end-to-end checksum of the =
file.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">So, to really be following the 'end-to-end =
argument' you need to take action at the application. &nbsp;Note that =
TCP/IP would thus not qualify, despite all the suggestions to the =
contrary...</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;">- =
K</span></font></div></span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><br></div><div><div>On Sep 15, 2008, =
at Sep 154:38 PMPDT, Lloyd Wood wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>On =
15 Sep 2008, at 23:25, Fall, Kevin wrote:<br><br><blockquote =
type=3D"cite">well, this is somewhat true, but in being an overlay you =
can &nbsp;<br></blockquote><blockquote type=3D"cite">implement =
countermeasures that mitigate some of the =
problems.<br></blockquote><br>such as the end-to-end principle being a =
countermeasure against an &nbsp;<br>unreliable underlying network =
infrastructure?<br><br>L.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">For example, =
the RON overlay would do routing that was arguably =
&nbsp;<br></blockquote><blockquote type=3D"cite">'better' than that =
provided by BGP.<br></blockquote><blockquote type=3D"cite">DTN can, for =
example, can make more than one copy of a message, =
&nbsp;<br></blockquote><blockquote type=3D"cite">which may improve the =
probability of ultimately delivery.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The Amherst =
folks also observe that even an unauthenticated DTN is =
&nbsp;<br></blockquote><blockquote type=3D"cite">relatively more secure =
than the alternative:<br></blockquote><blockquote type=3D"cite"><a =
href=3D"http://portal.acm.org/citation.cfm?id=3D1288116&amp;jmp=3Dcit&amp;=
coll=3D&amp;dl=3DACM">http://portal.acm.org/citation.cfm?id=3D1288116&amp;=
jmp=3Dcit&amp;coll=3D&amp;dl=3DACM</a><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">- =
K<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-----Original Message-----<br></blockquote><blockquote =
type=3D"cite">From: <a =
href=3D"mailto:[email-masked]">dtn-inte=
[email-masked]</a> [<a =
href=3D"mailto:[email-masked]">mailto:d=
[email-masked]</a> =
<br></blockquote><blockquote type=3D"cite">] On Behalf Of Ivancic, =
William D. (GRC-RHN0)<br></blockquote><blockquote type=3D"cite">Sent: =
Monday, September 15, 2008 8:34 AM<br></blockquote><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br></blockquote><blockquote type=3D"cite">Subject: =
[dtn-interest] Underlying Networks<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Would it be =
fair to say that the DTN architecture , as a =
network<br></blockquote><blockquote type=3D"cite">overlay, (and probably =
any network overlay - DTN or otherwise) =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">inherits<br></blockquote><blockquote type=3D"cite">and can =
exploit all to good characteristics of the underlying =
network,<br></blockquote><blockquote type=3D"cite">but also inherits and =
can be exploited by the bad. &nbsp;Some examples =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">would<br></blockquote><blockquote type=3D"cite">be =
security, routing, discovery etc....<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">/will<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br>DTN work: <a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a><br><br>&lt;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br><br><br><b=
r><br><br>_______________________________________________<br>dtn-interest =
mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br><a =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
<br></div></blockquote></div><br></div></div></blockquote></div><br><div =
apple-content-edited=3D"true"> <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; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><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-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div>DTN work:&nbsp;<a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a></div><div><br></div><div>&l=
t;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>></div><div><br=
></div></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"></div></span><br =
class=3D"Apple-interchange-newline"> </div><br></div></body></html>=

--Apple-Mail-1-551637862--

Date: Mon, 15 Sep 2008 17:18:01 -0700
From: Scott Burleigh <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

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

Lloyd Wood wrote:
> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>   
>> well, this is somewhat true, but in being an overlay you can  
>> implement countermeasures that mitigate some of the problems.
>>     
> such as the end-to-end principle being a countermeasure against an  
> unreliable underlying network infrastructure?
>   
Probably not, since a principle isn't a countermeasure (although it may 
in some cases provide some guidance in the development of a 
countermeasure).  Kevin's examples are better.
>> For example, the RON overlay would do routing that was arguably  
>> 'better' than that provided by BGP.
>> DTN can, for example, can make more than one copy of a message,  
>> which may improve the probability of ultimately delivery.
>>
>> The Amherst folks also observe that even an unauthenticated DTN is  
>> relatively more secure than the alternative:
>> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>>
>> - K
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked] 
>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>> Sent: Monday, September 15, 2008 8:34 AM
>> To: [email-masked]
>> Subject: [dtn-interest] Underlying Networks
>>
>> Would it be fair to say that the DTN architecture , as a network
>> overlay, (and probably any network overlay - DTN or otherwise)  
>> inherits
>> and can exploit all to good characteristics of the underlying network,
>> but also inherits and can be exploited by the bad.  Some examples  
>> would
>> be security, routing, discovery etc....
>>
>>
>> /will
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>     
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>   

--------------050502010808030005050508
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">
Lloyd Wood wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">well, this is somewhat true, but in being an overlay you can  
implement countermeasures that mitigate some of the problems.
    </pre>
  </blockquote>
  <pre wrap=""><!---->such as the end-to-end principle being a countermeasure against an  
unreliable underlying network infrastructure?
  </pre>
</blockquote>
Probably not, since a principle isn't a countermeasure (although it may
in some cases provide some guidance in the development of a
countermeasure).&nbsp; Kevin's examples are better.<br>
<blockquote cite="mid:[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">For example, the RON overlay would do routing that was arguably  
'better' than that provided by BGP.
DTN can, for example, can make more than one copy of a message,  
which may improve the probability of ultimately delivery.

The Amherst folks also observe that even an unauthenticated DTN is  
relatively more secure than the alternative:
<a class="moz-txt-link-freetext" href="http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM">http://portal.acm.org/citation.cfm?id=1288116&amp;jmp=cit&amp;coll=&amp;dl=ACM</a>

- K

-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a> 
] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, September 15, 2008 8:34 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: [dtn-interest] Underlying Networks

Would it be fair to say that the DTN architecture , as a network
overlay, (and probably any network overlay - DTN or otherwise)  
inherits
and can exploit all to good characteristics of the underlying network,
but also inherits and can be exploited by the bad.  Some examples  
would
be security, routing, discovery etc....

/will

_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>

_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
DTN work: <a class="moz-txt-link-freetext" href="http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a>

<a class="moz-txt-link-rfc2396E" href="http://info.surrey.ac.uk/Personal/L.Wood/">&lt;http://info.surrey.ac.uk/Personal/L.Wood/&gt;</a><a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>

_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>

  </pre>
</blockquote>
<br>
</body>
</html>

--------------050502010808030005050508--

From: Kevin Fall <[email-masked]>
To: Lloyd Wood <[email-masked]>
Date: Mon, 15 Sep 2008 17:02:47 -0700
Cc: DTN Interest List <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

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

No, I wouldn't exactly agree [I'm sure you are shocked. :P...].   
Quoting from the e2e argument paper:

The function in question can completely and correctly be implemented  
only with the
knowledge and help of the application standing at the end points of  
the communication
system. Therefore, providing that questioned function as a feature of  
the communication
system itself is not possible. (Sometimes an incomplete version of the  
function provided
by the communication system may be useful as a performance enhancement.)

This argument in fact argues that the function cannot reside
in the communication system [which an overlay is one of].  Further  
reading just drives the point home
further:

...The
application program follows the simple steps above in transferring the  
file from A to B. Then, as
a final additional step, the part of the file transfer application  
residing in host B reads the
transferred file copy back from its disk storage system into its own  
memory, recalculates the
checksum, and sends this value back to host A, where it is compared  
with the checksum of the
original. Only if the two checksums agree does the file transfer  
application declare the transaction
committed. If the comparison fails, something went wrong, and a retry  
from the beginning might
be attempted.
If failures really are fairly rare, this technique will normally work  
on the first try; occasionally a
second or even third try might be required; one would probably  
consider two or more failures on
the same file transfer attempt as indicating that some part of the  
system is in need of repair.
Now let us consider the usefulness of a common proposal, namely that  
the communication
system provide, internally, a guarantee of reliable data transmission.  
It might accomplish this
guarantee by providing selective redundancy in the form of packet  
checksums, sequence number
checking, and internal retry mechanisms, for example. With sufficient  
care, the probability of
undetected bit errors can be reduced to any desirable level. The  
question is whether or not this
attempt to be helpful on the part of the communication system is  
useful to the careful file transfer
application.
The answer is that threat number four may have been eliminated, but  
the careful file transfer
application must still counter the remaining threats, so it should  
still provide its own retries based
on an end-to-end checksum of the file.

So, to really be following the 'end-to-end argument' you need to take  
action at the application.  Note that TCP/IP would thus not qualify,  
despite all the suggestions to the contrary...

- K

On Sep 15, 2008, at Sep 154:38 PMPDT, Lloyd Wood wrote:

>
> On 15 Sep 2008, at 23:25, Fall, Kevin wrote:
>
>> well, this is somewhat true, but in being an overlay you can
>> implement countermeasures that mitigate some of the problems.
>
> such as the end-to-end principle being a countermeasure against an
> unreliable underlying network infrastructure?
>
> L.
>
>>
>>
>> For example, the RON overlay would do routing that was arguably
>> 'better' than that provided by BGP.
>> DTN can, for example, can make more than one copy of a message,
>> which may improve the probability of ultimately delivery.
>>
>> The Amherst folks also observe that even an unauthenticated DTN is
>> relatively more secure than the alternative:
>> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>>
>> - K
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]
>> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
>> Sent: Monday, September 15, 2008 8:34 AM
>> To: [email-masked]
>> Subject: [dtn-interest] Underlying Networks
>>
>> Would it be fair to say that the DTN architecture , as a network
>> overlay, (and probably any network overlay - DTN or otherwise)
>> inherits
>> and can exploit all to good characteristics of the underlying  
>> network,
>> but also inherits and can be exploited by the bad.  Some examples
>> would
>> be security, routing, discovery etc....
>>
>>
>> /will
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
> <http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--Apple-Mail-39-550515837
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; ">No, I wouldn't exactly agree =
[I'm sure you are shocked. :P...]. &nbsp;Quoting from the e2e argument =
paper:<div><br></div><div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; ">The function in question can completely and =
correctly be implemented only with the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">knowledge and help of the application =
standing at the end points of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system. Therefore, providing that =
questioned function as a feature of the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system itself is not possible. =
(Sometimes an incomplete version of the function provided<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">by the =
communication system may be useful as a performance =
enhancement.)</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">This argument in fact argues that the =
function cannot reside</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">in the communication system [which an overlay =
is one of]. &nbsp;Further reading just drives the point =
home</span></font></div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><font class=3D"Apple-style-span" face=3D"Helvetica" =
size=3D"5"><span class=3D"Apple-style-span" style=3D"font-size: =
18px;">further:</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">...The<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application program follows the simple steps above in transferring the =
file from A to B. Then, as<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">a final additional step, the part of =
the file transfer application residing in host B reads the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">transferred file copy back from its disk storage system into its own =
memory, recalculates the<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checksum, and sends this value back =
to host A, where it is compared with the checksum of the<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">original. Only if the two checksums agree does the file transfer =
application declare the transaction<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">committed. If the comparison fails, =
something went wrong, and a retry from the beginning might<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">be =
attempted.<span style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">If =
failures really are fairly rare, this technique will normally work on =
the first try; occasionally a<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">second or even third try might be =
required; one would probably consider two or more failures on<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; ">the =
same file transfer attempt as indicating that some part of the system is =
in need of repair.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">Now let us consider the usefulness of =
a common proposal, namely that the communication<span style=3D"font: =
12.0px Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">system provide, internally, a =
guarantee of reliable data transmission. It might accomplish this<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">guarantee by providing selective redundancy in the form of packet =
checksums, sequence number<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">checking, and internal retry =
mechanisms, for example. With sufficient care, the probability of<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">undetected bit errors can be reduced to any desirable level. The =
question is whether or not this<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">attempt to be helpful on the part of =
the communication system is useful to the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application.<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">The answer is that threat number four =
may have been eliminated, but the careful file transfer<span =
style=3D"font: 12.0px Helvetica">&nbsp;</span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; =
">application must still counter the remaining threats, so it should =
still provide its own retries based<span style=3D"font: 12.0px =
Helvetica">&nbsp;</span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; ">on an end-to-end checksum of the =
file.</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal Times; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;">So, to really be following the 'end-to-end =
argument' you need to take action at the application. &nbsp;Note that =
TCP/IP would thus not qualify, despite all the suggestions to the =
contrary...</span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><font class=3D"Apple-style-span" =
face=3D"Helvetica" size=3D"5"><span class=3D"Apple-style-span" =
style=3D"font-size: 18px;"><br></span></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal Times; "><font =
class=3D"Apple-style-span" face=3D"Helvetica" size=3D"5"><span =
class=3D"Apple-style-span" style=3D"font-size: 18px;">- =
K</span></font></div></span></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal Times; "><br></div><div><div>On Sep 15, 2008, =
at Sep 154:38 PMPDT, Lloyd Wood wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br>On =
15 Sep 2008, at 23:25, Fall, Kevin wrote:<br><br><blockquote =
type=3D"cite">well, this is somewhat true, but in being an overlay you =
can &nbsp;<br></blockquote><blockquote type=3D"cite">implement =
countermeasures that mitigate some of the =
problems.<br></blockquote><br>such as the end-to-end principle being a =
countermeasure against an &nbsp;<br>unreliable underlying network =
infrastructure?<br><br>L.<br><br><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">For example, =
the RON overlay would do routing that was arguably =
&nbsp;<br></blockquote><blockquote type=3D"cite">'better' than that =
provided by BGP.<br></blockquote><blockquote type=3D"cite">DTN can, for =
example, can make more than one copy of a message, =
&nbsp;<br></blockquote><blockquote type=3D"cite">which may improve the =
probability of ultimately delivery.<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">The Amherst =
folks also observe that even an unauthenticated DTN is =
&nbsp;<br></blockquote><blockquote type=3D"cite">relatively more secure =
than the alternative:<br></blockquote><blockquote type=3D"cite"><a =
href=3D"http://portal.acm.org/citation.cfm?id=3D1288116&amp;jmp=3Dcit&amp;=
coll=3D&amp;dl=3DACM">http://portal.acm.org/citation.cfm?id=3D1288116&amp;=
jmp=3Dcit&amp;coll=3D&amp;dl=3DACM</a><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">- =
K<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">-----Original Message-----<br></blockquote><blockquote =
type=3D"cite">From: [email-masked] =
[<a =
href=3D"mailto:[email-masked]">mailto:d=
[email-masked]</a> =
<br></blockquote><blockquote type=3D"cite">] On Behalf Of Ivancic, =
William D. (GRC-RHN0)<br></blockquote><blockquote type=3D"cite">Sent: =
Monday, September 15, 2008 8:34 AM<br></blockquote><blockquote =
type=3D"cite">To: <a =
href=3D"mailto:[email-masked]">[email-masked].=
org</a><br></blockquote><blockquote type=3D"cite">Subject: =
[dtn-interest] Underlying Networks<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">Would it be =
fair to say that the DTN architecture , as a =
network<br></blockquote><blockquote type=3D"cite">overlay, (and probably =
any network overlay - DTN or otherwise) =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">inherits<br></blockquote><blockquote type=3D"cite">and can =
exploit all to good characteristics of the underlying =
network,<br></blockquote><blockquote type=3D"cite">but also inherits and =
can be exploited by the bad. &nbsp;Some examples =
&nbsp;<br></blockquote><blockquote =
type=3D"cite">would<br></blockquote><blockquote type=3D"cite">be =
security, routing, discovery etc....<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">/will<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><blockquote type=3D"cite"><br></blockquote><blockquote =
type=3D"cite">_______________________________________________<br></blockqu=
ote><blockquote type=3D"cite">dtn-interest mailing =
list<br></blockquote><blockquote type=3D"cite"><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br></blockquote><blockquote type=3D"cite"><a=
 =
href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest"=
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>=
</blockquote><br>DTN work: <a =
href=3D"http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/">http://info=
.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</a><br><br>&lt;<a =
href=3D"http://info.surrey.ac.uk/Personal/L.Wood/">http://info.surrey.ac.u=
k/Personal/L.Wood/</a>>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>><br><br><br><b=
r><br><br>_______________________________________________<br>dtn-interest =
mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br><br></div></blockquote></div><br></div></body>=
</html>=

--Apple-Mail-39-550515837--

From: Lloyd Wood <[email-masked]>
To: "Fall, Kevin" <[email-masked]>
Date: Tue, 16 Sep 2008 00:38:43 +0100
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>, "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>
Subject: Re: [dtn-interest] Underlying Networks

On 15 Sep 2008, at 23:25, Fall, Kevin wrote:

> well, this is somewhat true, but in being an overlay you can  
> implement countermeasures that mitigate some of the problems.

such as the end-to-end principle being a countermeasure against an  
unreliable underlying network infrastructure?

L.

>
>
> For example, the RON overlay would do routing that was arguably  
> 'better' than that provided by BGP.
> DTN can, for example, can make more than one copy of a message,  
> which may improve the probability of ultimately delivery.
>
> The Amherst folks also observe that even an unauthenticated DTN is  
> relatively more secure than the alternative:
> http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM
>
> - K
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked] 
> ] On Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Monday, September 15, 2008 8:34 AM
> To: [email-masked]
> Subject: [dtn-interest] Underlying Networks
>
> Would it be fair to say that the DTN architecture , as a network
> overlay, (and probably any network overlay - DTN or otherwise)  
> inherits
> and can exploit all to good characteristics of the underlying network,
> but also inherits and can be exploited by the bad.  Some examples  
> would
> be security, routing, discovery etc....
>
>
> /will
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

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

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

Date: Tue, 16 Sep 2008 00:13:00 +0100
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Meeting frequency

Yes, good stuff.
Thanks Wes,
S.

Rajesh Krishnan wrote:
> Wes,
> 
> This is a very nice list.  I recommend listing metadata blocks under
> generic extensions rather than under routing.
> 
> Best Regards,
> Rajesh
> 
> On Sun, Sep 14, 2008 at 8:32 PM, Eddy, Wesley M. (GRC-RCN0)[VZ]
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Here's a first cut at a draft; it may be missing a couple docs
>     still, so clue me in if I've forgotten anything.
>      
> 
>     ------------------------------------------------------------------------
>     *From:* Stephen Farrell [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Sent:* Fri 9/12/2008 1:35 PM
>     *To:* Eddy, Wesley M. (GRC-RCN0)[VZ]
>     *Cc:* Symington, Susan F.; Lloyd Wood;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [dtn-interest] Meeting frequency
> 
> 
> 
>     Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
> 
>     > In addition to the longer meeting, I think some kind of a "roadmap"
>     > document that simply explains all the DTNRG documents and how they
>     > fit together would help us target the important pieces to push
>     > forward with.  There's definitely a dependency graph starting to
>     > form between documents.  "Roadmap" is probably not the best word,
>     > but it's what we used for the same kind of document on TCP (RFC
>     > 4614); if there's a better name, let's use that :).  I think this
>     > is an essential document as more people are coming into DTN work
>     > and need to grasp the pieces of activity and how they relate.
> 
>     Obvious question:-) Was that you volunteering?
> 
>     While I agree with you that that'd be useful, esp. for new
>     folks, right now I think I'd still emphasise the need to
>     finish up some of the docs we've currently under way. But,
>     if you've time to knock out an I-D, by all means do!
> 
>     S.
> 
> 
>     _______________________________________________
>     dtn-interest mailing list
>     [email-masked]
>     <mailto:[email-masked]>
>     http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 

From: "Fall, Kevin" <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 15 Sep 2008 15:25:18 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Underlying Networks

well, this is somewhat true, but in being an overlay you can implement countermeasures that mitigate some of the problems.

For example, the RON overlay would do routing that was arguably 'better' than that provided by BGP.
DTN can, for example, can make more than one copy of a message, which may improve the probability of ultimately delivery.

The Amherst folks also observe that even an unauthenticated DTN is relatively more secure than the alternative:
http://portal.acm.org/citation.cfm?id=1288116&jmp=cit&coll=&dl=ACM

- K

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
Sent: Monday, September 15, 2008 8:34 AM
To: [email-masked]
Subject: [dtn-interest] Underlying Networks

Would it be fair to say that the DTN architecture , as a network
overlay, (and probably any network overlay - DTN or otherwise) inherits
and can exploit all to good characteristics of the underlying network,
but also inherits and can be exploited by the bad.  Some examples would
be security, routing, discovery etc....

/will

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

Date: Mon, 15 Sep 2008 18:19:40 -0400
From: "Rajesh Krishnan" <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Meeting frequency

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

Wes,

This is a very nice list.  I recommend listing metadata blocks under generic
extensions rather than under routing.

Best Regards,
Rajesh

On Sun, Sep 14, 2008 at 8:32 PM, Eddy, Wesley M. (GRC-RCN0)[VZ] <
[email-masked]> wrote:

>  Here's a first cut at a draft; it may be missing a couple docs still, so
> clue me in if I've forgotten anything.
>
>
> ------------------------------
> *From:* Stephen Farrell [mailto:[email-masked]]
> *Sent:* Fri 9/12/2008 1:35 PM
> *To:* Eddy, Wesley M. (GRC-RCN0)[VZ]
> *Cc:* Symington, Susan F.; Lloyd Wood; [email-masked]
> *Subject:* Re: [dtn-interest] Meeting frequency
>
>
>
> Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:
>
> > In addition to the longer meeting, I think some kind of a "roadmap"
> > document that simply explains all the DTNRG documents and how they
> > fit together would help us target the important pieces to push
> > forward with.  There's definitely a dependency graph starting to
> > form between documents.  "Roadmap" is probably not the best word,
> > but it's what we used for the same kind of document on TCP (RFC
> > 4614); if there's a better name, let's use that :).  I think this
> > is an essential document as more people are coming into DTN work
> > and need to grasp the pieces of activity and how they relate.
>
> Obvious question:-) Was that you volunteering?
>
> While I agree with you that that'd be useful, esp. for new
> folks, right now I think I'd still emphasise the need to
> finish up some of the docs we've currently under way. But,
> if you've time to knock out an I-D, by all means do!
>
> S.
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

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

<div dir="ltr">Wes,<br><br>This is a very nice list.&nbsp; I recommend listing metadata blocks under generic extensions rather than under routing.<br><br>Best Regards,<br>Rajesh <br><br><div class="gmail_quote">On Sun, Sep 14, 2008 at 8:32 PM, Eddy, Wesley M. (GRC-RCN0)[VZ] <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>
<div dir="ltr">
<div dir="ltr"><font size="2" color="#000000" face="Arial">Here&#39;s a first cut at a draft; it may be missing a couple docs still, so clue me in if I&#39;ve forgotten anything.</font></div>
<div dir="ltr">&nbsp;</div></div>
<div dir="ltr"><br>
<hr>
<font size="2" face="Tahoma"><b>From:</b> Stephen Farrell [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>]<br><b>Sent:</b> Fri 9/12/2008 1:35 PM<br><b>To:</b> Eddy, Wesley M. (GRC-RCN0)[VZ]<br>
<b>Cc:</b> Symington, Susan F.; Lloyd Wood; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br><b>Subject:</b> Re: [dtn-interest] Meeting frequency<br></font><br></div>
<div><br><br>
<p><font size="2">Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:<br><br>&gt; In addition to the longer meeting, I think some kind of a &quot;roadmap&quot;<br>&gt; document that simply explains all the DTNRG documents and how they<br>
&gt; fit together would help us target the important pieces to push<br>&gt; forward with.&nbsp; There&#39;s definitely a dependency graph starting to<br>&gt; form between documents.&nbsp; &quot;Roadmap&quot; is probably not the best word,<br>
&gt; but it&#39;s what we used for the same kind of document on TCP (RFC<br>&gt; 4614); if there&#39;s a better name, let&#39;s use that :).&nbsp; I think this<br>&gt; is an essential document as more people are coming into DTN work<br>
&gt; and need to grasp the pieces of activity and how they relate.<br><br>Obvious question:-) Was that you volunteering?<br><br>While I agree with you that that&#39;d be useful, esp. for new<br>folks, right now I think I&#39;d still emphasise the need to<br>
finish up some of the docs we&#39;ve currently under way. But,<br>if you&#39;ve time to knock out an I-D, by all means do!<br><br>S.<br><br></font></p></div></div><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" target="_blank">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a><br>
<br></blockquote></div><br></div>

------=_Part_19488_15289131.1221517180590--

Content-class: urn:content-classes:message
Date: Mon, 15 Sep 2008 10:33:36 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] Underlying Networks

Would it be fair to say that the DTN architecture , as a network
overlay, (and probably any network overlay - DTN or otherwise) inherits
and can exploit all to good characteristics of the underlying network,
but also inherits and can be exploited by the bad.  Some examples would
be security, routing, discovery etc....

/will

Content-class: urn:content-classes:message
Date: Sun, 14 Sep 2008 19:32:55 -0500
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Meeting frequency

This is a multi-part message in MIME format.

------_=_NextPart_001_01C916CB.434C5FB7
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C916CB.434C5FB7"

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

Here's a first cut at a draft; it may be missing a couple docs still, so =
clue me in if I've forgotten anything.
=20

________________________________

From: Stephen Farrell [mailto:[email-masked]]
Sent: Fri 9/12/2008 1:35 PM
To: Eddy, Wesley M. (GRC-RCN0)[VZ]
Cc: Symington, Susan F.; Lloyd Wood; [email-masked]
Subject: Re: [dtn-interest] Meeting frequency

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> In addition to the longer meeting, I think some kind of a "roadmap"
> document that simply explains all the DTNRG documents and how they
> fit together would help us target the important pieces to push
> forward with.  There's definitely a dependency graph starting to
> form between documents.  "Roadmap" is probably not the best word,
> but it's what we used for the same kind of document on TCP (RFC
> 4614); if there's a better name, let's use that :).  I think this
> is an essential document as more people are coming into DTN work
> and need to grasp the pieces of activity and how they relate.

Obvious question:-) Was that you volunteering?

While I agree with you that that'd be useful, esp. for new
folks, right now I think I'd still emphasise the need to
finish up some of the docs we've currently under way. But,
if you've time to knock out an I-D, by all means do!

S.

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

<HTML dir=3Dltr><HEAD><TITLE>Re: [dtn-interest] Meeting frequency</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6000.16711" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText67291 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Here's a =
first cut at a draft; it may be missing a couple docs still, so clue me =
in if I've forgotten anything.</FONT></DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Stephen Farrell =
[mailto:[email-masked]]<BR><B>Sent:</B> Fri 9/12/2008 1:35 =
PM<BR><B>To:</B> Eddy, Wesley M. (GRC-RCN0)[VZ]<BR><B>Cc:</B> Symington, =
Susan F.; Lloyd Wood; [email-masked]<BR><B>Subject:</B> =
Re: [dtn-interest] Meeting frequency<BR></FONT><BR></DIV>=0A=
<DIV><BR><BR>=0A=
<P><FONT size=3D2>Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:<BR><BR>&gt; In =
addition to the longer meeting, I think some kind of a "roadmap"<BR>&gt; =
document that simply explains all the DTNRG documents and how =
they<BR>&gt; fit together would help us target the important pieces to =
push<BR>&gt; forward with.&nbsp; There's definitely a dependency graph =
starting to<BR>&gt; form between documents.&nbsp; "Roadmap" is probably =
not the best word,<BR>&gt; but it's what we used for the same kind of =
document on TCP (RFC<BR>&gt; 4614); if there's a better name, let's use =
that :).&nbsp; I think this<BR>&gt; is an essential document as more =
people are coming into DTN work<BR>&gt; and need to grasp the pieces of =
activity and how they relate.<BR><BR>Obvious question:-) Was that you =
volunteering?<BR><BR>While I agree with you that that'd be useful, esp. =
for new<BR>folks, right now I think I'd still emphasise the need =
to<BR>finish up some of the docs we've currently under way. But,<BR>if =
you've time to knock out an I-D, by all means =
do!<BR><BR>S.<BR><BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_002_01C916CB.434C5FB7--

------_=_NextPart_001_01C916CB.434C5FB7
Content-Type: text/html;
	name="draft-eddy-dtnrg-doc-tree-00.html"
Content-Transfer-Encoding: base64
Content-Description: draft-eddy-dtnrg-doc-tree-00.html
Content-Disposition: attachment; filename="draft-eddy-dtnrg-doc-tree-00.html"

------_=_NextPart_001_01C916CB.434C5FB7--

Date: Mon, 15 Sep 2008 08:05:15 -0700
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported] RFC5050 (1504)]

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

Scott, Keith L. wrote:
> I think the 1504--1505 set needs correction in the document.
Yes, a good catch; correction is needed in sections 6.1.1 and 6.1.2.
> I wonder
> if it would make sense to propose redrawing figures 10 and 13 to
> explicitly show the administrative record type and flags?
>   
Either that or else re-label those figures as "Bundle Status Report 
Record Content Format" and "Custody Signal Record Content Format", to 
make it clear that neither one depicts the complete administrative record.
> 1506 is easy and should be fixed.
>   
I agree.

Scott
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Stephen Farrell
> Sent: Monday, September 15, 2008 8:17 AM
> To: DTN
> Cc: [email-masked]
> Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported]
> RFC5050 (1504)]
>
>
> So there're a couple more errata reports that've trickled out,
> not sure if that's the lot but they're all available at [1].
> Processing 'em as a bunch seems right.
>
> Also, if anyone else knows of any others for 5050, posting
> them now would be nice. You can also find instructions
> from [1].
>
> S.
>
> [1] http://www.rfc-editor.org/errata_search.php?rfc=5050
>
> Stephen Farrell wrote:
>   
>> FYI. So that this hits the list.
>>
>> Be good if the authors of 5050 could check if the erratum is
>> good or not and report back here initially.
>>
>> Then we can have all the fun of figuring out how the RFC errata
>> system works in IRTF land;-)
>>
>> Thanks,
>> Stephen.
>>
>>
>>
>>
>>     
> -----------------------------------------------------------------------
> -
>   
>> _______________________________________________
>> 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
>
>   

--------------080809040909020303060208
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">
Scott, Keith L. wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">I think the 1504--1505 set needs correction in the document.</pre>
</blockquote>
Yes, a good catch; correction is needed in sections 6.1.1 and 6.1.2.<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">I wonder
if it would make sense to propose redrawing figures 10 and 13 to
explicitly show the administrative record type and flags?
  </pre>
</blockquote>
Either that or else re-label those figures as "Bundle Status Report
Record Content Format" and "Custody Signal Record Content Format", to
make it clear that neither one depicts the complete administrative
record.<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">1506 is easy and should be fixed.
  </pre>
</blockquote>
I agree.<br>
<br>
Scott<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of
Stephen Farrell
Sent: Monday, September 15, 2008 8:17 AM
To: DTN
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported]
RFC5050 (1504)]

So there're a couple more errata reports that've trickled out,
not sure if that's the lot but they're all available at [1].
Processing 'em as a bunch seems right.

Also, if anyone else knows of any others for 5050, posting
them now would be nice. You can also find instructions
from [1].

S.

[1] <a class="moz-txt-link-freetext" href="http://www.rfc-editor.org/errata_search.php?rfc=5050">http://www.rfc-editor.org/errata_search.php?rfc=5050</a>

Stephen Farrell wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">FYI. So that this hits the list.

Be good if the authors of 5050 could check if the erratum is
good or not and report back here initially.

Then we can have all the fun of figuring out how the RFC errata
system works in IRTF land;-)

Thanks,
Stephen.

    </pre>
  </blockquote>
  <pre wrap=""><!---->-----------------------------------------------------------------------
-
  </pre>
  <blockquote type="cite">
    <pre wrap="">_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>

_______________________________________________
dtn-interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</a>

  </pre>
</blockquote>
<br>
</body>
</html>

--------------080809040909020303060208--

Content-class: urn:content-classes:message
Date: Mon, 15 Sep 2008 08:41:06 -0400
From: "Scott, Keith L." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported] RFC5050 (1504)]

I think the 1504--1505 set needs correction in the document.  I wonder
if it would make sense to propose redrawing figures 10 and 13 to
explicitly show the administrative record type and flags?

1506 is easy and should be fixed.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Stephen Farrell
Sent: Monday, September 15, 2008 8:17 AM
To: DTN
Cc: [email-masked]
Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported]
RFC5050 (1504)]

So there're a couple more errata reports that've trickled out,
not sure if that's the lot but they're all available at [1].
Processing 'em as a bunch seems right.

Also, if anyone else knows of any others for 5050, posting
them now would be nice. You can also find instructions
from [1].

S.

[1] http://www.rfc-editor.org/errata_search.php?rfc=5050

Stephen Farrell wrote:
> FYI. So that this hits the list.
> 
> Be good if the authors of 5050 could check if the erratum is
> good or not and report back here initially.
> 
> Then we can have all the fun of figuring out how the RFC errata
> system works in IRTF land;-)
> 
> Thanks,
> Stephen.
> 
> 
> 
>
-----------------------------------------------------------------------
-
> 
> _______________________________________________
> 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: Mon, 15 Sep 2008 13:17:04 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported] RFC5050 (1504)]

So there're a couple more errata reports that've trickled out,
not sure if that's the lot but they're all available at [1].
Processing 'em as a bunch seems right.

Also, if anyone else knows of any others for 5050, posting
them now would be nice. You can also find instructions
from [1].

S.

[1] http://www.rfc-editor.org/errata_search.php?rfc=5050

Stephen Farrell wrote:
> FYI. So that this hits the list.
> 
> Be good if the authors of 5050 could check if the erratum is
> good or not and report back here initially.
> 
> Then we can have all the fun of figuring out how the RFC errata
> system works in IRTF land;-)
> 
> Thanks,
> Stephen.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 15 Sep 2008 12:55:39 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] [Fwd: [IRSG] [Technical Errata Reported] RFC5050 (1504)]

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

FYI. So that this hits the list.

Be good if the authors of 5050 could check if the erratum is
good or not and report back here initially.

Then we can have all the fun of figuring out how the RFC errata
system works in IRTF land;-)

Thanks,
Stephen.

--------------010609030606080705010201
Content-Type: message/rfc822;
	name="[IRSG] [Technical Errata Reported] RFC5050 (1504).eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename*0="[IRSG] [Technical Errata Reported] RFC5050 (1504).eml"

Date: Mon, 15 Sep 2008 04:32:34 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked]
From: RFC Errata System <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [IRSG] [Technical Errata Reported] RFC5050 (1504)
Sender: [email-masked]

The following errata report has been submitted for RFC5050,
"Bundle Protocol Specification".

--------------------------------------
You may review the report below and at:
http://www.RFC-Editor.ORG/errata_search.php?rfc=5050&eid=1504

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <[email-masked]>

Section: 6.1.1,pg.40

Original Text
-------------
|  Fragment Offset:   If the bundle fragment bit is set in the status
|     flags, then the offset (within the original application data unit)
      of the payload of the bundle that caused the status report to be
      generated is included here.

|  Fragment length:   If the bundle fragment bit is set in the status
|     flags, then the length of the payload of the subject bundle is
      included here.

Corrected Text
--------------
|  Fragment Offset:   If the bundle fragment bit is set in the
|     administrative record flags, then the offset (within the original
      application data unit) of the payload of the bundle that caused
      the status report to be generated is included here.

|  Fragment length:   If the bundle fragment bit is set in the
|     administrative record flags, then the length of the payload of
      the subject bundle is included here.

Notes
-----
Note the distinct fields:
 -- administrative record flags (least significant nibble of the
    one-octet administrative record header, per Figure 9 on pg.37)
 -- status flags (first octet in the body of a bundle status report,
    per Figure 11 on page 39)
The fragment bit is contained in the former, not in the latter.

Attention: this same issue recurs literally in Section 6.1.2,
on pg. 43, below Figure 14 !

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IRSG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5050 (draft-irtf-dtnrg-bundle-spec-10)
--------------------------------------
Title               : Bundle Protocol Specification
Publication Date    : November 2007
Author(s)           : K. Scott, S. Burleigh
Category            : EXPERIMENTAL
Source              : IRTF
Area                : N/A
Stream              : IRTF
Verifying Party     : IRSG
_______________________________________________
IRSG mailing list
[email-masked]
http://mailman.isi.edu/mailman/listinfo/irsg

--------------010609030606080705010201--

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
XX-CMAE-analysis: score=0 v=1.0 c=1 a=bVn98QAQIUEA:10 a=8vMRVc6N1JgA:10 a=reRN_k78R_QA:10 a=XeILQGAkmLZIDoMhSed7pQ==:17 a=m4JX3AljAAAA:8 a=axOpDwRbD8HbptVDqsYA:9 a=i5fKM1VaRsJComlnzNnuDzpHVKUA:4 a=50e4U0PicR4A:10 a=6SwCy3u5AAAA:8 a=lipYB1ZX6au47Wod_NMA:7 a=W_H42hdxNQzqBRcUXkwRU9MUfocA:4 a=MRcuu4QPSFIA:10
Date: 15 Sep 2008 03:27:00 -0000
From: "laveen vikram sundararaj" <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at IETF-73)
Reply-To: laveen vikram sundararaj <[email-masked]>

 This is a multipart mime message

--Next_1221449220---0-202.137.234.213-6168
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi=0AI would like to extend my support for the proposed 2/3 day meeting (DT=
NRG meeting?). Pls let us know upfront so that we can arrange for the logis=
tics (VISA?).=A0=0AAlso in NOV, shall we have the informal session too (Fre=
e Beer?) during the IETF weekend, so that group folks who could not make it=
 to the conf can catch up?=0Aregards,=0ALaveen.=0A=0AOn Fri, 12 Sep 2008 St=
ephen Farrell wrote :=0A>=0A>=0A>Lloyd Wood wrote:=0A> > Running out of tim=
e is imo an indication that there's likely sufficient interest to hold a me=
eting every IETF, rather than every second IETF, to spread the load, rather=
 than selecting 'worthy' speakers in a crowded session. If, as I suspect, t=
his turns out to be a busy meeting, that should really be considered.=0A>=
=0A>Maybe. We certainly had too much on the agenda last time.=0A>=0A>Or per=
haps it means we should schedule a 2/3 day meeting sometime in the=0A>new y=
ear, away from the IETF, as we've done before.=0A>=0A>If others feel we sho=
uld change the meeting frequency or arrange a=0A>few days away from the IET=
F saying so now would be good,=0A>Cheers,=0A>S.=0A>=0A>PS: I've asked for a=
 2.5 hour session for DTNRG for Thursday or=0A>Friday morning. As always, s=
cheduling will not be certain for a=0A>good while yet.=0A>=0A>=0A>_________=
______________________________________=0A>dtn-interest mailing list=0A>dtn-=
[email-masked]=0A>http://maillists.intel-research.ne=
t/mailman/listinfo/dtn-interest=0A
--Next_1221449220---0-202.137.234.213-6168
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHi<BR>=0AI would like to extend my support for the proposed 2/3 day m=
eeting (DTNRG meeting?). Pls let us know upfront so that we can arrange for=
 the logistics (VISA?).=A0<BR>=0AAlso in NOV, shall we have the informal se=
ssion too (Free Beer?) during the IETF weekend, so that group folks who cou=
ld not make it to the conf can catch up?<BR>=0Aregards,<BR>=0ALaveen.<BR>=
=0A<BR>=0AOn Fri, 12 Sep 2008 Stephen Farrell wrote :<BR>=0A&gt;<BR>=0A&gt;=
<BR>=0A&gt;Lloyd Wood wrote:<BR>=0A&gt; &gt; Running out of time is imo an =
indication that there's likely sufficient interest to hold a meeting every =
IETF, rather than every second IETF, to spread the load, rather than select=
ing 'worthy' speakers in a crowded session. If, as I suspect, this turns ou=
t to be a busy meeting, that should really be considered.<BR>=0A&gt;<BR>=0A=
&gt;Maybe. We certainly had too much on the agenda last time.<BR>=0A&gt;<BR=
>=0A&gt;Or perhaps it means we should schedule a 2/3 day meeting sometime i=
n the<BR>=0A&gt;new year, away from the IETF, as we've done before.<BR>=0A&=
gt;<BR>=0A&gt;If others feel we should change the meeting frequency or arra=
nge a<BR>=0A&gt;few days away from the IETF saying so now would be good,<BR=
>=0A&gt;Cheers,<BR>=0A&gt;S.<BR>=0A&gt;<BR>=0A&gt;PS: I've asked for a 2.5 =
hour session for DTNRG for Thursday or<BR>=0A&gt;Friday morning. As always,=
 scheduling will not be certain for a<BR>=0A&gt;good while yet.<BR>=0A&gt;<=
BR>=0A&gt;<BR>=0A&gt;_______________________________________________<BR>=0A=
&gt;dtn-interest mailing list<BR>=0A&gt;[email-masked]=
ch.net<BR>=0A&gt;http://maillists.intel-research.net/mailman/listinfo/dtn-i=
nterest<BR>=0A=0A</P>=0A<br><br>=0A<Table border=3D0 Width=3D644 Height=3D5=
7 cellspacing=3D0 cellpadding=3D0 style=3D'font-family:Verdana;font-size:11=
px;line-height:15px;'><TR><td><a href=3D'http://adworks.rediff.com/cgi-bin/=
AdWorks/click.cgi/www.rediff.com/signature-home.htm/1050715198@Middle5/2206=
641_2199021/2201649/1?PARTNER=3D3&OAS_QUERY=3Dnull' target=3Dnew ><img src =
=3D'http://imadworks.rediff.com/cgi-bin/AdWorks/adimage.cgi/2206641_2199021=
/creative_2201649.gif'  alt=3D'Rediff Shopping'  border=3D0></a></td></TR><=
/Table>
--Next_1221449220---0-202.137.234.213-6168--

From: Hans Kruse <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Fri, 12 Sep 2008 15:44:41 -0400
Subject: Re: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at IETF-73)

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

I would prefer to go with an "interim" meeting as well.

On Sep 12, 2008, at 12:29 PM, Stephen Farrell wrote:

>
>
> Lloyd Wood wrote:
>> Running out of time is imo an indication that there's likely  
>> sufficient interest to hold a meeting every IETF, rather than every  
>> second IETF, to spread the load, rather than selecting 'worthy'  
>> speakers in a crowded session. If, as I suspect, this turns out to  
>> be a busy meeting, that should really be considered.
>
> Maybe. We certainly had too much on the agenda last time.
>
> Or perhaps it means we should schedule a 2/3 day meeting sometime in  
> the
> new year, away from the IETF, as we've done before.
>
> If others feel we should change the meeting frequency or arrange a
> few days away from the IETF saying so now would be good,
> Cheers,
> S.
>
> PS: I've asked for a 2.5 hour session for DTNRG for Thursday or
> Friday morning. As always, scheduling will not be certain for a
> good while yet.
>
>
> _______________________________________________
> 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-7-275829498
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; ">I would prefer to go with an =
"interim" meeting as well.<div><br><div><div>On Sep 12, 2008, at 12:29 =
PM, Stephen Farrell wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br><br>Lloyd Wood wrote:<br><blockquote =
type=3D"cite">Running out of time is imo an indication that there's =
likely sufficient interest to hold a meeting every IETF, rather than =
every second IETF, to spread the load, rather than selecting 'worthy' =
speakers in a crowded session. If, as I suspect, this turns out to be a =
busy meeting, that should really be =
considered.<br></blockquote><br>Maybe. We certainly had too much on the =
agenda last time.<br><br>Or perhaps it means we should schedule a 2/3 =
day meeting sometime in the<br>new year, away from the IETF, as we've =
done before.<br><br>If others feel we should change the meeting =
frequency or arrange a<br>few days away from the IETF saying so now =
would be good,<br>Cheers,<br>S.<br><br>PS: I've asked for a 2.5 hour =
session for DTNRG for Thursday or<br>Friday morning. As always, =
scheduling will not be certain for a<br>good while =
yet.<br><br><br>_______________________________________________<br>dtn-int=
erest mailing list<br><a =
href=3D"mailto:[email-masked]">dtn-interest@mai=
llists.intel-research.net</a><br>http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest<br></div></blockquote></div><br><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-7-275829498--

Date: Fri, 12 Sep 2008 19:35:27 +0100
From: Stephen Farrell <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Meeting frequency

Eddy, Wesley M. (GRC-RCN0)[VZ] wrote:

> In addition to the longer meeting, I think some kind of a "roadmap"
> document that simply explains all the DTNRG documents and how they
> fit together would help us target the important pieces to push
> forward with.  There's definitely a dependency graph starting to
> form between documents.  "Roadmap" is probably not the best word,
> but it's what we used for the same kind of document on TCP (RFC
> 4614); if there's a better name, let's use that :).  I think this
> is an essential document as more people are coming into DTN work
> and need to grasp the pieces of activity and how they relate.

Obvious question:-) Was that you volunteering?

While I agree with you that that'd be useful, esp. for new
folks, right now I think I'd still emphasise the need to
finish up some of the docs we've currently under way. But,
if you've time to knock out an I-D, by all means do!

S.

Content-class: urn:content-classes:message
Date: Fri, 12 Sep 2008 12:48:23 -0500
From: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>
To: "Symington, Susan F." <[email-masked]>, "Stephen Farrell" <[email-masked]>, "Lloyd Wood" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting atIETF-73)

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Symington, Susan F.
>Sent: Friday, September 12, 2008 12:55 PM
>
>I would like to see a number of the I-Ds that are now in the pipeline
>progress to RFC status. It seems that interim meetings, during which we
>can meet for longer than a 2.5 hour timeslot, would be a good way to
>facilitate more detailed discussions on the drafts that may need to
>take place.  

In addition to the longer meeting, I think some kind of a "roadmap"
document that simply explains all the DTNRG documents and how they
fit together would help us target the important pieces to push
forward with.  There's definitely a dependency graph starting to
form between documents.  "Roadmap" is probably not the best word,
but it's what we used for the same kind of document on TCP (RFC
4614); if there's a better name, let's use that :).  I think this
is an essential document as more people are coming into DTN work
and need to grasp the pieces of activity and how they relate.

From: Jeff Doyle <[email-masked]>
To: Stephen Farrell <[email-masked]>, "Symington, Susan F." <[email-masked]>, Lloyd Wood <[email-masked]>
Date: Fri, 12 Sep 2008 11:09:40 -0600
Cc: [email-masked]
Subject: Re: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at IETF-73)

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

As someone new to this WG and interested in learning how I can begin  
contributing, I also vote for a multi-day meeting separate from IETF.

Jeff Doyle

On Sep 12, 2008, at 10:55 AM, Symington, Susan F. wrote:

> I would like to see a number of the I-Ds that are now in the pipeline
> progress to RFC status. It seems that interim meetings, during which  
> we
> can meet for longer than a 2.5 hour timeslot, would be a good way to
> facilitate more detailed discussions on the drafts that may need to
> take place.
>
> Please mark me down as being in favor of arranging a multi-day meeting
> away from the IETF. Thanks.
>
> -susan
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>
>> -----Original Message-----
>> From: [email-masked] [mailto:dtn-
>> [email-masked]] On Behalf Of Stephen
>> Farrell
>> Sent: Friday, September 12, 2008 12:30 PM
>> To: Lloyd Wood
>> Cc: [email-masked]
>> Subject: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at
>> IETF-73)
>>
>>
>>
>> Lloyd Wood wrote:
>>> Running out of time is imo an indication that there's likely
>> sufficient interest to hold a meeting every IETF, rather than every
>> second IETF, to spread the load, rather than selecting 'worthy'
> speakers
>> in a crowded session. If, as I suspect, this turns out to be a busy
>> meeting, that should really be considered.
>>
>> Maybe. We certainly had too much on the agenda last time.
>>
>> Or perhaps it means we should schedule a 2/3 day meeting sometime in
> the
>> new year, away from the IETF, as we've done before.
>>
>> If others feel we should change the meeting frequency or arrange a
>> few days away from the IETF saying so now would be good,
>> Cheers,
>> S.
>>
>> PS: I've asked for a 2.5 hour session for DTNRG for Thursday or
>> Friday morning. As always, scheduling will not be certain for a
>> good while yet.
>>
>>
>> _______________________________________________
>> 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
>

--Apple-Mail-35-266528467
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-35-266528467--

Content-class: urn:content-classes:message
Date: Fri, 12 Sep 2008 12:55:00 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Lloyd Wood" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at IETF-73)

I would like to see a number of the I-Ds that are now in the pipeline
progress to RFC status. It seems that interim meetings, during which we
can meet for longer than a 2.5 hour timeslot, would be a good way to
facilitate more detailed discussions on the drafts that may need to
take place.  

Please mark me down as being in favor of arranging a multi-day meeting
away from the IETF. Thanks.

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

>-----Original Message-----
>From: [email-masked] [mailto:dtn-
>[email-masked]] On Behalf Of Stephen
>Farrell
>Sent: Friday, September 12, 2008 12:30 PM
>To: Lloyd Wood
>Cc: [email-masked]
>Subject: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at
>IETF-73)
>
>
>
>Lloyd Wood wrote:
>> Running out of time is imo an indication that there's likely
>sufficient interest to hold a meeting every IETF, rather than every
>second IETF, to spread the load, rather than selecting 'worthy'
speakers
>in a crowded session. If, as I suspect, this turns out to be a busy
>meeting, that should really be considered.
>
>Maybe. We certainly had too much on the agenda last time.
>
>Or perhaps it means we should schedule a 2/3 day meeting sometime in
the
>new year, away from the IETF, as we've done before.
>
>If others feel we should change the meeting frequency or arrange a
>few days away from the IETF saying so now would be good,
>Cheers,
>S.
>
>PS: I've asked for a 2.5 hour session for DTNRG for Thursday or
>Friday morning. As always, scheduling will not be certain for a
>good while yet.
>
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 12 Sep 2008 17:29:44 +0100
From: Stephen Farrell <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] Meeting frequency (was: Re: DTNRG meeting at IETF-73)

Lloyd Wood wrote:
> Running out of time is imo an indication that there's likely sufficient interest to hold a meeting every IETF, rather than every second IETF, to spread the load, rather than selecting 'worthy' speakers in a crowded session. If, as I suspect, this turns out to be a busy meeting, that should really be considered.

Maybe. We certainly had too much on the agenda last time.

Or perhaps it means we should schedule a 2/3 day meeting sometime in the
new year, away from the IETF, as we've done before.

If others feel we should change the meeting frequency or arrange a
few days away from the IETF saying so now would be good,
Cheers,
S.

PS: I've asked for a 2.5 hour session for DTNRG for Thursday or
Friday morning. As always, scheduling will not be certain for a
good while yet.

Date: Fri, 12 Sep 2008 16:11:28 +0100
To: [email-masked]
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] DTNRG meeting at IETF-73

Wes Eddy and I will be attending.

We have the following drafts we'll need to revise for a DTNRG meet in Minneapolis:

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-checksum
this one's quite important; we were only able to present one of our slides at the last meet, so haven't even walked through that material and its implications in full. See previous slides at:
http://www.ietf.org/proceedings/08mar/DTNRG.html
We have not received any significant feedback on the -02 version from the group (though -01 attracted a bit of comment). Definitely needs a slot

http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
is also worth publishing; I'm under the impression that there was some interest in seeing this proceed. Workgroup draft, its status should be discussed at least briefly.

http://tools.ietf.org/html/draft-wood-dtnrg-saratoga
this is related to our use of the Bundle Protocol in space and recent successful testing in our prototype Interplanetary Internet.

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
Is this the only thing that is currently preventing DTNRG being called the Bundle Architecture Research Group?

Running out of time is imo an indication that there's likely sufficient interest to hold a meeting every IETF, rather than every second IETF, to spread the load, rather than selecting 'worthy' speakers in a crowded session. If, as I suspect, this turns out to be a busy meeting, that should really be considered.

L.

>>From: Stephen Farrell <[email-masked]>
>>Date: 9 September 2008 15:07:46 BST
>>To: DTN <[email-masked]>
>>Subject: [dtn-interest] DTNRG meeting at IETF-73
>>
>>
>>Hi all,
>>
>>A number of people suggested that we schedule a slot for meeting
>>at IETF-73. [1] Can you let Kevin and I know (off-list is fine,
>>I'll summarise back to the list):
>>
>>- if you plan to attend, and which days suit
>>- if there's something particular related to the current set of
>> documents that you want on the agenda
>>- if you want a slot to speak and if so what about and for how
>> long (note that we may have to figure out a way to select a
>> subset of the requests - last time we had too many speakers
>> and ran out of time)
>>
>>By default I'll ask for a 2.5 hour slot Thursday or Friday
>>morning. The request has to be in by Monday, so get your
>>answers in soon!
>>
>>Cheers,
>>S.
>>
>>[1] http://www.ietf.org/meetings/73/

To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Fri, 12 Sep 2008 10:18:24 +0100
From: Milena V Radenkovic <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

Great news --- big congratulations,

Milena

In your message of Thu, 11 Sep 2008 10:51:09 -0500 you wrote:

> First, I would like to thank both the NASA and SSTL procurement officers
> for their patience, professionalism and diligence as these results would
> not have been possible without their hard work.
> 
> UK-DMC satellite first to transfer sensor data from space using 'bundle'
> protocol
> http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
> 
> 
> "Use of the Delay-Tolerant Networking Bundle Protocol from Space"
> Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
> Jackson, Alex da Silva Curiel.
> 
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
> iac-2008
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +
> 
> The following is a summary of the flight tests and test results for DTN
> flight testing using the UK-DMC satellite.  Download was to SSTL's
> ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
> 8.1 Mbps.
> 
> These tests are a repeat of the January testing reported at the IRTF
> meeting at IETF-71 in March 2008 and at the NASA Earth Science
> Technology Conference in June 2008.  See:
> 
> http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
> f
> http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
> F_DTN.ppt
> 
> 
> Test Plan:
> ==========
> The image should be taken with the MD5 checksum enabled. 
> 
> DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
> 1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
> Station
> 2)      Demonstrate that DTN code and general SSTL code can coexist
> without effecting normal SSTL Operations
> 
> Configuration
> *       UK-DMC acquired a 150 Mbyte image.
> *       DTN bundling code default set to 80 Mbytes for proactive
> fragmentation
> Tests
> 1)      Basic file download using existing technique (GRC Saratoga)
> 2)      Same file downloaded but treated as single bundle (DTN)
> 3)      Same file download but using DTN proactive fragmentation with 80
> Mbytes preconfigured fragments.
> 3a)     Somewhere in the downloads we want to make sure we download the
> sysconfig that has the MD5 payload checksum
> 4)      Basic file download using SSTL Saratoga
> 
> 
> 
> 
> August 26th UK-DMC passes:
> ============================
> 07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR
> code.
> 
> 07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).
> 
> 08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).
> 
> 09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).
> ============================
> 
> The following is preliminary results for the 8:07 pass:
> 
> 1) Successfully downloaded syslog.  No MD5 calculation present.
> 2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga
> 3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload
> 3) Downloaded 1st 80 Mbyte bundle fragment
> 4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at
> about 2/3 complete. (Soft of a good thing in that we get to test 2 pass
> recombining.)
> 5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent
> to GRC Bundle Agent and GRC took custody of both full bundle and 1st
> bundle fragment. 
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file
> (Result is f434d0116a1f8b8e5a1cfff4a931812c)
> 
> Extracted payload from GRC bundle agent (full file) and checked MD5.  It
> matched full file MD5.
> 
> Checked SSDR code and discovered MD5 telecommand handling problem.  Code
> assumes that images end in ".img"!  That works on Cisco Engineering
> testbed, but is not a valid assumption for UK-DMC. 
> 
> 
> The following is preliminary results for the 9:45 pass:
> 
> 1) Downloaded 2nd 70 Mbyte bundle fragment
> 2) Downloaded syslog
> 3) SSTL downloaded image with SSTL's Saratoga Implementation
> 4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC
> Bundle Agent. GRC took custody of 2nd bundle fragment. 
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file and payload portion of the full bundle
> brought Down by GRC Saratoga (Result is
> f434d0116a1f8b8e5a1cfff4a931812c) matched.
> 
> Extracted payload from  2 fragments and checked MD5.  MD5 did not Match!
> 
> - Inspected Bundle Fragments and noted header overwrite - index problem
> puts 4 bytes of DTN header into the header.
> - Inspected syslog and noted that build was April 11th which had the
> overwrite problem discovered in lab testing in August. 
>  Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin
> 
> Preliminary results/conclusions:
> ===============================
> Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle
> and file downloads with GRC Saratoga implementation.  Current MD5 is
> EXTREMELY promising.
> This was done August 28th and comparison was correct.  So File from
> "file" download using GRC and SSTL Saratoga implementation matched as
> did bundle payload of GRC bundle download using Saratoga.
> 
> 
> - Latest SSDR build was not used.  April 11th build had fragmentation
> index problem.  That is why SSTL got error message when sending MD5
> command (Hex 60) because the command did not exist in the April 11th
> build.
> 
> ***  GRC already rewritten and compiled new SSDR code to run MD5
> calculations on files larger than 5 Mbytes.  Yet to be will test in
> Cisco Engineering Model testbed and once we confirm tests then we will
> send new code to SSTL for flight tests.  ***
> 
> 
> August 27th UK-DMC Passes:
> **** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin
> ===================================================================
> The image is scheduled for 08:27 UTC, again over South Africa.
> 
> The MD5 command is scheduled for 08:35 UTC
> 
> 1st pass is between 08:44 and 08:57 UTC
> 
> 2nd pass is between 10:23 and 10:34 UTC
> ==============================================
> 
> The first pass results are as follows:
> 
> 1) Downloaded Syslog successfully
> 2) Downloaded Bundle Frag 1 (80 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 3) Downloaded Bundle Frag 2 (77.5 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 4) Downloaded File using GRC Saratoga
> 4a) Lots of bursts of errors on initial download.  Caused a fail of
> transfer as "inactivity timeout". Saratoga timed out. 
> 4b) We restarted our Saratoga client - just for good measure.
> 4c) Restarted file transfer using Saratoga and successfully completed.
> 
> 
> Post Processing
> =================
> 1) Combined and extracted file from two bundle fragments.  Calculated
> Checksum
> 2) Ran MD5 checksum on file residing on SSTL Bundle Agent
> 
> Results matched as shown below:  Proves fragmentation is working!  This
> also match checksum of SSTL file download calculated August 28th.
> 
> [weddy@bundling-SSTL ~]$ md5sum DU000d72pm
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm [weddy@Bundle-Master ~]$
> md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
> 
> 3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and
> placed on Web Server for SSTL post processing.
> 
> The following is the terminal log from GRC Bundle Master:
> ============================================================
> # Performed list command. Shows 1st fragment.# Currently Pending Bundles
> (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle
> list Currently Pending Bundles (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%
> bundle list Currently Pending Bundles (2):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000
>         92716: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 77500550
> 
> # Application Requested Bundle to File at GRC Bundle Master and Bundle
> Fragments are combined.# bundling-grc dtn% [1219828317.602151
> /dtn/bundle/daemon warning] event REGISTRATION_ADDED took 2335 ms to
> process
> [1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED
> took 2218 ms to process bundle list Currently Pending Bundles (1):
>         92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 157500550
> 
> bundling-grc dtn% bundle list
> Currently Pending Bundles (0):
> 
> bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event
> BUNDLE_FREE took 2402 ms to process
> [1219828324.915598 /timer warning] timer thread running slow -- timer is
> 2313 msecs late
> 
> # Performed list command. Shows bundles have been removed from Bundle
> Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):
> 
> bundling-grc dtn%
> 
> 
> The following was performed during pass 2, 10:23 UTC
> 
> Order of tests Pass 2:
> ======================
> 1) Download Syslog successfully
> 2) Download Frag 2 successfully
> 2a) Frag 2 was forwarded to GRC Bundle Master
> 2b) Copied First Pass Frag-2 form temporary directory file to another
> location on SSTL Bundle Agent
> 2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and
> second pass.  MD5 results match.  Conclusion is use of multiple ground
> stations and proactive fragmentation will work.
> 
> [weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-1_frag2.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-2_frag2.dtn
> 
> 3) Download full Bundle using GRC Saratoga
> 3a) Similar to pass 1, we received bursts of errors causing Saratoga to
> time out.  Due to the limited time pass, we terminated this test in
> order to give SSTL sufficient time to download the image file.
> 
> 4) Download Syslog successfully using GRC Saratoga
> 
> 4) Download File successfully using SSTL Saratoga
> 
> 
> SSTL  FTPed their image downloads to GRC and we confirmed MD5 check on
> August 28th.
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm         
> # file downloaded by SSTL Aug 26, 2008 pass
> f434d0116a1f8b8e5a1cfff4a931812c  DU000d70pm
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm         
> # file downloaded by SSTL Aug 27,2008 pass
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm
> 
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img    
> # file download as 2 fragments & xfer via DTN to bundle-master Aug 26,
> 2008 pass fb03c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img  #
> MD5 mismatch due to file corrupted from bug in old GRC generated SSDR
> binary.
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img    
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c 
> Aug262008-1_ufrag_dtn.img   
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> [weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn            
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e 
> Aug272008-1_frag.dtn         
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> ******************************************
> Regarding GRC's Implementation of Saratoga
> ******************************************
> We have some ideas on why GRC's Saratoga may be timing out. We will look
> at that in the next few days, weeks.  We didn't problems with Saratoga
> on August 26th.  That pass was at a very high elevation (almost directly
> overhead). SSTL will check the telemetry logs to see if there was
> interference or something.  From the background conversations, we
> believe that SSTL has their timeout settings longer GRC's for Saratoga.
> Also, we understand that SSTL's Saratoga can restart from where it left
> off whereas GRC's restarts at the beginning.  Finally, in order to
> minimize transmissions on the 9600 bps uplink, SSTL does some hole
> combining requests prior to asking for retransmissions - basically just
> requesting retransmission of a large segment rather than small gaps of
> holes.  This is done to minimize the back-channel transmission otherwise
> one creates self congestion in the 9600 uplink.
> 
> 
> ===========================================
> I place the image that was extracted from the DTN full bundle at the
> following location:
> 
> http://roland.grc.nasa.gov/~ivancic/shared/DTN/
> 
> .tiff is approximately 150 Mbytes
> .pdf is 150 kbytes
> Other is raw unprocessed data. 
> 
> /Will Ivancic 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

--
                                   ,,,
                                  (o o)
/ ----------------------------oOO--(_)--OOo-----------------------------\ 
| Milena Radenkovic                 |  Work Tel:  +44 (0)115 84 67670   |
| Communications Research Group     |       Fax:  +44 (0)115 951 4254   |
| School of Computer Science and IT |                                   |
| University of Nottingham          |     Email:   [email-masked]    |
| Jubilee Campus, Wollaton Road     |                                   |
| Nottingham NG8 1BB, ENGLAND       | http://www.crg.cs.nott.ac.uk/~mvr |
\----------------------------------/ \----------------------------------/

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Date: Thu, 11 Sep 2008 20:46:26 -0700 (PDT)
From: Hadi <[email-masked]>
To: "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>, [email-masked]
Subject: [dtn-interest] Congragulations

--0-1256310656-1221191186=:94127
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,=0A=0Acongargulations on the successfull results.=0A=0AKeep it up.=0A=0A=
Hadi.=0A=0A=0A=0A----- Original Message ----=0AFrom: "Ivancic, William D. (=
GRC-RHN0)" <[email-masked]>=0ATo: [email-masked]=
g; [email-masked]=0ACc: [email-masked]=0ASe=
nt: Thursday, September 11, 2008 8:51:09 PM=0ASubject: [dtn-interest] 1st S=
uccessful Bundling Tests from Space - Technical Results=0A=0AFirst, I would=
 like to thank both the NASA and SSTL procurement officers=0Afor their pati=
ence, professionalism and diligence as these results would=0Anot have been =
possible without their hard work.=0A=0AUK-DMC satellite first to transfer s=
ensor data from space using 'bundle'=0Aprotocol=0Ahttp://www.sstl.co.uk/New=
s_and_Events/Latest_News/?story=3D1254=0A=0A=0A"Use of the Delay-Tolerant N=
etworking Bundle Protocol from Space"=0ALloyd Wood, Will Ivancic, Wes Eddy,=
 Dave Stewart, James Northam, Chris=0AJackson, Alex da Silva Curiel.=0A=0Ah=
ttp://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/=0Ahttp://personal.=
ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#=0Aiac-2008=0A=0A=
=0A++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
=0A+=0A=0AThe following is a summary of the flight tests and test results f=
or DTN=0Aflight testing using the UK-DMC satellite.=A0 Download was to SSTL=
's=0Aground station in Guildford, England.=A0 Uplink is 9600 bps, Downlink =
is=0A8.1 Mbps.=0A=0AThese tests are a repeat of the January testing reporte=
d at the IRTF=0Ameeting at IETF-71 in March 2008 and at the NASA Earth Scie=
nce=0ATechnology Conference in June 2008.=A0 See:=0A=0Ahttp://esto.nasa.gov=
/conferences/estc2008/papers/Ivancic_William_A4P2.pd=0Af=0Ahttp://roland.gr=
c.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT=0AF_DTN.ppt=0A=0A=
=0ATest Plan:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AThe image should be taken =
with the MD5 checksum enabled. =0A=0ADTN Test Plan for Initial DTN Testing =
using the UK-DMC Goal=0A1)=A0 =A0 =A0 Demonstrate DTN Bundle Transfer from =
UK-DMC to SSTL Ground=0AStation=0A2)=A0 =A0 =A0 Demonstrate that DTN code a=
nd general SSTL code can coexist=0Awithout effecting normal SSTL Operations=
=0A=0AConfiguration=0A*=A0 =A0 =A0 UK-DMC acquired a 150 Mbyte image.=0A*=
=A0 =A0 =A0 DTN bundling code default set to 80 Mbytes for proactive=0Afrag=
mentation=0ATests=0A1)=A0 =A0 =A0 Basic file download using existing techni=
que (GRC Saratoga)=0A2)=A0 =A0 =A0 Same file downloaded but treated as sing=
le bundle (DTN)=0A3)=A0 =A0 =A0 Same file download but using DTN proactive =
fragmentation with 80=0AMbytes preconfigured fragments.=0A3a)=A0 =A0 Somewh=
ere in the downloads we want to make sure we download the=0Asysconfig that =
has the MD5 payload checksum=0A4)=A0 =A0 =A0 Basic file download using SSTL=
 Saratoga=0A=0A=0A=0A=0AAugust 26th UK-DMC passes:=0A=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A07:50:11 =
Capture a 150 Mb image over South Africa using the DTN SSDR=0Acode.=0A=0A07=
:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).=0A=0A08:=
07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).=0A=0A09:45:13=
 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).=0A=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=
The following is preliminary results for the 8:07 pass:=0A=0A1) Successfull=
y downloaded syslog.=A0 No MD5 calculation present.=0A2) Downloaded 150 Mby=
te Image using GRC's implementation of Saratoga=0A3) Downloaded 70+byte DTN=
 header plus 150 Mbyte DTN payload=0A3) Downloaded 1st 80 Mbyte bundle frag=
ment=0A4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal =
at=0Aabout 2/3 complete. (Soft of a good thing in that we get to test 2 pas=
s=0Arecombining.)=0A5) Bundle and 1st fragment moved from SSTL Ground Stati=
on Bundle Agent=0Ato GRC Bundle Agent and GRC took custody of both full bun=
dle and 1st=0Abundle fragment. =0A=0A=0APost Processing:=0A=0AComputed MD5 =
on 150 Mbyte file=0A(Result is f434d0116a1f8b8e5a1cfff4a931812c)=0A=0AExtra=
cted payload from GRC bundle agent (full file) and checked MD5.=A0 It=0Amat=
ched full file MD5.=0A=0AChecked SSDR code and discovered MD5 telecommand h=
andling problem.=A0 Code=0Aassumes that images end in ".img"!=A0 That works=
 on Cisco Engineering=0Atestbed, but is not a valid assumption for UK-DMC. =
=0A=0A=0AThe following is preliminary results for the 9:45 pass:=0A=0A1) Do=
wnloaded 2nd 70 Mbyte bundle fragment=0A2) Downloaded syslog=0A3) SSTL down=
loaded image with SSTL's Saratoga Implementation=0A4) 2nd fragment moved fr=
om SSTL Ground Station Bundle Agent to GRC=0ABundle Agent. GRC took custody=
 of 2nd bundle fragment. =0A=0A=0APost Processing:=0A=0AComputed MD5 on 150=
 Mbyte file and payload portion of the full bundle=0Abrought Down by GRC Sa=
ratoga (Result is=0Af434d0116a1f8b8e5a1cfff4a931812c) matched.=0A=0AExtract=
ed payload from=A0 2 fragments and checked MD5.=A0 MD5 did not Match!=0A=0A=
- Inspected Bundle Fragments and noted header overwrite - index problem=0Ap=
uts 4 bytes of DTN header into the header.=0A- Inspected syslog and noted t=
hat build was April 11th which had the=0Aoverwrite problem discovered in la=
b testing in August. =0ALatest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bi=
n=0A=0APreliminary results/conclusions:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0ANeed to comp=
are MD5 with SSTL Saratoga Download to confirm good Bundle=0Aand file downl=
oads with GRC Saratoga implementation.=A0 Current MD5 is=0AEXTREMELY promis=
ing.=0AThis was done August 28th and comparison was correct.=A0 So File fro=
m=0A"file" download using GRC and SSTL Saratoga implementation matched as=
=0Adid bundle payload of GRC bundle download using Saratoga.=0A=0A=0A- Late=
st SSDR build was not used.=A0 April 11th build had fragmentation=0Aindex p=
roblem.=A0 That is why SSTL got error message when sending MD5=0Acommand (H=
ex 60) because the command did not exist in the April 11th=0Abuild.=0A=0A**=
*=A0 GRC already rewritten and compiled new SSDR code to run MD5=0Acalculat=
ions on files larger than 5 Mbytes.=A0 Yet to be will test in=0ACisco Engin=
eering Model testbed and once we confirm tests then we will=0Asend new code=
 to SSTL for flight tests.=A0 ***=0A=0A=0AAugust 27th UK-DMC Passes:=0A****=
 Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin=0A=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AThe image is scheduled for 08:=
27 UTC, again over South Africa.=0A=0AThe MD5 command is scheduled for 08:3=
5 UTC=0A=0A1st pass is between 08:44 and 08:57 UTC=0A=0A2nd pass is between=
 10:23 and 10:34 UTC=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=0A=0AThe first pass results are as follows:=0A=0A1) Downloaded=
 Syslog successfully=0A2) Downloaded Bundle Frag 1 (80 Mbyte).=A0 Bundle wa=
s received and=0Aforwarded to GRC Bundle Agent using DTN-2=0A3) Downloaded =
Bundle Frag 2 (77.5 Mbyte).=A0 Bundle was received and=0Aforwarded to GRC B=
undle Agent using DTN-2=0A4) Downloaded File using GRC Saratoga=0A4a) Lots =
of bursts of errors on initial download.=A0 Caused a fail of=0Atransfer as =
"inactivity timeout". Saratoga timed out. =0A4b) We restarted our Saratoga =
client - just for good measure.=0A4c) Restarted file transfer using Saratog=
a and successfully completed.=0A=0A=0APost Processing=0A=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A1) Combined and extracted file from two=
 bundle fragments.=A0 Calculated=0AChecksum=0A2) Ran MD5 checksum on file r=
esiding on SSTL Bundle Agent=0A=0AResults matched as shown below:=A0 Proves=
 fragmentation is working!=A0 This=0Aalso match checksum of SSTL file downl=
oad calculated August 28th.=0A=0A[weddy@bundling-SSTL ~]$ md5sum DU000d72pm=
=0Ace1a95dcb175ff21a2d3ec69315e1d7e=A0 DU000d72pm [weddy@Bundle-Master ~]$=
=0Amd5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e=0AAug272008=
-1_frag.dtn=0A=0A3) Copied image of Africa file, DU000d72pm, to GRC Bundle-=
Master and=0Aplaced on Web Server for SSTL post processing.=0A=0AThe follow=
ing is the terminal log from GRC Bundle Master:=0A=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=0A# Performed list command. Shows 1st fragment.# Currently Pending B=
undles=0A(1):=0A=A0 =A0 =A0 =A0 92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i =
length 80000000 #=0APerformed list command. Shows 1st fragment.# bundling-g=
rc dtn% bundle=0Alist Currently Pending Bundles (1):=0A=A0 =A0 =A0 =A0 9271=
5: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #=0APerformed list c=
ommand. Shows 1st and 2nd fragment.# bundling-grc dtn%=0Abundle list Curren=
tly Pending Bundles (2):=0A=A0 =A0 =A0 =A0 92715: dtn:uk-dmc/i -> dtn:bundl=
ing-grc1/i length 80000000=0A=A0 =A0 =A0 =A0 92716: dtn:uk-dmc/i -> dtn:bun=
dling-grc1/i length 77500550=0A=0A# Application Requested Bundle to File at=
 GRC Bundle Master and Bundle=0AFragments are combined.# bundling-grc dtn% =
[1219828317.602151=0A/dtn/bundle/daemon warning] event REGISTRATION_ADDED t=
ook 2335 ms to=0Aprocess=0A[1219828319.821315 /dtn/bundle/daemon warning] e=
vent BUNDLE_RECEIVED=0Atook 2218 ms to process bundle list Currently Pendin=
g Bundles (1):=0A=A0 =A0 =A0 =A0 92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i=
 length 157500550=0A=0Abundling-grc dtn% bundle list=0ACurrently Pending Bu=
ndles (0):=0A=0Abundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon war=
ning] event=0ABUNDLE_FREE took 2402 ms to process=0A[1219828324.915598 /tim=
er warning] timer thread running slow -- timer is=0A2313 msecs late=0A=0A# =
Performed list command. Shows bundles have been removed from Bundle=0AAgent=
# bundling-grc dtn% bundle list Currently Pending Bundles (0):=0A=0Abundlin=
g-grc dtn%=0A=0A=0AThe following was performed during pass 2, 10:23 UTC=0A=
=0AOrder of tests Pass 2:=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=0A1) Download Syslog successfully=0A2) Download Frag =
2 successfully=0A2a) Frag 2 was forwarded to GRC Bundle Master=0A2b) Copied=
 First Pass Frag-2 form temporary directory file to another=0Alocation on S=
STL Bundle Agent=0A2c) Did an MD5 comparison of the payload of Frag -2 from=
 the 1st and=0Asecond pass.=A0 MD5 results match.=A0 Conclusion is use of m=
ultiple ground=0Astations and proactive fragmentation will work.=0A=0A[wedd=
y@bundling-SSTL ~]$ md5sum *frag2*.dtn=0Ae849a9481cd7d9cc709555d7d5f0b012=
=A0 Aug272008-1_frag2.dtn=0Ae849a9481cd7d9cc709555d7d5f0b012=A0 Aug272008-2=
_frag2.dtn=0A=0A3) Download full Bundle using GRC Saratoga=0A3a) Similar to=
 pass 1, we received bursts of errors causing Saratoga to=0Atime out.=A0 Du=
e to the limited time pass, we terminated this test in=0Aorder to give SSTL=
 sufficient time to download the image file.=0A=0A4) Download Syslog succes=
sfully using GRC Saratoga=0A=0A4) Download File successfully using SSTL Sar=
atoga=0A=0A=0ASSTL=A0 FTPed their image downloads to GRC and we confirmed M=
D5 check on=0AAugust 28th.=0A=0A[weddy@Bundle-Master SSTL_Files]$ md5sum DU=
000d70pm=A0 =A0 =A0 =A0 =0A# file downloaded by SSTL Aug 26, 2008 pass=0Af4=
34d0116a1f8b8e5a1cfff4a931812c=A0 DU000d70pm=0A=0A[weddy@Bundle-Master SSTL=
_Files]$ md5sum DU000d72pm=A0 =A0 =A0 =A0 =0A# file downloaded by SSTL Aug =
27,2008 pass=0Ace1a95dcb175ff21a2d3ec69315e1d7e=A0 DU000d72pm=0A=0A=0A[wedd=
y@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img=A0 =A0 =0A# file downl=
oad as 2 fragments & xfer via DTN to bundle-master Aug 26,=0A2008 pass fb03=
c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img=A0 #=0AMD5 mismatch =
due to file corrupted from bug in old GRC generated SSDR=0Abinary.=0A=0A[we=
ddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img=A0 =A0 =0A# file dow=
nloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug=0A26, 2008 pass=
 f434d0116a1f8b8e5a1cfff4a931812c =0AAug262008-1_ufrag_dtn.img=A0 =0A# MD5 =
matches with file above that was downloaded by SSTL's Saratoga=0Aclient=0A=
=0A[weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn=A0 =A0 =A0 =A0 =A0 =
=A0 =0A# file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Au=
g=0A27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e =0AAug272008-1_frag.dtn=
=A0 =A0 =A0 =A0 =0A# MD5 matches with file above that was downloaded by SST=
L's Saratoga=0Aclient=0A=0A******************************************=0AReg=
arding GRC's Implementation of Saratoga=0A*********************************=
*********=0AWe have some ideas on why GRC's Saratoga may be timing out. We =
will look=0Aat that in the next few days, weeks.=A0 We didn't problems with=
 Saratoga=0Aon August 26th.=A0 That pass was at a very high elevation (almo=
st directly=0Aoverhead). SSTL will check the telemetry logs to see if there=
 was=0Ainterference or something.=A0 From the background conversations, we=
=0Abelieve that SSTL has their timeout settings longer GRC's for Saratoga.=
=0AAlso, we understand that SSTL's Saratoga can restart from where it left=
=0Aoff whereas GRC's restarts at the beginning.=A0 Finally, in order to=0Am=
inimize transmissions on the 9600 bps uplink, SSTL does some hole=0Acombini=
ng requests prior to asking for retransmissions - basically just=0Arequesti=
ng retransmission of a large segment rather than small gaps of=0Aholes.=A0 =
This is done to minimize the back-channel transmission otherwise=0Aone crea=
tes self congestion in the 9600 uplink.=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AI place the image that was extracted from the=
 DTN full bundle at the=0Afollowing location:=0A=0Ahttp://roland.grc.nasa.g=
ov/~ivancic/shared/DTN/=0A=0A.tiff is approximately 150 Mbytes=0A.pdf is 15=
0 kbytes=0AOther is raw unprocessed data. =0A=0A/Will Ivancic =0A=0A=0A____=
___________________________________________=0Adtn-interest mailing list=0Ad=
[email-masked]=0Ahttp://maillists.intel-research.=
net/mailman/listinfo/dtn-interest=0A=0A=0A=0A      
--0-1256310656-1221191186=:94127
Content-Type: text/html; charset=us-ascii

<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:tahoma, new york, times, serif;font-size:10pt"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>congargulations on the successfull results.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Keep it up.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Hadi.<BR></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: tahoma, new york, times, serif"><BR>
<DIV style="FONT-SIZE: 13px; FONT-FAMILY: arial, helvetica, sans-serif">----- Original Message ----<BR>From: "Ivancic, William D. (GRC-RHN0)" &lt;[email-masked]&gt;<BR>To: [email-masked]; [email-masked]<BR>Cc: [email-masked]<BR>Sent: Thursday, September 11, 2008 8:51:09 PM<BR>Subject: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results<BR><BR>First, I would like to thank both the NASA and SSTL procurement officers<BR>for their patience, professionalism and diligence as these results would<BR>not have been possible without their hard work.<BR><BR>UK-DMC satellite first to transfer sensor data from space using 'bundle'<BR>protocol<BR><A href="http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254" target=_blank>http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254</A><BR><BR><BR>"Use of the Delay-Tolerant Networking Bundle Protocol from Space"<BR>Lloyd Wood,
 Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris<BR>Jackson, Alex da Silva Curiel.<BR><BR><A href="http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/" target=_blank>http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/</A><BR><A href="http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#" target=_blank>http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#</A><BR>iac-2008<BR><BR><BR>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>+<BR><BR>The following is a summary of the flight tests and test results for DTN<BR>flight testing using the UK-DMC satellite.&nbsp; Download was to SSTL's<BR>ground station in Guildford, England.&nbsp; Uplink is 9600 bps, Downlink is<BR>8.1 Mbps.<BR><BR>These tests are a repeat of the January testing reported at the IRTF<BR>meeting at IETF-71 in March 2008 and at the NASA Earth Science<BR>Technology Conference in June 2008.&nbsp;
 See:<BR><BR><A href="http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd" target=_blank>http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd</A><BR>f<BR><A href="http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT" target=_blank>http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT</A><BR>F_DTN.ppt<BR><BR><BR>Test Plan:<BR>==========<BR>The image should be taken with the MD5 checksum enabled. <BR><BR>DTN Test Plan for Initial DTN Testing using the UK-DMC Goal<BR>1)&nbsp; &nbsp; &nbsp; Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground<BR>Station<BR>2)&nbsp; &nbsp; &nbsp; Demonstrate that DTN code and general SSTL code can coexist<BR>without effecting normal SSTL Operations<BR><BR>Configuration<BR>*&nbsp; &nbsp; &nbsp; UK-DMC acquired a 150 Mbyte image.<BR>*&nbsp; &nbsp; &nbsp; DTN bundling code default set to 80 Mbytes for
 proactive<BR>fragmentation<BR>Tests<BR>1)&nbsp; &nbsp; &nbsp; Basic file download using existing technique (GRC Saratoga)<BR>2)&nbsp; &nbsp; &nbsp; Same file downloaded but treated as single bundle (DTN)<BR>3)&nbsp; &nbsp; &nbsp; Same file download but using DTN proactive fragmentation with 80<BR>Mbytes preconfigured fragments.<BR>3a)&nbsp; &nbsp; Somewhere in the downloads we want to make sure we download the<BR>sysconfig that has the MD5 payload checksum<BR>4)&nbsp; &nbsp; &nbsp; Basic file download using SSTL Saratoga<BR><BR><BR><BR><BR>August 26th UK-DMC passes:<BR>============================<BR>07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR<BR>code.<BR><BR>07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).<BR><BR>08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).<BR><BR>09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).<BR>============================<BR><BR>The following is
 preliminary results for the 8:07 pass:<BR><BR>1) Successfully downloaded syslog.&nbsp; No MD5 calculation present.<BR>2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga<BR>3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload<BR>3) Downloaded 1st 80 Mbyte bundle fragment<BR>4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at<BR>about 2/3 complete. (Soft of a good thing in that we get to test 2 pass<BR>recombining.)<BR>5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent<BR>to GRC Bundle Agent and GRC took custody of both full bundle and 1st<BR>bundle fragment. <BR><BR><BR>Post Processing:<BR><BR>Computed MD5 on 150 Mbyte file<BR>(Result is f434d0116a1f8b8e5a1cfff4a931812c)<BR><BR>Extracted payload from GRC bundle agent (full file) and checked MD5.&nbsp; It<BR>matched full file MD5.<BR><BR>Checked SSDR code and discovered MD5 telecommand handling problem.&nbsp; Code<BR>assumes that images end
 in ".img"!&nbsp; That works on Cisco Engineering<BR>testbed, but is not a valid assumption for UK-DMC. <BR><BR><BR>The following is preliminary results for the 9:45 pass:<BR><BR>1) Downloaded 2nd 70 Mbyte bundle fragment<BR>2) Downloaded syslog<BR>3) SSTL downloaded image with SSTL's Saratoga Implementation<BR>4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC<BR>Bundle Agent. GRC took custody of 2nd bundle fragment. <BR><BR><BR>Post Processing:<BR><BR>Computed MD5 on 150 Mbyte file and payload portion of the full bundle<BR>brought Down by GRC Saratoga (Result is<BR>f434d0116a1f8b8e5a1cfff4a931812c) matched.<BR><BR>Extracted payload from&nbsp; 2 fragments and checked MD5.&nbsp; MD5 did not Match!<BR><BR>- Inspected Bundle Fragments and noted header overwrite - index problem<BR>puts 4 bytes of DTN header into the header.<BR>- Inspected syslog and noted that build was April 11th which had the<BR>overwrite problem discovered in lab testing
 in August. <BR>Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin<BR><BR>Preliminary results/conclusions:<BR>===============================<BR>Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle<BR>and file downloads with GRC Saratoga implementation.&nbsp; Current MD5 is<BR>EXTREMELY promising.<BR>This was done August 28th and comparison was correct.&nbsp; So File from<BR>"file" download using GRC and SSTL Saratoga implementation matched as<BR>did bundle payload of GRC bundle download using Saratoga.<BR><BR><BR>- Latest SSDR build was not used.&nbsp; April 11th build had fragmentation<BR>index problem.&nbsp; That is why SSTL got error message when sending MD5<BR>command (Hex 60) because the command did not exist in the April 11th<BR>build.<BR><BR>***&nbsp; GRC already rewritten and compiled new SSDR code to run MD5<BR>calculations on files larger than 5 Mbytes.&nbsp; Yet to be will test in<BR>Cisco Engineering Model testbed and
 once we confirm tests then we will<BR>send new code to SSTL for flight tests.&nbsp; ***<BR><BR><BR>August 27th UK-DMC Passes:<BR>**** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin<BR>===================================================================<BR>The image is scheduled for 08:27 UTC, again over South Africa.<BR><BR>The MD5 command is scheduled for 08:35 UTC<BR><BR>1st pass is between 08:44 and 08:57 UTC<BR><BR>2nd pass is between 10:23 and 10:34 UTC<BR>==============================================<BR><BR>The first pass results are as follows:<BR><BR>1) Downloaded Syslog successfully<BR>2) Downloaded Bundle Frag 1 (80 Mbyte).&nbsp; Bundle was received and<BR>forwarded to GRC Bundle Agent using DTN-2<BR>3) Downloaded Bundle Frag 2 (77.5 Mbyte).&nbsp; Bundle was received and<BR>forwarded to GRC Bundle Agent using DTN-2<BR>4) Downloaded File using GRC Saratoga<BR>4a) Lots of bursts of errors on initial download.&nbsp; Caused a fail
 of<BR>transfer as "inactivity timeout". Saratoga timed out. <BR>4b) We restarted our Saratoga client - just for good measure.<BR>4c) Restarted file transfer using Saratoga and successfully completed.<BR><BR><BR>Post Processing<BR>=================<BR>1) Combined and extracted file from two bundle fragments.&nbsp; Calculated<BR>Checksum<BR>2) Ran MD5 checksum on file residing on SSTL Bundle Agent<BR><BR>Results matched as shown below:&nbsp; Proves fragmentation is working!&nbsp; This<BR>also match checksum of SSTL file download calculated August 28th.<BR><BR>[weddy@bundling-SSTL ~]$ md5sum DU000d72pm<BR>ce1a95dcb175ff21a2d3ec69315e1d7e&nbsp; DU000d72pm [weddy@Bundle-Master ~]$<BR>md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e<BR>Aug272008-1_frag.dtn<BR><BR>3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and<BR>placed on Web Server for SSTL post processing.<BR><BR>The following is the terminal log from GRC Bundle
 Master:<BR>============================================================<BR># Performed list command. Shows 1st fragment.# Currently Pending Bundles<BR>(1):<BR>&nbsp; &nbsp; &nbsp; &nbsp; 92715: dtn:uk-dmc/i -&gt; dtn:bundling-grc1/i length 80000000 #<BR>Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle<BR>list Currently Pending Bundles (1):<BR>&nbsp; &nbsp; &nbsp; &nbsp; 92715: dtn:uk-dmc/i -&gt; dtn:bundling-grc1/i length 80000000 #<BR>Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%<BR>bundle list Currently Pending Bundles (2):<BR>&nbsp; &nbsp; &nbsp; &nbsp; 92715: dtn:uk-dmc/i -&gt; dtn:bundling-grc1/i length 80000000<BR>&nbsp; &nbsp; &nbsp; &nbsp; 92716: dtn:uk-dmc/i -&gt; dtn:bundling-grc1/i length 77500550<BR><BR># Application Requested Bundle to File at GRC Bundle Master and Bundle<BR>Fragments are combined.# bundling-grc dtn% [1219828317.602151<BR>/dtn/bundle/daemon warning] event REGISTRATION_ADDED took
 2335 ms to<BR>process<BR>[1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED<BR>took 2218 ms to process bundle list Currently Pending Bundles (1):<BR>&nbsp; &nbsp; &nbsp; &nbsp; 92717: dtn:uk-dmc/i -&gt; dtn:bundling-grc1/i length 157500550<BR><BR>bundling-grc dtn% bundle list<BR>Currently Pending Bundles (0):<BR><BR>bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event<BR>BUNDLE_FREE took 2402 ms to process<BR>[1219828324.915598 /timer warning] timer thread running slow -- timer is<BR>2313 msecs late<BR><BR># Performed list command. Shows bundles have been removed from Bundle<BR>Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):<BR><BR>bundling-grc dtn%<BR><BR><BR>The following was performed during pass 2, 10:23 UTC<BR><BR>Order of tests Pass 2:<BR>======================<BR>1) Download Syslog successfully<BR>2) Download Frag 2 successfully<BR>2a) Frag 2 was forwarded to GRC Bundle Master<BR>2b) Copied
 First Pass Frag-2 form temporary directory file to another<BR>location on SSTL Bundle Agent<BR>2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and<BR>second pass.&nbsp; MD5 results match.&nbsp; Conclusion is use of multiple ground<BR>stations and proactive fragmentation will work.<BR><BR>[weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn<BR>e849a9481cd7d9cc709555d7d5f0b012&nbsp; Aug272008-1_frag2.dtn<BR>e849a9481cd7d9cc709555d7d5f0b012&nbsp; Aug272008-2_frag2.dtn<BR><BR>3) Download full Bundle using GRC Saratoga<BR>3a) Similar to pass 1, we received bursts of errors causing Saratoga to<BR>time out.&nbsp; Due to the limited time pass, we terminated this test in<BR>order to give SSTL sufficient time to download the image file.<BR><BR>4) Download Syslog successfully using GRC Saratoga<BR><BR>4) Download File successfully using SSTL Saratoga<BR><BR><BR>SSTL&nbsp; FTPed their image downloads to GRC and we confirmed MD5 check on<BR>August
 28th.<BR><BR>[weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm&nbsp; &nbsp; &nbsp; &nbsp; <BR># file downloaded by SSTL Aug 26, 2008 pass<BR>f434d0116a1f8b8e5a1cfff4a931812c&nbsp; DU000d70pm<BR><BR>[weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm&nbsp; &nbsp; &nbsp; &nbsp; <BR># file downloaded by SSTL Aug 27,2008 pass<BR>ce1a95dcb175ff21a2d3ec69315e1d7e&nbsp; DU000d72pm<BR><BR><BR>[weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img&nbsp; &nbsp; <BR># file download as 2 fragments &amp; xfer via DTN to bundle-master Aug 26,<BR>2008 pass fb03c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img&nbsp; #<BR>MD5 mismatch due to file corrupted from bug in old GRC generated SSDR<BR>binary.<BR><BR>[weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img&nbsp; &nbsp; <BR># file downloaded as 1 DTN bundle &amp; xfer via DTN to Bundle-Master Aug<BR>26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c <BR>Aug262008-1_ufrag_dtn.img&nbsp; <BR># MD5 matches
 with file above that was downloaded by SSTL's Saratoga<BR>client<BR><BR>[weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <BR># file downloaded as 1 DTN bundle &amp; xfer via DTN to Bundle-Master Aug<BR>27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e <BR>Aug272008-1_frag.dtn&nbsp; &nbsp; &nbsp; &nbsp; <BR># MD5 matches with file above that was downloaded by SSTL's Saratoga<BR>client<BR><BR>******************************************<BR>Regarding GRC's Implementation of Saratoga<BR>******************************************<BR>We have some ideas on why GRC's Saratoga may be timing out. We will look<BR>at that in the next few days, weeks.&nbsp; We didn't problems with Saratoga<BR>on August 26th.&nbsp; That pass was at a very high elevation (almost directly<BR>overhead). SSTL will check the telemetry logs to see if there was<BR>interference or something.&nbsp; From the background conversations, we<BR>believe that
 SSTL has their timeout settings longer GRC's for Saratoga.<BR>Also, we understand that SSTL's Saratoga can restart from where it left<BR>off whereas GRC's restarts at the beginning.&nbsp; Finally, in order to<BR>minimize transmissions on the 9600 bps uplink, SSTL does some hole<BR>combining requests prior to asking for retransmissions - basically just<BR>requesting retransmission of a large segment rather than small gaps of<BR>holes.&nbsp; This is done to minimize the back-channel transmission otherwise<BR>one creates self congestion in the 9600 uplink.<BR><BR><BR>===========================================<BR>I place the image that was extracted from the DTN full bundle at the<BR>following location:<BR><BR><A href="http://roland.grc.nasa.gov/~ivancic/shared/DTN/" target=_blank>http://roland.grc.nasa.gov/~ivancic/shared/DTN/</A><BR><BR>.tiff is approximately 150 Mbytes<BR>.pdf is 150 kbytes<BR>Other is raw unprocessed data. <BR><BR>/Will Ivancic
 <BR><BR><BR>_______________________________________________<BR>dtn-interest mailing list<BR><A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR><A href="http://maillists.intel-research.net/mailman/listinfo/dtn-interest" target=_blank>http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><BR></DIV></DIV></div><br>

      </body></html>
--0-1256310656-1221191186=:94127--

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 11 Sep 2008 13:37:30 -0700
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

congrats.  I assume we can get a briefing on this at the next IETF?  
(nudge, nudge)
- K

On Sep 11, 2008, at Sep 118:51 AMPDT, Ivancic, William D. (GRC-RHN0)  
wrote:

> First, I would like to thank both the NASA and SSTL procurement  
> officers
> for their patience, professionalism and diligence as these results  
> would
> not have been possible without their hard work.
>
> UK-DMC satellite first to transfer sensor data from space using  
> 'bundle'
> protocol
> http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
>
>
> "Use of the Delay-Tolerant Networking Bundle Protocol from Space"
> Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
> Jackson, Alex da Silva Curiel.
>
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
> iac-2008
>
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> +++
> +
>
> The following is a summary of the flight tests and test results for  
> DTN
> flight testing using the UK-DMC satellite.  Download was to SSTL's
> ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
> 8.1 Mbps.
>
> These tests are a repeat of the January testing reported at the IRTF
> meeting at IETF-71 in March 2008 and at the NASA Earth Science
> Technology Conference in June 2008.  See:
>
> http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
> f
> http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
> F_DTN.ppt
>
>
> Test Plan:
> ==========
> The image should be taken with the MD5 checksum enabled.
>
> DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
> 1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
> Station
> 2)      Demonstrate that DTN code and general SSTL code can coexist
> without effecting normal SSTL Operations
>
> Configuration
> *       UK-DMC acquired a 150 Mbyte image.
> *       DTN bundling code default set to 80 Mbytes for proactive
> fragmentation
> Tests
> 1)      Basic file download using existing technique (GRC Saratoga)
> 2)      Same file downloaded but treated as single bundle (DTN)
> 3)      Same file download but using DTN proactive fragmentation  
> with 80
> Mbytes preconfigured fragments.
> 3a)     Somewhere in the downloads we want to make sure we download  
> the
> sysconfig that has the MD5 payload checksum
> 4)      Basic file download using SSTL Saratoga
>
>
>
>
> August 26th UK-DMC passes:
> ============================
> 07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR
> code.
>
> 07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).
>
> 08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).
>
> 09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).
> ============================
>
> The following is preliminary results for the 8:07 pass:
>
> 1) Successfully downloaded syslog.  No MD5 calculation present.
> 2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga
> 3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload
> 3) Downloaded 1st 80 Mbyte bundle fragment
> 4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at
> about 2/3 complete. (Soft of a good thing in that we get to test 2  
> pass
> recombining.)
> 5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent
> to GRC Bundle Agent and GRC took custody of both full bundle and 1st
> bundle fragment.
>
>
> Post Processing:
>
> Computed MD5 on 150 Mbyte file
> (Result is f434d0116a1f8b8e5a1cfff4a931812c)
>
> Extracted payload from GRC bundle agent (full file) and checked  
> MD5.  It
> matched full file MD5.
>
> Checked SSDR code and discovered MD5 telecommand handling problem.   
> Code
> assumes that images end in ".img"!  That works on Cisco Engineering
> testbed, but is not a valid assumption for UK-DMC.
>
>
> The following is preliminary results for the 9:45 pass:
>
> 1) Downloaded 2nd 70 Mbyte bundle fragment
> 2) Downloaded syslog
> 3) SSTL downloaded image with SSTL's Saratoga Implementation
> 4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC
> Bundle Agent. GRC took custody of 2nd bundle fragment.
>
>
> Post Processing:
>
> Computed MD5 on 150 Mbyte file and payload portion of the full bundle
> brought Down by GRC Saratoga (Result is
> f434d0116a1f8b8e5a1cfff4a931812c) matched.
>
> Extracted payload from  2 fragments and checked MD5.  MD5 did not  
> Match!
>
> - Inspected Bundle Fragments and noted header overwrite - index  
> problem
> puts 4 bytes of DTN header into the header.
> - Inspected syslog and noted that build was April 11th which had the
> overwrite problem discovered in lab testing in August.
> Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin
>
> Preliminary results/conclusions:
> ===============================
> Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle
> and file downloads with GRC Saratoga implementation.  Current MD5 is
> EXTREMELY promising.
> This was done August 28th and comparison was correct.  So File from
> "file" download using GRC and SSTL Saratoga implementation matched as
> did bundle payload of GRC bundle download using Saratoga.
>
>
> - Latest SSDR build was not used.  April 11th build had fragmentation
> index problem.  That is why SSTL got error message when sending MD5
> command (Hex 60) because the command did not exist in the April 11th
> build.
>
> ***  GRC already rewritten and compiled new SSDR code to run MD5
> calculations on files larger than 5 Mbytes.  Yet to be will test in
> Cisco Engineering Model testbed and once we confirm tests then we will
> send new code to SSTL for flight tests.  ***
>
>
> August 27th UK-DMC Passes:
> **** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin
> ===================================================================
> The image is scheduled for 08:27 UTC, again over South Africa.
>
> The MD5 command is scheduled for 08:35 UTC
>
> 1st pass is between 08:44 and 08:57 UTC
>
> 2nd pass is between 10:23 and 10:34 UTC
> ==============================================
>
> The first pass results are as follows:
>
> 1) Downloaded Syslog successfully
> 2) Downloaded Bundle Frag 1 (80 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 3) Downloaded Bundle Frag 2 (77.5 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 4) Downloaded File using GRC Saratoga
> 4a) Lots of bursts of errors on initial download.  Caused a fail of
> transfer as "inactivity timeout". Saratoga timed out.
> 4b) We restarted our Saratoga client - just for good measure.
> 4c) Restarted file transfer using Saratoga and successfully completed.
>
>
> Post Processing
> =================
> 1) Combined and extracted file from two bundle fragments.  Calculated
> Checksum
> 2) Ran MD5 checksum on file residing on SSTL Bundle Agent
>
> Results matched as shown below:  Proves fragmentation is working!   
> This
> also match checksum of SSTL file download calculated August 28th.
>
> [weddy@bundling-SSTL ~]$ md5sum DU000d72pm
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm [weddy@Bundle-Master ~]$
> md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
>
> 3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and
> placed on Web Server for SSTL post processing.
>
> The following is the terminal log from GRC Bundle Master:
> ============================================================
> # Performed list command. Shows 1st fragment.# Currently Pending  
> Bundles
> (1):
>        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle
> list Currently Pending Bundles (1):
>        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%
> bundle list Currently Pending Bundles (2):
>        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000
>        92716: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 77500550
>
> # Application Requested Bundle to File at GRC Bundle Master and Bundle
> Fragments are combined.# bundling-grc dtn% [1219828317.602151
> /dtn/bundle/daemon warning] event REGISTRATION_ADDED took 2335 ms to
> process
> [1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED
> took 2218 ms to process bundle list Currently Pending Bundles (1):
>        92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 157500550
>
> bundling-grc dtn% bundle list
> Currently Pending Bundles (0):
>
> bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event
> BUNDLE_FREE took 2402 ms to process
> [1219828324.915598 /timer warning] timer thread running slow --  
> timer is
> 2313 msecs late
>
> # Performed list command. Shows bundles have been removed from Bundle
> Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):
>
> bundling-grc dtn%
>
>
> The following was performed during pass 2, 10:23 UTC
>
> Order of tests Pass 2:
> ======================
> 1) Download Syslog successfully
> 2) Download Frag 2 successfully
> 2a) Frag 2 was forwarded to GRC Bundle Master
> 2b) Copied First Pass Frag-2 form temporary directory file to another
> location on SSTL Bundle Agent
> 2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and
> second pass.  MD5 results match.  Conclusion is use of multiple ground
> stations and proactive fragmentation will work.
>
> [weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-1_frag2.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-2_frag2.dtn
>
> 3) Download full Bundle using GRC Saratoga
> 3a) Similar to pass 1, we received bursts of errors causing Saratoga  
> to
> time out.  Due to the limited time pass, we terminated this test in
> order to give SSTL sufficient time to download the image file.
>
> 4) Download Syslog successfully using GRC Saratoga
>
> 4) Download File successfully using SSTL Saratoga
>
>
> SSTL  FTPed their image downloads to GRC and we confirmed MD5 check on
> August 28th.
>
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm
> # file downloaded by SSTL Aug 26, 2008 pass
> f434d0116a1f8b8e5a1cfff4a931812c  DU000d70pm
>
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm
> # file downloaded by SSTL Aug 27,2008 pass
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm
>
>
> [weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img
> # file download as 2 fragments & xfer via DTN to bundle-master Aug 26,
> 2008 pass fb03c9f16c60eb486ebc45b74974cb0a  
> Aug262008-12_frag_dtn.img  #
> MD5 mismatch due to file corrupted from bug in old GRC generated SSDR
> binary.
>
> [weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c
> Aug262008-1_ufrag_dtn.img
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
>
> [weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
>
> ******************************************
> Regarding GRC's Implementation of Saratoga
> ******************************************
> We have some ideas on why GRC's Saratoga may be timing out. We will  
> look
> at that in the next few days, weeks.  We didn't problems with Saratoga
> on August 26th.  That pass was at a very high elevation (almost  
> directly
> overhead). SSTL will check the telemetry logs to see if there was
> interference or something.  From the background conversations, we
> believe that SSTL has their timeout settings longer GRC's for  
> Saratoga.
> Also, we understand that SSTL's Saratoga can restart from where it  
> left
> off whereas GRC's restarts at the beginning.  Finally, in order to
> minimize transmissions on the 9600 bps uplink, SSTL does some hole
> combining requests prior to asking for retransmissions - basically  
> just
> requesting retransmission of a large segment rather than small gaps of
> holes.  This is done to minimize the back-channel transmission  
> otherwise
> one creates self congestion in the 9600 uplink.
>
>
> ===========================================
> I place the image that was extracted from the DTN full bundle at the
> following location:
>
> http://roland.grc.nasa.gov/~ivancic/shared/DTN/
>
> .tiff is approximately 150 Mbytes
> .pdf is 150 kbytes
> Other is raw unprocessed data.
>
> /Will Ivancic
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Content-class: urn:content-classes:message
Date: Thu, 11 Sep 2008 14:36:46 -0400
From: "Weiss, Howard" <[email-masked]>
To: "Ivancic, William D. \(GRC-RHN0\)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] [Sis-dtn] 1st Successful Bundling Tests from Space - TechnicalResults

Will

My goodness - you mean it *really* does work???  :-)

Congratulations to you and the entire team.

regards

Howie

> -----Original Message-----
> From: [email-masked] [mailto:sis-dtn-
> [email-masked]] On Behalf Of Ivancic, William D. (GRC-RHN0)
> Sent: Thursday, September 11, 2008 11:51 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sis-dtn] 1st Successful Bundling Tests from Space -
> TechnicalResults
> 
> First, I would like to thank both the NASA and SSTL procurement
> officers
> for their patience, professionalism and diligence as these results
> would
> not have been possible without their hard work.
> 
> UK-DMC satellite first to transfer sensor data from space using
> 'bundle'
> protocol
> http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
> 
> 
> "Use of the Delay-Tolerant Networking Bundle Protocol from Space"
> Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
> Jackson, Alex da Silva Curiel.
> 
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
>
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html
> #
> iac-2008
> 
> 
>
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +
> +
> 
> The following is a summary of the flight tests and test results for
DTN
> flight testing using the UK-DMC satellite.  Download was to SSTL's
> ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
> 8.1 Mbps.
> 
> These tests are a repeat of the January testing reported at the IRTF
> meeting at IETF-71 in March 2008 and at the NASA Earth Science
> Technology Conference in June 2008.  See:
> 
>
http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.p
> d
> f
>
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IR
> T
> F_DTN.ppt
> 
> 
> Test Plan:
> ==========
> The image should be taken with the MD5 checksum enabled.
> 
> DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
> 1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
> Station
> 2)      Demonstrate that DTN code and general SSTL code can coexist
> without effecting normal SSTL Operations
> 
> Configuration
> *       UK-DMC acquired a 150 Mbyte image.
> *       DTN bundling code default set to 80 Mbytes for proactive
> fragmentation
> Tests
> 1)      Basic file download using existing technique (GRC Saratoga)
> 2)      Same file downloaded but treated as single bundle (DTN)
> 3)      Same file download but using DTN proactive fragmentation with
> 80
> Mbytes preconfigured fragments.
> 3a)     Somewhere in the downloads we want to make sure we download
the
> sysconfig that has the MD5 payload checksum
> 4)      Basic file download using SSTL Saratoga
> 
> 
> 
> 
> August 26th UK-DMC passes:
> ============================
> 07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR
> code.
> 
> 07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).
> 
> 08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).
> 
> 09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).
> ============================
> 
> The following is preliminary results for the 8:07 pass:
> 
> 1) Successfully downloaded syslog.  No MD5 calculation present.
> 2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga
> 3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload
> 3) Downloaded 1st 80 Mbyte bundle fragment
> 4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at
> about 2/3 complete. (Soft of a good thing in that we get to test 2
pass
> recombining.)
> 5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent
> to GRC Bundle Agent and GRC took custody of both full bundle and 1st
> bundle fragment.
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file
> (Result is f434d0116a1f8b8e5a1cfff4a931812c)
> 
> Extracted payload from GRC bundle agent (full file) and checked MD5.
> It
> matched full file MD5.
> 
> Checked SSDR code and discovered MD5 telecommand handling problem.
> Code
> assumes that images end in ".img"!  That works on Cisco Engineering
> testbed, but is not a valid assumption for UK-DMC.
> 
> 
> The following is preliminary results for the 9:45 pass:
> 
> 1) Downloaded 2nd 70 Mbyte bundle fragment
> 2) Downloaded syslog
> 3) SSTL downloaded image with SSTL's Saratoga Implementation
> 4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC
> Bundle Agent. GRC took custody of 2nd bundle fragment.
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file and payload portion of the full bundle
> brought Down by GRC Saratoga (Result is
> f434d0116a1f8b8e5a1cfff4a931812c) matched.
> 
> Extracted payload from  2 fragments and checked MD5.  MD5 did not
> Match!
> 
> - Inspected Bundle Fragments and noted header overwrite - index
problem
> puts 4 bytes of DTN header into the header.
> - Inspected syslog and noted that build was April 11th which had the
> overwrite problem discovered in lab testing in August.
>  Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin
> 
> Preliminary results/conclusions:
> ===============================
> Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle
> and file downloads with GRC Saratoga implementation.  Current MD5 is
> EXTREMELY promising.
> This was done August 28th and comparison was correct.  So File from
> "file" download using GRC and SSTL Saratoga implementation matched as
> did bundle payload of GRC bundle download using Saratoga.
> 
> 
> - Latest SSDR build was not used.  April 11th build had fragmentation
> index problem.  That is why SSTL got error message when sending MD5
> command (Hex 60) because the command did not exist in the April 11th
> build.
> 
> ***  GRC already rewritten and compiled new SSDR code to run MD5
> calculations on files larger than 5 Mbytes.  Yet to be will test in
> Cisco Engineering Model testbed and once we confirm tests then we will
> send new code to SSTL for flight tests.  ***
> 
> 
> August 27th UK-DMC Passes:
> **** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin
> ===================================================================
> The image is scheduled for 08:27 UTC, again over South Africa.
> 
> The MD5 command is scheduled for 08:35 UTC
> 
> 1st pass is between 08:44 and 08:57 UTC
> 
> 2nd pass is between 10:23 and 10:34 UTC
> ==============================================
> 
> The first pass results are as follows:
> 
> 1) Downloaded Syslog successfully
> 2) Downloaded Bundle Frag 1 (80 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 3) Downloaded Bundle Frag 2 (77.5 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 4) Downloaded File using GRC Saratoga
> 4a) Lots of bursts of errors on initial download.  Caused a fail of
> transfer as "inactivity timeout". Saratoga timed out.
> 4b) We restarted our Saratoga client - just for good measure.
> 4c) Restarted file transfer using Saratoga and successfully completed.
> 
> 
> Post Processing
> =================
> 1) Combined and extracted file from two bundle fragments.  Calculated
> Checksum
> 2) Ran MD5 checksum on file residing on SSTL Bundle Agent
> 
> Results matched as shown below:  Proves fragmentation is working!
This
> also match checksum of SSTL file download calculated August 28th.
> 
> [weddy@bundling-SSTL ~]$ md5sum DU000d72pm
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm [weddy@Bundle-Master ~]$
> md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
> 
> 3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and
> placed on Web Server for SSTL post processing.
> 
> The following is the terminal log from GRC Bundle Master:
> ============================================================
> # Performed list command. Shows 1st fragment.# Currently Pending
> Bundles
> (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle
> list Currently Pending Bundles (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%
> bundle list Currently Pending Bundles (2):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000
>         92716: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 77500550
> 
> # Application Requested Bundle to File at GRC Bundle Master and Bundle
> Fragments are combined.# bundling-grc dtn% [1219828317.602151
> /dtn/bundle/daemon warning] event REGISTRATION_ADDED took 2335 ms to
> process
> [1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED
> took 2218 ms to process bundle list Currently Pending Bundles (1):
>         92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 157500550
> 
> bundling-grc dtn% bundle list
> Currently Pending Bundles (0):
> 
> bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event
> BUNDLE_FREE took 2402 ms to process
> [1219828324.915598 /timer warning] timer thread running slow -- timer
> is
> 2313 msecs late
> 
> # Performed list command. Shows bundles have been removed from Bundle
> Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):
> 
> bundling-grc dtn%
> 
> 
> The following was performed during pass 2, 10:23 UTC
> 
> Order of tests Pass 2:
> ======================
> 1) Download Syslog successfully
> 2) Download Frag 2 successfully
> 2a) Frag 2 was forwarded to GRC Bundle Master
> 2b) Copied First Pass Frag-2 form temporary directory file to another
> location on SSTL Bundle Agent
> 2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and
> second pass.  MD5 results match.  Conclusion is use of multiple ground
> stations and proactive fragmentation will work.
> 
> [weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-1_frag2.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-2_frag2.dtn
> 
> 3) Download full Bundle using GRC Saratoga
> 3a) Similar to pass 1, we received bursts of errors causing Saratoga
to
> time out.  Due to the limited time pass, we terminated this test in
> order to give SSTL sufficient time to download the image file.
> 
> 4) Download Syslog successfully using GRC Saratoga
> 
> 4) Download File successfully using SSTL Saratoga
> 
> 
> SSTL  FTPed their image downloads to GRC and we confirmed MD5 check on
> August 28th.
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm
> # file downloaded by SSTL Aug 26, 2008 pass
> f434d0116a1f8b8e5a1cfff4a931812c  DU000d70pm
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm
> # file downloaded by SSTL Aug 27,2008 pass
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm
> 
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img
> # file download as 2 fragments & xfer via DTN to bundle-master Aug 26,
> 2008 pass fb03c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img
#
> MD5 mismatch due to file corrupted from bug in old GRC generated SSDR
> binary.
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c
> Aug262008-1_ufrag_dtn.img
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> [weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> ******************************************
> Regarding GRC's Implementation of Saratoga
> ******************************************
> We have some ideas on why GRC's Saratoga may be timing out. We will
> look
> at that in the next few days, weeks.  We didn't problems with Saratoga
> on August 26th.  That pass was at a very high elevation (almost
> directly
> overhead). SSTL will check the telemetry logs to see if there was
> interference or something.  From the background conversations, we
> believe that SSTL has their timeout settings longer GRC's for
Saratoga.
> Also, we understand that SSTL's Saratoga can restart from where it
left
> off whereas GRC's restarts at the beginning.  Finally, in order to
> minimize transmissions on the 9600 bps uplink, SSTL does some hole
> combining requests prior to asking for retransmissions - basically
just
> requesting retransmission of a large segment rather than small gaps of
> holes.  This is done to minimize the back-channel transmission
> otherwise
> one creates self congestion in the 9600 uplink.
> 
> 
> ===========================================
> I place the image that was extracted from the DTN full bundle at the
> following location:
> 
> http://roland.grc.nasa.gov/~ivancic/shared/DTN/
> 
> .tiff is approximately 150 Mbytes
> .pdf is 150 kbytes
> Other is raw unprocessed data.
> 
> /Will Ivancic
> 
> 
> _______________________________________________
> Sis-dtn mailing list
> [email-masked]
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn

From: Rajesh Krishnan <[email-masked]>
Date: Thu, 11 Sep 2008 13:38:45 -0400
Importance: normal
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

Congratulations on this milestone!

Best Regards,
Rajesh Krishnan

-----Original Message-----
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]
Sent: 9/11/08 11:51 AM
Subject: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

First, I would like to thank both the NASA and SSTL procurement officers
for their patience, professionalism and diligence as these results would
not have been possible without their hard work.

UK-DMC satellite first to transfer sensor data from space using 'bundle'
protocol
http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254

"Use of the Delay-Tolerant Networking Bundle Protocol from Space"
Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
Jackson, Alex da Silva Curiel.

http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
iac-2008

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+

The following is a summary of the flight tests and test results for DTN
flight testing using the UK-DMC satellite.  Download was to SSTL's
ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
8.1 Mbps.

These tests are a repeat of the January testing reported at the IRTF
meeting at IETF-71 in March 2008 and at the NASA Earth Science
Technology Conference in June 2008.  See:

http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
f
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
F_DTN.ppt

Test Plan:
==========
The image should be taken with the MD5 checksum enabled. 

DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
Station
2)      Demonstrate that DTN code and general SSTL code can coexist
without effecting normal SSTL Operations

Configuration
*       UK-DMC acquired a 150 Mbyte image.
*       DTN bundling code default set to 80 Mbytes for proactive
fragmentation
Tests
1)      Basic file download using existing technique (GRC Saratoga)
2)      Same file downloaded but treated as single bundle (DTN)
3)      Same file download but using DTN proactive fragmentation with 80
Mbytes preconfigured fragments.
3a) 

Date: Thu, 11 Sep 2008 10:07:47 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] [nasa-dtn] 1st Successful Bundling Tests from Space - Technical Results

Ivancic, William D. (GRC-RHN0) wrote:
> First, I would like to thank both the NASA and SSTL procurement officers
> for their patience, professionalism and diligence as these results would
> not have been possible without their hard work.
>
> UK-DMC satellite first to transfer sensor data from space using 'bundle'
> protocol
> http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
>
>
> "Use of the Delay-Tolerant Networking Bundle Protocol from Space"
> Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
> Jackson, Alex da Silva Curiel.
>
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
> iac-2008
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +
>
> The following is a summary of the flight tests and test results for DTN
> flight testing using the UK-DMC satellite.  Download was to SSTL's
> ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
> 8.1 Mbps.
>
> These tests are a repeat of the January testing reported at the IRTF
> meeting at IETF-71 in March 2008 and at the NASA Earth Science
> Technology Conference in June 2008.  See:
>
> http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
> f
> http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
> F_DTN.ppt
>   
Great news, Will -- well done!

Scott

From: "Peter Lovell" <[email-masked]>
To: "William D. (GRC-RCN0) Ivancic" <[email-masked]>, "dtn interest" <[email-masked]>, <[email-masked]>
Date: Thu, 11 Sep 2008 13:01:44 -0400
Cc: [email-masked]
Subject: Re: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

On Thu, Sep 11, 2008, Ivancic, William D. (GRC-RHN0)
<[email-masked]> wrote:

>UK-DMC satellite first to transfer sensor data from space using 'bundle'
>protocol
>http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
>

Congratulations !!

Regards.....Peter

Date: Thu, 11 Sep 2008 17:33:44 +0100
From: Stephen Farrell <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

Congruatulations on the successful test!
S.

Ivancic, William D. (GRC-RHN0) wrote:
> First, I would like to thank both the NASA and SSTL procurement officers
> for their patience, professionalism and diligence as these results would
> not have been possible without their hard work.
> 
> UK-DMC satellite first to transfer sensor data from space using 'bundle'
> protocol
> http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254
> 
> 
> "Use of the Delay-Tolerant Networking Bundle Protocol from Space"
> Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
> Jackson, Alex da Silva Curiel.
> 
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
> http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
> iac-2008
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> +
> 
> The following is a summary of the flight tests and test results for DTN
> flight testing using the UK-DMC satellite.  Download was to SSTL's
> ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
> 8.1 Mbps.
> 
> These tests are a repeat of the January testing reported at the IRTF
> meeting at IETF-71 in March 2008 and at the NASA Earth Science
> Technology Conference in June 2008.  See:
> 
> http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
> f
> http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
> F_DTN.ppt
> 
> 
> Test Plan:
> ==========
> The image should be taken with the MD5 checksum enabled. 
> 
> DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
> 1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
> Station
> 2)      Demonstrate that DTN code and general SSTL code can coexist
> without effecting normal SSTL Operations
> 
> Configuration
> *       UK-DMC acquired a 150 Mbyte image.
> *       DTN bundling code default set to 80 Mbytes for proactive
> fragmentation
> Tests
> 1)      Basic file download using existing technique (GRC Saratoga)
> 2)      Same file downloaded but treated as single bundle (DTN)
> 3)      Same file download but using DTN proactive fragmentation with 80
> Mbytes preconfigured fragments.
> 3a)     Somewhere in the downloads we want to make sure we download the
> sysconfig that has the MD5 payload checksum
> 4)      Basic file download using SSTL Saratoga
> 
> 
> 
> 
> August 26th UK-DMC passes:
> ============================
> 07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR
> code.
> 
> 07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).
> 
> 08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).
> 
> 09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).
> ============================
> 
> The following is preliminary results for the 8:07 pass:
> 
> 1) Successfully downloaded syslog.  No MD5 calculation present.
> 2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga
> 3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload
> 3) Downloaded 1st 80 Mbyte bundle fragment
> 4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at
> about 2/3 complete. (Soft of a good thing in that we get to test 2 pass
> recombining.)
> 5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent
> to GRC Bundle Agent and GRC took custody of both full bundle and 1st
> bundle fragment. 
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file
> (Result is f434d0116a1f8b8e5a1cfff4a931812c)
> 
> Extracted payload from GRC bundle agent (full file) and checked MD5.  It
> matched full file MD5.
> 
> Checked SSDR code and discovered MD5 telecommand handling problem.  Code
> assumes that images end in ".img"!  That works on Cisco Engineering
> testbed, but is not a valid assumption for UK-DMC. 
> 
> 
> The following is preliminary results for the 9:45 pass:
> 
> 1) Downloaded 2nd 70 Mbyte bundle fragment
> 2) Downloaded syslog
> 3) SSTL downloaded image with SSTL's Saratoga Implementation
> 4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC
> Bundle Agent. GRC took custody of 2nd bundle fragment. 
> 
> 
> Post Processing:
> 
> Computed MD5 on 150 Mbyte file and payload portion of the full bundle
> brought Down by GRC Saratoga (Result is
> f434d0116a1f8b8e5a1cfff4a931812c) matched.
> 
> Extracted payload from  2 fragments and checked MD5.  MD5 did not Match!
> 
> - Inspected Bundle Fragments and noted header overwrite - index problem
> puts 4 bytes of DTN header into the header.
> - Inspected syslog and noted that build was April 11th which had the
> overwrite problem discovered in lab testing in August. 
>  Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin
> 
> Preliminary results/conclusions:
> ===============================
> Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle
> and file downloads with GRC Saratoga implementation.  Current MD5 is
> EXTREMELY promising.
> This was done August 28th and comparison was correct.  So File from
> "file" download using GRC and SSTL Saratoga implementation matched as
> did bundle payload of GRC bundle download using Saratoga.
> 
> 
> - Latest SSDR build was not used.  April 11th build had fragmentation
> index problem.  That is why SSTL got error message when sending MD5
> command (Hex 60) because the command did not exist in the April 11th
> build.
> 
> ***  GRC already rewritten and compiled new SSDR code to run MD5
> calculations on files larger than 5 Mbytes.  Yet to be will test in
> Cisco Engineering Model testbed and once we confirm tests then we will
> send new code to SSTL for flight tests.  ***
> 
> 
> August 27th UK-DMC Passes:
> **** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin
> ===================================================================
> The image is scheduled for 08:27 UTC, again over South Africa.
> 
> The MD5 command is scheduled for 08:35 UTC
> 
> 1st pass is between 08:44 and 08:57 UTC
> 
> 2nd pass is between 10:23 and 10:34 UTC
> ==============================================
> 
> The first pass results are as follows:
> 
> 1) Downloaded Syslog successfully
> 2) Downloaded Bundle Frag 1 (80 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 3) Downloaded Bundle Frag 2 (77.5 Mbyte).  Bundle was received and
> forwarded to GRC Bundle Agent using DTN-2
> 4) Downloaded File using GRC Saratoga
> 4a) Lots of bursts of errors on initial download.  Caused a fail of
> transfer as "inactivity timeout". Saratoga timed out. 
> 4b) We restarted our Saratoga client - just for good measure.
> 4c) Restarted file transfer using Saratoga and successfully completed.
> 
> 
> Post Processing
> =================
> 1) Combined and extracted file from two bundle fragments.  Calculated
> Checksum
> 2) Ran MD5 checksum on file residing on SSTL Bundle Agent
> 
> Results matched as shown below:  Proves fragmentation is working!  This
> also match checksum of SSTL file download calculated August 28th.
> 
> [weddy@bundling-SSTL ~]$ md5sum DU000d72pm
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm [weddy@Bundle-Master ~]$
> md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e
> Aug272008-1_frag.dtn
> 
> 3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and
> placed on Web Server for SSTL post processing.
> 
> The following is the terminal log from GRC Bundle Master:
> ============================================================
> # Performed list command. Shows 1st fragment.# Currently Pending Bundles
> (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle
> list Currently Pending Bundles (1):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
> Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%
> bundle list Currently Pending Bundles (2):
>         92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000
>         92716: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 77500550
> 
> # Application Requested Bundle to File at GRC Bundle Master and Bundle
> Fragments are combined.# bundling-grc dtn% [1219828317.602151
> /dtn/bundle/daemon warning] event REGISTRATION_ADDED took 2335 ms to
> process
> [1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED
> took 2218 ms to process bundle list Currently Pending Bundles (1):
>         92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 157500550
> 
> bundling-grc dtn% bundle list
> Currently Pending Bundles (0):
> 
> bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event
> BUNDLE_FREE took 2402 ms to process
> [1219828324.915598 /timer warning] timer thread running slow -- timer is
> 2313 msecs late
> 
> # Performed list command. Shows bundles have been removed from Bundle
> Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):
> 
> bundling-grc dtn%
> 
> 
> The following was performed during pass 2, 10:23 UTC
> 
> Order of tests Pass 2:
> ======================
> 1) Download Syslog successfully
> 2) Download Frag 2 successfully
> 2a) Frag 2 was forwarded to GRC Bundle Master
> 2b) Copied First Pass Frag-2 form temporary directory file to another
> location on SSTL Bundle Agent
> 2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and
> second pass.  MD5 results match.  Conclusion is use of multiple ground
> stations and proactive fragmentation will work.
> 
> [weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-1_frag2.dtn
> e849a9481cd7d9cc709555d7d5f0b012  Aug272008-2_frag2.dtn
> 
> 3) Download full Bundle using GRC Saratoga
> 3a) Similar to pass 1, we received bursts of errors causing Saratoga to
> time out.  Due to the limited time pass, we terminated this test in
> order to give SSTL sufficient time to download the image file.
> 
> 4) Download Syslog successfully using GRC Saratoga
> 
> 4) Download File successfully using SSTL Saratoga
> 
> 
> SSTL  FTPed their image downloads to GRC and we confirmed MD5 check on
> August 28th.
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm         
> # file downloaded by SSTL Aug 26, 2008 pass
> f434d0116a1f8b8e5a1cfff4a931812c  DU000d70pm
> 
> [weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm         
> # file downloaded by SSTL Aug 27,2008 pass
> ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm
> 
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img    
> # file download as 2 fragments & xfer via DTN to bundle-master Aug 26,
> 2008 pass fb03c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img  #
> MD5 mismatch due to file corrupted from bug in old GRC generated SSDR
> binary.
> 
> [weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img    
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c 
> Aug262008-1_ufrag_dtn.img   
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> [weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn            
> # file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
> 27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e 
> Aug272008-1_frag.dtn         
> # MD5 matches with file above that was downloaded by SSTL's Saratoga
> client
> 
> ******************************************
> Regarding GRC's Implementation of Saratoga
> ******************************************
> We have some ideas on why GRC's Saratoga may be timing out. We will look
> at that in the next few days, weeks.  We didn't problems with Saratoga
> on August 26th.  That pass was at a very high elevation (almost directly
> overhead). SSTL will check the telemetry logs to see if there was
> interference or something.  From the background conversations, we
> believe that SSTL has their timeout settings longer GRC's for Saratoga.
> Also, we understand that SSTL's Saratoga can restart from where it left
> off whereas GRC's restarts at the beginning.  Finally, in order to
> minimize transmissions on the 9600 bps uplink, SSTL does some hole
> combining requests prior to asking for retransmissions - basically just
> requesting retransmission of a large segment rather than small gaps of
> holes.  This is done to minimize the back-channel transmission otherwise
> one creates self congestion in the 9600 uplink.
> 
> 
> ===========================================
> I place the image that was extracted from the DTN full bundle at the
> following location:
> 
> http://roland.grc.nasa.gov/~ivancic/shared/DTN/
> 
> .tiff is approximately 150 Mbytes
> .pdf is 150 kbytes
> Other is raw unprocessed data. 
> 
> /Will Ivancic 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Date: Thu, 11 Sep 2008 10:51:09 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] 1st Successful Bundling Tests from Space - Technical Results

First, I would like to thank both the NASA and SSTL procurement officers
for their patience, professionalism and diligence as these results would
not have been possible without their hard work.

UK-DMC satellite first to transfer sensor data from space using 'bundle'
protocol
http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254

"Use of the Delay-Tolerant Networking Bundle Protocol from Space"
Lloyd Wood, Will Ivancic, Wes Eddy, Dave Stewart, James Northam, Chris
Jackson, Alex da Silva Curiel.

http://personal.ee.surrey.ac.uk/Personal/L.Wood/saratoga/
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#
iac-2008

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+

The following is a summary of the flight tests and test results for DTN
flight testing using the UK-DMC satellite.  Download was to SSTL's
ground station in Guildford, England.  Uplink is 9600 bps, Downlink is
8.1 Mbps.

These tests are a repeat of the January testing reported at the IRTF
meeting at IETF-71 in March 2008 and at the NASA Earth Science
Technology Conference in June 2008.  See:

http://esto.nasa.gov/conferences/estc2008/papers/Ivancic_William_A4P2.pd
f
http://roland.grc.nasa.gov/~ivancic/papers_presentations/2008/IETF71_IRT
F_DTN.ppt

Test Plan:
==========
The image should be taken with the MD5 checksum enabled. 

DTN Test Plan for Initial DTN Testing using the UK-DMC Goal
1)      Demonstrate DTN Bundle Transfer from UK-DMC to SSTL Ground
Station
2)      Demonstrate that DTN code and general SSTL code can coexist
without effecting normal SSTL Operations

Configuration
*       UK-DMC acquired a 150 Mbyte image.
*       DTN bundling code default set to 80 Mbytes for proactive
fragmentation
Tests
1)      Basic file download using existing technique (GRC Saratoga)
2)      Same file downloaded but treated as single bundle (DTN)
3)      Same file download but using DTN proactive fragmentation with 80
Mbytes preconfigured fragments.
3a)     Somewhere in the downloads we want to make sure we download the
sysconfig that has the MD5 payload checksum
4)      Basic file download using SSTL Saratoga

August 26th UK-DMC passes:
============================
07:50:11 Capture a 150 Mb image over South Africa using the DTN SSDR
code.

07:55:00 Send the MD5 command (Node 0x90, Command 0x60, Value 0x00).

08:07:33 - 08:20:53 High Rate Pass SSTL (Disable SSTL Saratoga).

09:45:13 - 09:58:13 High Rate Pass SSTL (Disable SSTL Saratoga).
============================

The following is preliminary results for the 8:07 pass:

1) Successfully downloaded syslog.  No MD5 calculation present.
2) Downloaded 150 Mbyte Image using GRC's implementation of Saratoga
3) Downloaded 70+byte DTN header plus 150 Mbyte DTN payload
3) Downloaded 1st 80 Mbyte bundle fragment
4) Started download of 2nd 70 Mbyte bundle fragment. Loss of Signal at
about 2/3 complete. (Soft of a good thing in that we get to test 2 pass
recombining.)
5) Bundle and 1st fragment moved from SSTL Ground Station Bundle Agent
to GRC Bundle Agent and GRC took custody of both full bundle and 1st
bundle fragment. 

Post Processing:

Computed MD5 on 150 Mbyte file
(Result is f434d0116a1f8b8e5a1cfff4a931812c)

Extracted payload from GRC bundle agent (full file) and checked MD5.  It
matched full file MD5.

Checked SSDR code and discovered MD5 telecommand handling problem.  Code
assumes that images end in ".img"!  That works on Cisco Engineering
testbed, but is not a valid assumption for UK-DMC. 

The following is preliminary results for the 9:45 pass:

1) Downloaded 2nd 70 Mbyte bundle fragment
2) Downloaded syslog
3) SSTL downloaded image with SSTL's Saratoga Implementation
4) 2nd fragment moved from SSTL Ground Station Bundle Agent to GRC
Bundle Agent. GRC took custody of 2nd bundle fragment. 

Post Processing:

Computed MD5 on 150 Mbyte file and payload portion of the full bundle
brought Down by GRC Saratoga (Result is
f434d0116a1f8b8e5a1cfff4a931812c) matched.

Extracted payload from  2 fragments and checked MD5.  MD5 did not Match!

- Inspected Bundle Fragments and noted header overwrite - index problem
puts 4 bytes of DTN header into the header.
- Inspected syslog and noted that build was April 11th which had the
overwrite problem discovered in lab testing in August. 
 Latest build was: ukdmc-ppcssdr-ssdr0-August-7-2.bin

Preliminary results/conclusions:
===============================
Need to compare MD5 with SSTL Saratoga Download to confirm good Bundle
and file downloads with GRC Saratoga implementation.  Current MD5 is
EXTREMELY promising.
This was done August 28th and comparison was correct.  So File from
"file" download using GRC and SSTL Saratoga implementation matched as
did bundle payload of GRC bundle download using Saratoga.

- Latest SSDR build was not used.  April 11th build had fragmentation
index problem.  That is why SSTL got error message when sending MD5
command (Hex 60) because the command did not exist in the April 11th
build.

***  GRC already rewritten and compiled new SSDR code to run MD5
calculations on files larger than 5 Mbytes.  Yet to be will test in
Cisco Engineering Model testbed and once we confirm tests then we will
send new code to SSTL for flight tests.  ***

August 27th UK-DMC Passes:
**** Note, August 27th Pass uses ukdmc-ppcssdr-ssdr0-August-7-2.bin
===================================================================
The image is scheduled for 08:27 UTC, again over South Africa.

The MD5 command is scheduled for 08:35 UTC

1st pass is between 08:44 and 08:57 UTC

2nd pass is between 10:23 and 10:34 UTC
==============================================

The first pass results are as follows:

1) Downloaded Syslog successfully
2) Downloaded Bundle Frag 1 (80 Mbyte).  Bundle was received and
forwarded to GRC Bundle Agent using DTN-2
3) Downloaded Bundle Frag 2 (77.5 Mbyte).  Bundle was received and
forwarded to GRC Bundle Agent using DTN-2
4) Downloaded File using GRC Saratoga
4a) Lots of bursts of errors on initial download.  Caused a fail of
transfer as "inactivity timeout". Saratoga timed out. 
4b) We restarted our Saratoga client - just for good measure.
4c) Restarted file transfer using Saratoga and successfully completed.

Post Processing
=================
1) Combined and extracted file from two bundle fragments.  Calculated
Checksum
2) Ran MD5 checksum on file residing on SSTL Bundle Agent

Results matched as shown below:  Proves fragmentation is working!  This
also match checksum of SSTL file download calculated August 28th.

[weddy@bundling-SSTL ~]$ md5sum DU000d72pm
ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm [weddy@Bundle-Master ~]$
md5sum Aug272008-1_frag.dtn ce1a95dcb175ff21a2d3ec69315e1d7e
Aug272008-1_frag.dtn

3) Copied image of Africa file, DU000d72pm, to GRC Bundle-Master and
placed on Web Server for SSTL post processing.

The following is the terminal log from GRC Bundle Master:
============================================================
# Performed list command. Shows 1st fragment.# Currently Pending Bundles
(1):
        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
Performed list command. Shows 1st fragment.# bundling-grc dtn% bundle
list Currently Pending Bundles (1):
        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000 #
Performed list command. Shows 1st and 2nd fragment.# bundling-grc dtn%
bundle list Currently Pending Bundles (2):
        92715: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 80000000
        92716: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 77500550

# Application Requested Bundle to File at GRC Bundle Master and Bundle
Fragments are combined.# bundling-grc dtn% [1219828317.602151
/dtn/bundle/daemon warning] event REGISTRATION_ADDED took 2335 ms to
process
[1219828319.821315 /dtn/bundle/daemon warning] event BUNDLE_RECEIVED
took 2218 ms to process bundle list Currently Pending Bundles (1):
        92717: dtn:uk-dmc/i -> dtn:bundling-grc1/i length 157500550

bundling-grc dtn% bundle list
Currently Pending Bundles (0):

bundling-grc dtn% [1219828324.915213 /dtn/bundle/daemon warning] event
BUNDLE_FREE took 2402 ms to process
[1219828324.915598 /timer warning] timer thread running slow -- timer is
2313 msecs late

# Performed list command. Shows bundles have been removed from Bundle
Agent# bundling-grc dtn% bundle list Currently Pending Bundles (0):

bundling-grc dtn%

The following was performed during pass 2, 10:23 UTC

Order of tests Pass 2:
======================
1) Download Syslog successfully
2) Download Frag 2 successfully
2a) Frag 2 was forwarded to GRC Bundle Master
2b) Copied First Pass Frag-2 form temporary directory file to another
location on SSTL Bundle Agent
2c) Did an MD5 comparison of the payload of Frag -2 from the 1st and
second pass.  MD5 results match.  Conclusion is use of multiple ground
stations and proactive fragmentation will work.

[weddy@bundling-SSTL ~]$ md5sum *frag2*.dtn
e849a9481cd7d9cc709555d7d5f0b012  Aug272008-1_frag2.dtn
e849a9481cd7d9cc709555d7d5f0b012  Aug272008-2_frag2.dtn

3) Download full Bundle using GRC Saratoga
3a) Similar to pass 1, we received bursts of errors causing Saratoga to
time out.  Due to the limited time pass, we terminated this test in
order to give SSTL sufficient time to download the image file.

4) Download Syslog successfully using GRC Saratoga

4) Download File successfully using SSTL Saratoga

SSTL  FTPed their image downloads to GRC and we confirmed MD5 check on
August 28th.

[weddy@Bundle-Master SSTL_Files]$ md5sum DU000d70pm         
# file downloaded by SSTL Aug 26, 2008 pass
f434d0116a1f8b8e5a1cfff4a931812c  DU000d70pm

[weddy@Bundle-Master SSTL_Files]$ md5sum DU000d72pm         
# file downloaded by SSTL Aug 27,2008 pass
ce1a95dcb175ff21a2d3ec69315e1d7e  DU000d72pm

[weddy@Bundle-Master ~]$ md5sum Aug262008-12_frag_dtn.img    
# file download as 2 fragments & xfer via DTN to bundle-master Aug 26,
2008 pass fb03c9f16c60eb486ebc45b74974cb0a Aug262008-12_frag_dtn.img  #
MD5 mismatch due to file corrupted from bug in old GRC generated SSDR
binary.

[weddy@Bundle-Master ~]$ md5sum Aug262008-1_ufrag_dtn.img    
# file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
26, 2008 pass f434d0116a1f8b8e5a1cfff4a931812c 
Aug262008-1_ufrag_dtn.img   
# MD5 matches with file above that was downloaded by SSTL's Saratoga
client

[weddy@Bundle-Master ~]$ md5sum Aug272008-1_frag.dtn            
# file downloaded as 1 DTN bundle & xfer via DTN to Bundle-Master Aug
27, 2008 pass ce1a95dcb175ff21a2d3ec69315e1d7e 
Aug272008-1_frag.dtn         
# MD5 matches with file above that was downloaded by SSTL's Saratoga
client

******************************************
Regarding GRC's Implementation of Saratoga
******************************************
We have some ideas on why GRC's Saratoga may be timing out. We will look
at that in the next few days, weeks.  We didn't problems with Saratoga
on August 26th.  That pass was at a very high elevation (almost directly
overhead). SSTL will check the telemetry logs to see if there was
interference or something.  From the background conversations, we
believe that SSTL has their timeout settings longer GRC's for Saratoga.
Also, we understand that SSTL's Saratoga can restart from where it left
off whereas GRC's restarts at the beginning.  Finally, in order to
minimize transmissions on the 9600 bps uplink, SSTL does some hole
combining requests prior to asking for retransmissions - basically just
requesting retransmission of a large segment rather than small gaps of
holes.  This is done to minimize the back-channel transmission otherwise
one creates self congestion in the 9600 uplink.

===========================================
I place the image that was extracted from the DTN full bundle at the
following location:

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

.tiff is approximately 150 Mbytes
.pdf is 150 kbytes
Other is raw unprocessed data. 

/Will Ivancic 

Date: Tue, 09 Sep 2008 15:15:19 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] My agenda slot request - finishing documents

Assuming we do meet in MSP:

In addition to the usual business, I'd like to include a slot
where we discuss how to (or even whether to) finish up work
on each of the existing DTNRG drafts.

The reason to have this discussion is basically due to the long
lead time to get RFCs out, (once the RG is done), and the fact
that we have so many drafts on the boil.

I'd like if we could get a bunch finished at the same time (maybe
before end of the year) to at least make that a bit quicker.

So if you're the author of an existing draft please try to update
it before the meeting and have a plan for finishing.

S.

Date: Tue, 09 Sep 2008 15:07:46 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] DTNRG meeting at IETF-73

Hi all,

A number of people suggested that we schedule a slot for meeting
at IETF-73. [1] Can you let Kevin and I know (off-list is fine,
I'll summarise back to the list):

- if you plan to attend, and which days suit
- if there's something particular related to the current set of
  documents that you want on the agenda
- if you want a slot to speak and if so what about and for how
  long (note that we may have to figure out a way to select a
  subset of the requests - last time we had too many speakers
  and ran out of time)

By default I'll ask for a 2.5 hour slot Thursday or Friday
morning. The request has to be in by Monday, so get your
answers in soon!

Cheers,
S.

[1] http://www.ietf.org/meetings/73/