Subject: Re: [dtn-interest] Fwd: Planetary Society Newsletter - May 2003
From: "vinton g. cerf" <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Date: Sat, 31 May 2003 07:50:22 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Lloyd,

hmm. good point. I wonder if they really were DVD as opposed to
some form of CD? Frankly I have doubts that any opportunity will
arise in which an alien intelligent life form will be challenged
to decode/decrypt these. I just thought it was nice that the names
were on board. It lets a lot of us participate in a vicarious way
in the exploration. Of course, what will allow real participation
will be the successful landing and deployment of the rovers and
the capture of the imagery and sensor/analysis data that they can
provide. 

vint

At 11:54 AM 5/31/2003 +0100, Lloyd Wood wrote:
>On Fri, 30 May 2003, vinton g. cerf wrote:
>
>> I thought this was a cool move.
>
>dvds are encrypted and not readable without a high degree of
>(culture-specific) technology.
>
>Did they think to include a DVD player?
>And all the gutenberg texts in the spare space of the DVD, so that
>reverse-engineering the encoding process has a worthwhile result?
>
>L.

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Fri, 30 May 2003 20:40:21 -0400
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: Planetary Society Newsletter - May 2003
Sender: [email-masked]

I thought this was a cool move.

vint

>THE PLANETARY SOCIETY NEWSLETTER
>MAY 2003
>
>YOUR NAME FLIES TO MARS IN JUNE
>As part of our Red Rover Goes to Mars program, the
>names of all Planetary Society members, as of
>December 1, 2002, are included in the 3,551,645
>names flying to Mars this June on the Mars
>Exploration Rovers. The names were encoded on a
>small DVD attached to the lander. As they rest
>on the Martian surface, the rovers will photograph
>and return to Earth an image of each DVD.  The rovers
>are scheduled to land in January 2004.
>
>For more on this upcoming Mars mission
>and the DVD, go to:
>http://www.planetary.org/rrgtm/index.html

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Thu, 29 May 2003 18:37:35 -0400
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: precision engineering
Sender: [email-masked]

>
>
>this is pretty cool
>
>http://paradiselost.com/index.php?module=htmlpages&func=display&pid=2
>
>

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

Date: Fri, 23 May 2003 00:49:11 +0200 (CEST)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [dtn-interest] DTN related poster at MobiHoc
Sender: [email-masked]

All,

I would just like to inform you that our poster "Probabilistic Routing in
Intermittently Connected Networks" by Anders Lindgren, Avri Doria, and
Olov Schelen will be presented at MobiHoc 2003, June 2 in Annapolis, MD.
The poster is DTN related and deals with routing in networks with
opportunistic contacts with a probabilistic approach. A two-page poster
summary can be found at
http://www.sm.luth.se/~dugdale/publications/mobihoc2003summary_lindgren.pdf
After the conference, the poster itself and the poster summary will be
linked from my homepage at http://www.sm.luth.se/~dugdale/ but I thought I
would give the DTN community a preview of it.
Comments are welcome (but please bear in mind that this work is in a very
initial stage), and if you are attending MobiHoc, don't hesitate to
discuss any questions you might have with me during the poster session.

Best regards,

/Anders Lindgren
Luleå University of Technology

To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Date: Mon, 19 May 2003 10:56:58 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] DTNRG web site updated to include slides from May workshop
Sender: [email-masked]

I've just pieced together all the presentations from the Workshop on May 8th.
To see 'em, either go to the dtnrg site at http://www.dtnrg.org for a link,
or go straight to here for only the presentations:

	http://www.dtnrg.org/workshop-slides/presentations.html

Thanks to everyone who participated for making this event successful!

cheers,
- Kevin

Date: Mon, 19 May 2003 09:35:03 -0400
From: Howard Weiss <[email-masked]>
To: "vinton g. cerf" <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Fwd: dtnrg
Sender: [email-masked]

--------------080600060601040807070105
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Vint,

Ray Ozzie is also the guy behind Lotus Notes isn't he?

The piece that really interested me was his discourse on security:

The next layer up is the "session" layer.  Sessions are arbitrarily long
and require significant persistent state at every endpoint.  Message
sequencing, fragmentation, retransmission, etc., is done at this session
layer.  (Interestingly, because it's N-way, you can fetch lost messages
from any available endpoint.)  Compression and encryption are also done by 
this session layer.  Session establishment is quite simple logically, but
the message flow is quite complex given the fact that it handles not only
confidentiality but authentication on a message-by-message with N-way
mutual distrust.

Essentially, he is describing security mechanisms that several of us 
would say belong in the bundle layer.  There is no arguement about the 
message-by-message "mutual distrust" but at the DRNRG we still had 
disagreements over whether to include end-to-end message confidentiality 
into the bundle layer.  Looks like Groove does it (from a Groove FAQ on 
security):

Unless extraordinary measures are taken, email is transmitted in plain 
text over networks, and is stored in plain text form on email servers, 
so anyone with access to those networks or computers can read the user's 
email. But in Groove, all information transmitted among Groove users is 
automatically encrypted and integrity-protected "on the wire" in an 
end-to-end manner, so only the sending and receiving parties (not 
intermediate routers or servers, even Groove relay servers) can read the 
data. The only place that Groove data and shared spaces exist is on 
users' computers, rather than on servers or on the public Internet, so 
users have complete control over who has access to their data.

I'd say that Groove is a GOOD security model to follow....

Howie

vinton g. cerf wrote:

>Ray Ozzie is the inventor/engineer of Groove - see below.
>
>I asked whether we'd run into patent problems using any of the
>Groove ideas...
>
>vint
>
>
>  
>
>>Date: Sun, 18 May 2003 16:59:09 -0400
>>From: Ray_Ozzie/[email-masked]
>>Subject: dtnrg
>>To: Vint Cerf <[email-masked]>
>>X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
>>X-MIMETrack: Serialize by Router on The/Rocks(Release 5.0.9a |January 7,
>>2002) at 05/18/2003 04:59:10 PM
>>Original-recipient: rfc822;@pmmsg00.wcomnet.com:[email-masked]
>>
>>Hello, Vint.  I really enjoyed meeting & speaking with you at NCSA.
>>
>>Pursuant to our conversation, I finally got around to checking out DTNRG
>>and had time to read a few of the documents on the website.  I must say
>>that I'm somewhat blown away at the similarity between the problems that
>>you're trying to solve and the challenges that we faced when building
>>Groove.  And of course, we ended up with similar architectural solutions.
>>
>>In essence, my goal was to create a pure "edge" collaborative user
>>environment and platform for collaborative apps - one that was end-to-end
>>secure and robust, embracing disconnected use and a world of variable
>>network bandwidth, latency, jitter, symmetry, etc.
>>
>>Our architectures are quite similar in that they are both based upon the
>>fundamental concept of store-and-forward message queueing, either direct
>>end-to-end or via relays.  You call 'em bundles, while we call 'em messages
>>or deltas.  In our implementation we haven't yet found the commercial need
>>for what you describe as "regions" or what we'd describe as relay-to-relay
>>routing, but it's surely within scope of the architecture.
>>
>>The biggest single difference, I think, is that while your application's
>>transport needs may only require modeling a standard "pipe" with two ends,
>>Groove had the need from the outset for a different transport model - in
>>essence, an N-ended symmetric pipe, where insertion of a message at any
>>endpoint results in the message eventually emerging from all of the other
>>endpoints.  (If N=2, it of course behaves like a standard pipe.)
>>
>>In essence, our model is three layers - described here from the bottom up.
>>
>>The lowest layer manages live logical connections between this device and
>>another device - either a peer or a relay.  It manages many, many
>>concurrent connections and tries to figure out the best path given the
>>choice of multiple physical network interfaces, and it is protocol-agile in
>>that it will happily transport a message via any method it can to get it
>>past dynamically detected obstacles such as firewalls or NATs.  This layer
>>creates the illusion, for higher layers, that the Internet actually is
>>symmetrical :-)
>>
>>The next layer up manages persistent outgoing and incoming message queues.
>>It makes best efforts to move packets from one endpoint to another, where
>>an endpoint is described by a tuple (user, device, resource), and where
>>'user' or 'device' can be wildcarded.  It requests connections of the lower
>>layer in order to move these messages out, and "listens" for incoming
>>messages to be enqueued for local resource handlers.
>>
>>The next layer up is the "session" layer.  Sessions are arbitrarily long
>>and require significant persistent state at every endpoint.  Message
>>sequencing, fragmentation, retransmission, etc., is done at this session
>>layer.  (Interestingly, because it's N-way, you can fetch lost messages
>>    
>>
>>from any available endpoint.)  Compression and encryption are also done by
>  
>
>>this session layer.  Session establishment is quite simple logically, but
>>the message flow is quite complex given the fact that it handles not only
>>confidentiality but authentication on a message-by-message with N-way
>>mutual distrust.
>>
>>Another complex task of the session layer is to provide a guaranteed
>>deterministic ordering of messages to and from all N endpoints, but in such
>>a way that received messages are optimistically given to the application
>>when received, but withdrawn and reordered and given back to the app in the
>>right order if something is later found to have been sequenced "first".
>>Thus, for example, in an N-way extended session where N=4, each of two
>>pairs of two endpoints can be indendently communicating with one another,
>>and when they are later "joined" back into a set of 4, everything
>>automatically resequences as if by magic.
>>
>>But the thing that you may or may not have yet discovered is that while
>>it's relatively easy to build distributed applications on "pipe" semantics,
>>it is far more challenging to build applications on "message queueing"
>>semantics if they are at all complex in their behavior.  One of the things
>>that took Groove so long to "get right" was in building an application
>>layer that made it relatively straightforward to build applications on this
>>model.
>>
>>We've been working on this thing since Oct '97, and at this point the kinks
>>have been worked out and it works quite robustly.  I urge you and your
>>fellow DTN researchers to download and play with Groove as an example of
>>the power of what can be done with this kind of messaging architecture.
>>
>>I've also attached, for your amusement, a VERY OLD macromedia flash
>>animation that we used to describe "how it works" from an app perspective
>>on top of this message queueing transport.  The little triangles correspond
>>to what you'd refer to as a "bundle" and we call a "delta".  It's still
>>accurate, but it ain't pretty.  (Don't worry - it's not a virus.  Just
>>remember: CTRL+F goes full screen, CTRL+R rewinds, and Enter (or clicking
>>on the arrow) goes forward a step.)
>>
>>Anyway, thanks for the pointer to the dtnrg stuff, and it'll be interesting
>>to follow its evolution.  If you are ever trying to solve a problem and
>>you're interested in how we approached it, please don't hesitate to drop me
>>a note.
>>
>>Best,
>>
>>Ray
>>
>>(See attached file: architecture4.exe)
>>
>>===============
>>Ray Ozzie, CEO
>>Groove Networks
>>http://www.groove.net
>>[email-masked]
>>    
>>
>
>Vint Cerf
>SVP Architecture & Technology
>MCI
>22001 Loudoun County Parkway, F2-4115
>Ashburn, VA 20147
>703 886 1690 (v806 1690)
>703 886 0047 fax
>[email-masked]
>www.mci.com/cerfsup 
>  
>
>------------------------------------------------------------------------
>
>This notification was inserted in order to inform you of CHANGES that have
>occurred to this email message. 
>
>Due to the impact from several email-bourne viruses, restrictions have been
>placed on the types of attachments that will be allowed through the MCI Email system.
>
>With the safety of MCI business in mind, the .exe     
>attachment(s) was removed from the message and deleted. The attachment is not saved. 
>
>If this attachment(s) was business related please contact Ehelp at
>https://wwwint.mcilink.com/ehelp/home.rbx for alternative methods to deliver your
>attachment.
>  
>

-- 
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Vint,<br>
<br>
Ray Ozzie is also the guy behind Lotus Notes isn't he?<br>
<br>
The piece that really interested me was his discourse on security: <br>
<br>
 
<pre wrap=""><font color="#330099">The next layer up is the "session" layer.  Sessions are arbitrarily long
and require significant persistent state at every endpoint.  Message
sequencing, fragmentation, retransmission, etc., is done at this session
layer.  (Interestingly, because it's N-way, you can fetch lost messages
from any available endpoint.)  <u><b>Compression and encryption are also done by 
this session layer.  Session establishment is quite simple logically, but
the message flow is quite complex given the fact that it handles not only
confidentiality but authentication on a message-by-message with N-way
mutual distrust.</b></u></font><!----></pre>
 <br>
Essentially, he is describing security mechanisms that several of us would
say belong in the bundle layer. &nbsp;There is no arguement about the message-by-message
"mutual distrust" but at the DRNRG we still had disagreements over whether
to include end-to-end message confidentiality into the bundle layer. &nbsp;Looks
like Groove does it (from a Groove FAQ on security):<br>
<br>
<font color="#330099"><big><tt><small><span>Unless extraordinary  measures
are taken, email is transmitted in plain text over networks, and is  stored
in plain text form on email servers, so anyone with access to  those networks
or computers can read the user's email.  But in Groove, all  information
transmitted among Groove users is automatically  encrypted and integrity-protected
"on the wire" in an end-to-end manner, so only  the sending and receiving
parties (not intermediate routers  or servers,  even Groove relay servers)
can read the data.  The only place that Groove  data and shared spaces exist
is on users' computers, rather than  on servers or on the public Internet,
so users have complete control over who has access to their data.    </span></small></tt></big></font><br>
<br>
I'd say that Groove is a GOOD security model to follow....<br>
<br>
Howie<br>
<br>
vinton g. cerf wrote:<br>
<blockquote type="cite"
 cite="[email-masked]">
  <pre wrap="">Ray Ozzie is the inventor/engineer of Groove - see below.

I asked whether we'd run into patent problems using any of the
Groove ideas...

vint

  </pre>
  <blockquote type="cite">
    <pre wrap="">Date: Sun, 18 May 2003 16:59:09 -0400
From: <a class="moz-txt-link-abbreviated" href="mailto:Ray_Ozzie/[email-masked]">Ray_Ozzie/[email-masked]</a>
Subject: dtnrg
To: Vint Cerf <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on The/Rocks(Release 5.0.9a |January 7,
2002) at 05/18/2003 04:59:10 PM
Original-recipient: <a class="moz-txt-link-abbreviated" href="mailto:rfc822;@pmmsg00.wcomnet.com:[email-masked]">rfc822;@pmmsg00.wcomnet.com:[email-masked]</a>

Hello, Vint.  I really enjoyed meeting &amp; speaking with you at NCSA.

Pursuant to our conversation, I finally got around to checking out DTNRG
and had time to read a few of the documents on the website.  I must say
that I'm somewhat blown away at the similarity between the problems that
you're trying to solve and the challenges that we faced when building
Groove.  And of course, we ended up with similar architectural solutions.

In essence, my goal was to create a pure "edge" collaborative user
environment and platform for collaborative apps - one that was end-to-end
secure and robust, embracing disconnected use and a world of variable
network bandwidth, latency, jitter, symmetry, etc.

Our architectures are quite similar in that they are both based upon the
fundamental concept of store-and-forward message queueing, either direct
end-to-end or via relays.  You call 'em bundles, while we call 'em messages
or deltas.  In our implementation we haven't yet found the commercial need
for what you describe as "regions" or what we'd describe as relay-to-relay
routing, but it's surely within scope of the architecture.

The biggest single difference, I think, is that while your application's
transport needs may only require modeling a standard "pipe" with two ends,
Groove had the need from the outset for a different transport model - in
essence, an N-ended symmetric pipe, where insertion of a message at any
endpoint results in the message eventually emerging from all of the other
endpoints.  (If N=2, it of course behaves like a standard pipe.)

In essence, our model is three layers - described here from the bottom up.

The lowest layer manages live logical connections between this device and
another device - either a peer or a relay.  It manages many, many
concurrent connections and tries to figure out the best path given the
choice of multiple physical network interfaces, and it is protocol-agile in
that it will happily transport a message via any method it can to get it
past dynamically detected obstacles such as firewalls or NATs.  This layer
creates the illusion, for higher layers, that the Internet actually is
symmetrical :-)

The next layer up manages persistent outgoing and incoming message queues.
It makes best efforts to move packets from one endpoint to another, where
an endpoint is described by a tuple (user, device, resource), and where
'user' or 'device' can be wildcarded.  It requests connections of the lower
layer in order to move these messages out, and "listens" for incoming
messages to be enqueued for local resource handlers.

The next layer up is the "session" layer.  Sessions are arbitrarily long
and require significant persistent state at every endpoint.  Message
sequencing, fragmentation, retransmission, etc., is done at this session
layer.  (Interestingly, because it's N-way, you can fetch lost messages
    </pre>
  </blockquote>
  <pre wrap=""><!---->&gt;from any available endpoint.)  Compression and encryption are also done by
  </pre>
  <blockquote type="cite">
    <pre wrap="">this session layer.  Session establishment is quite simple logically, but
the message flow is quite complex given the fact that it handles not only
confidentiality but authentication on a message-by-message with N-way
mutual distrust.

Another complex task of the session layer is to provide a guaranteed
deterministic ordering of messages to and from all N endpoints, but in such
a way that received messages are optimistically given to the application
when received, but withdrawn and reordered and given back to the app in the
right order if something is later found to have been sequenced "first".
Thus, for example, in an N-way extended session where N=4, each of two
pairs of two endpoints can be indendently communicating with one another,
and when they are later "joined" back into a set of 4, everything
automatically resequences as if by magic.

But the thing that you may or may not have yet discovered is that while
it's relatively easy to build distributed applications on "pipe" semantics,
it is far more challenging to build applications on "message queueing"
semantics if they are at all complex in their behavior.  One of the things
that took Groove so long to "get right" was in building an application
layer that made it relatively straightforward to build applications on this
model.

We've been working on this thing since Oct '97, and at this point the kinks
have been worked out and it works quite robustly.  I urge you and your
fellow DTN researchers to download and play with Groove as an example of
the power of what can be done with this kind of messaging architecture.

I've also attached, for your amusement, a VERY OLD macromedia flash
animation that we used to describe "how it works" from an app perspective
on top of this message queueing transport.  The little triangles correspond
to what you'd refer to as a "bundle" and we call a "delta".  It's still
accurate, but it ain't pretty.  (Don't worry - it's not a virus.  Just
remember: CTRL+F goes full screen, CTRL+R rewinds, and Enter (or clicking
on the arrow) goes forward a step.)

Anyway, thanks for the pointer to the dtnrg stuff, and it'll be interesting
to follow its evolution.  If you are ever trying to solve a problem and
you're interested in how we approached it, please don't hesitate to drop me
a note.

Best,

Ray

(See attached file: architecture4.exe)

===============
Ray Ozzie, CEO
Groove Networks
<a class="moz-txt-link-freetext" href="http://www.groove.net">http://www.groove.net</a>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Vint Cerf
SVP Architecture &amp; Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-abbreviated" href="http://www.mci.com/cerfsup">www.mci.com/cerfsup</a> 
  </pre>
  <pre wrap="">
<hr width="90%" size="4">
This notification was inserted in order to inform you of CHANGES that have
occurred to this email message. 

Due to the impact from several email-bourne viruses, restrictions have been
placed on the types of attachments that will be allowed through the MCI Email system.

With the safety of MCI business in mind, the .exe     
attachment(s) was removed from the message and deleted. The attachment is not saved. 

If this attachment(s) was business related please contact Ehelp at
<a class="moz-txt-link-freetext" href="https://wwwint.mcilink.com/ehelp/home.rbx">https://wwwint.mcilink.com/ehelp/home.rbx</a> for alternative methods to deliver your
attachment.
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------080600060601040807070105--

Date: Sun, 18 May 2003 17:33:43 -0400
From: "vinton g. cerf" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Fwd: dtnrg
Sender: [email-masked]

--Boundary_(ID_8nPEeX+qqxVCUlLmQMYmfw)
Content-type: text/plain; charset=us-ascii

Ray Ozzie is the inventor/engineer of Groove - see below.

I asked whether we'd run into patent problems using any of the
Groove ideas...

vint

>Date: Sun, 18 May 2003 16:59:09 -0400
>From: Ray_Ozzie/[email-masked]
>Subject: dtnrg
>To: Vint Cerf <[email-masked]>
>X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
>X-MIMETrack: Serialize by Router on The/Rocks(Release 5.0.9a |January 7,
> 2002) at 05/18/2003 04:59:10 PM
>Original-recipient: rfc822;@pmmsg00.wcomnet.com:[email-masked]
>
>Hello, Vint.  I really enjoyed meeting & speaking with you at NCSA.
>
>Pursuant to our conversation, I finally got around to checking out DTNRG
>and had time to read a few of the documents on the website.  I must say
>that I'm somewhat blown away at the similarity between the problems that
>you're trying to solve and the challenges that we faced when building
>Groove.  And of course, we ended up with similar architectural solutions.
>
>In essence, my goal was to create a pure "edge" collaborative user
>environment and platform for collaborative apps - one that was end-to-end
>secure and robust, embracing disconnected use and a world of variable
>network bandwidth, latency, jitter, symmetry, etc.
>
>Our architectures are quite similar in that they are both based upon the
>fundamental concept of store-and-forward message queueing, either direct
>end-to-end or via relays.  You call 'em bundles, while we call 'em messages
>or deltas.  In our implementation we haven't yet found the commercial need
>for what you describe as "regions" or what we'd describe as relay-to-relay
>routing, but it's surely within scope of the architecture.
>
>The biggest single difference, I think, is that while your application's
>transport needs may only require modeling a standard "pipe" with two ends,
>Groove had the need from the outset for a different transport model - in
>essence, an N-ended symmetric pipe, where insertion of a message at any
>endpoint results in the message eventually emerging from all of the other
>endpoints.  (If N=2, it of course behaves like a standard pipe.)
>
>In essence, our model is three layers - described here from the bottom up.
>
>The lowest layer manages live logical connections between this device and
>another device - either a peer or a relay.  It manages many, many
>concurrent connections and tries to figure out the best path given the
>choice of multiple physical network interfaces, and it is protocol-agile in
>that it will happily transport a message via any method it can to get it
>past dynamically detected obstacles such as firewalls or NATs.  This layer
>creates the illusion, for higher layers, that the Internet actually is
>symmetrical :-)
>
>The next layer up manages persistent outgoing and incoming message queues.
>It makes best efforts to move packets from one endpoint to another, where
>an endpoint is described by a tuple (user, device, resource), and where
>'user' or 'device' can be wildcarded.  It requests connections of the lower
>layer in order to move these messages out, and "listens" for incoming
>messages to be enqueued for local resource handlers.
>
>The next layer up is the "session" layer.  Sessions are arbitrarily long
>and require significant persistent state at every endpoint.  Message
>sequencing, fragmentation, retransmission, etc., is done at this session
>layer.  (Interestingly, because it's N-way, you can fetch lost messages
>from any available endpoint.)  Compression and encryption are also done by
>this session layer.  Session establishment is quite simple logically, but
>the message flow is quite complex given the fact that it handles not only
>confidentiality but authentication on a message-by-message with N-way
>mutual distrust.
>
>Another complex task of the session layer is to provide a guaranteed
>deterministic ordering of messages to and from all N endpoints, but in such
>a way that received messages are optimistically given to the application
>when received, but withdrawn and reordered and given back to the app in the
>right order if something is later found to have been sequenced "first".
>Thus, for example, in an N-way extended session where N=4, each of two
>pairs of two endpoints can be indendently communicating with one another,
>and when they are later "joined" back into a set of 4, everything
>automatically resequences as if by magic.
>
>But the thing that you may or may not have yet discovered is that while
>it's relatively easy to build distributed applications on "pipe" semantics,
>it is far more challenging to build applications on "message queueing"
>semantics if they are at all complex in their behavior.  One of the things
>that took Groove so long to "get right" was in building an application
>layer that made it relatively straightforward to build applications on this
>model.
>
>We've been working on this thing since Oct '97, and at this point the kinks
>have been worked out and it works quite robustly.  I urge you and your
>fellow DTN researchers to download and play with Groove as an example of
>the power of what can be done with this kind of messaging architecture.
>
>I've also attached, for your amusement, a VERY OLD macromedia flash
>animation that we used to describe "how it works" from an app perspective
>on top of this message queueing transport.  The little triangles correspond
>to what you'd refer to as a "bundle" and we call a "delta".  It's still
>accurate, but it ain't pretty.  (Don't worry - it's not a virus.  Just
>remember: CTRL+F goes full screen, CTRL+R rewinds, and Enter (or clicking
>on the arrow) goes forward a step.)
>
>Anyway, thanks for the pointer to the dtnrg stuff, and it'll be interesting
>to follow its evolution.  If you are ever trying to solve a problem and
>you're interested in how we approached it, please don't hesitate to drop me
>a note.
>
>Best,
>
>Ray
>
>(See attached file: architecture4.exe)
>
>===============
>Ray Ozzie, CEO
>Groove Networks
>http://www.groove.net
>[email-masked]

Vint Cerf
SVP Architecture & Technology
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
703 886 1690 (v806 1690)
703 886 0047 fax
[email-masked]
www.mci.com/cerfsup 

--Boundary_(ID_8nPEeX+qqxVCUlLmQMYmfw)
Content-type: text/plain; charset=us-ascii

This notification was inserted in order to inform you of CHANGES that have
occurred to this email message. 

Due to the impact from several email-bourne viruses, restrictions have been
placed on the types of attachments that will be allowed through the MCI Email system.

With the safety of MCI business in mind, the .exe     
attachment(s) was removed from the message and deleted. The attachment is not saved. 

If this attachment(s) was business related please contact Ehelp at
https://wwwint.mcilink.com/ehelp/home.rbx for alternative methods to deliver your
attachment.

--Boundary_(ID_8nPEeX+qqxVCUlLmQMYmfw)--

Date: Tue, 13 May 2003 20:03:38 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] DTN Security Issues
Sender: [email-masked]

My take on this is a little bit different, but mainly in line
with Howie's.

I'd argue that we should define both hop-by-hop and end-to-end
(a bad term, but ok for this mail) confidentiality and integrity
mechanisms.

We should also define a couple of key management schemes (which
fill the roll that IKE cannot fill in a DTN) to support the
above. The key management schemes we define should be targetted
at specific, known DTN application requirements. There were enough
cases described at the meeting that I'd be confident that we can
do that. (Certainly there are deployments of our project where
we would wish to have this in the DTN "layer".)

In terms of optionality etc, my take would be that applications
MUST define their security requirements in terms of which of
the defined services MUST be used, and when. Routing implementations
MUST include support for all run time mechanisms and at least
one key managmement scheme. We RECOMMEND that where possible,
security mechanisms are turned on, by default (i.e. we're
encouraging folks to take on the overhead of s-a establishment
wherever they possibly can, aiming at a kind of opportunistic
use of the security mechanims).

My reasons for taking this line could be added to Howie's
pros and cons list and include:-

- Applications developers have a history of doing badly when
it comes to designing or using cryptographic protocols. (Actually,
even security designers have their problems - witness the
side-channel attacks now emerging against TLS, CMS etc.) Basically,
doing a good job on cryptographic protocol security is not just
*hard*, but *very, very, hard*, and best-practices tend not to
be easily visible to applications developers.

- There will be many different key management scenarios, some of
which (most of which?) are currently not well understood. So
separating out key managment from run-time mechanisms is a good
idea for us. This is due to the "D" in DTN and the fact that most
key management schemes are inherently chatty. (There are exceptions,
e.g. the kind of MAC residue schemes that used to be used in
ATM networks.)

- There are a range of well understood run-time security
mechanisms from which to start working e.g. ESP, CMS, TLS'
application data "protocol", Kerberos ticket formating.
All of these allow for fairly obvious ways to separate
run-time and key management mechanisms. Basically, there's
nothing really new at run-time in a DTN since we already
have well understood conectionless security primitives.

- If a run-time mechanism for either end-to-end or hop-by-hop
is defined, then the same mechanism should be made usable for
the other case. Basically, there's no point in suggesting a
method that can only work for one of h-b-h or e-2-e. (And,
arguably, the simplest thing to do is to allow multiple
nestings, mainly due to the ambiguities inherent in the
term "end-to-end". That's another day's work though.)

- Confidentiality will be important for some environments,
in particular if bundles for different applications can be
multiplexed at a single router/mule. The only way that such
a multiplexing router can be used without forcing all
applications to be mutually trusting is via a confidentiality
service which is not hop-by-hop. Similar issues arise if a
convergence layer is not considered trustworthy (e.g. the way
NIST and others recommend running an IPsec VPN over 802.11).

- Integrity is required in order to a) protect bundle header
information, b) detect mishaps (e.g. IPv6 decided there was
no real point in a weak CRC), and c) detect active bundle
insertions/modifications, e.g. if an open convergence layer
like 802.11 is used.

- Error handling and signalling are complicated by security.
This is true regardless of whether or not cryptographic
mechanisms are used. When cryptographic mechanisms are used,
then one has to specify how error and security-association
handling interact. (That's badly stated, but you probably
know roughly what I mean.)

That's enough for now,
Stephen.

Keith Scott wrote:
> I wonder if including some security mechanisms in the dtn library that 
> applications link with would be an acceptable compromise between the two 
> positions below.  It would provide a set of standard, readily available, 
> and rigorously tested mechanisms without requiring changes to the bundle 
> protocol itself.  This would also make it very clear that e2e keying is 
> the application's problem (unless we _really_ want to take that on...).
> 
> For the user-level security, we don't have to worry about what bits of 
> the header are in the clear, right?  Let the infrastructure security 
> worry about maintaining the integrity of the headers and apply the e2e 
> security mechanisms only to the bundle payload?
> 
>                 --keith
> 
> At 02:45 PM 5/12/2003 -0400, Howard Weiss wrote:
> 
>> At the DTN Workshop last week, there was a security discussion that 
>> never came to a conclusion. 
>>
>> There were two sets of opinions being expressed:
>>
>>    1. End-to-end security services *should *be included in the DTN
>>       architecture and therefore in the bundle specification, and
>>    2. End-to-end security services should *NOT *be included in the DTN
>>       because it complicates the protocol structure and is best left
>>       to the applications that care about such services. 
>>
>>
>> There are merits in both of these arguments.   Lets look at both.....
>>
>> _Include E2 services (pros & cons):_
>>
>>     * provides shareable security services (implement once, all apps
>>       can use at no additional development expense)
>>     * provides ubiquitious security services (its there, use it if you
>>       care about security issues)
>>     * implementation is part of a "core" development and the likilhood
>>       of it being done correct (from a security strength perspective)
>>       is high(er) than if it were done by application developer A,
>>       application developer B, and also by application developer C -
>>       all of whom used different aspects of security services and may
>>       or may not have used a toolkit library.
>>     * optional service - if you don't use it, you don't pay the
>>       overhead "expense" for it (but yes, the mechanisms are included
>>       in the protocol machine). 
>>
>> _Don't include E2 services (pros & cons)_:
>>
>>     * "writer-to-reader" is best accomplished at the application layer
>>       (e.g., email from me to you signed by me has to be accomplished
>>       at the application).
>>     * toolkits are available to implement application layer security
>>       services (e.g., TLS/SSL toolkits, Cryptlib).
>>     * each application has to do their own thing - e.g., 10
>>       instruments aboard a spacecraft and every one of them would have
>>       to implement their own security mechanisms - a hit to their
>>       implementation budget and we know from past experience that if
>>       there are budget issues (and when aren't there?) then security
>>       gets pushed over the side.
>>     * applications would have to find and use security folks to do the
>>       security implementations - not space science application
>>       developers - if they don't, the liklihood of doing the
>>       implementation wrong or establishing the manner (policy) in
>>       which its used wrong will go up dramatically.  "XOR is good
>>       enough for me...." mentality. 
>>
>>
>> In my way of thinking, application security mechanisms ARE needed but 
>> not as the sole means of providing security. They are useful when a 
>> project realizes its security needs and is willing to put forth the 
>> energy and resources to accomplish the requirements.  However, I 
>> believe that there will be all too many instances of applications that 
>> won't put forth the resources to provide security solutions but would 
>> make use of a solution if it were there anyway.  I don't think that 
>> adding in security mechanisms to the DTN mucks up the protocol engine 
>> other than having to worry about the issue of which parts of the 
>> protocol header needs to remain in the clear.  Certainly it will cost 
>> in terms of additional code and CPU cycles but the code and CPU cycles 
>> will be needed whether its implemented in the bundle layer or if its 
>> in the application itself.  Or it might not in either case if 
>> embeddable crypto engine hardware is utilized (e.g., hand the crypto 
>> module a block of plaintext data, tell it what to do with it, and get 
>> back a bucket of ciphertext).
>>
>> What do you all think?
>>
>> Comments?   Discussion?
>>
>> Howie
>>
>>-- 
>>                                                                    
>>Howard Weiss      
>>SPARTA, Inc.
>>7075 Samuel Morse Drive
>>Columbia, MD 21046
>>410.872.1515 x201
>>410.872.8079 (fax)
>>
>>
> 

Date: Tue, 13 May 2003 12:49:35 -0400
To: [email-masked] (Howard Weiss), [email-masked]
From: [email-masked] (Keith Scott)
Subject: Re: [dtn-interest] DTN Security Issues
Sender: [email-masked]

--=====================_679026==.ALT
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I wonder if including some security mechanisms in the dtn library that=
 applications link with would be an acceptable compromise between the two=
 positions below.  It would provide a set of standard, readily available,=
 and rigorously tested mechanisms without requiring changes to the bundle=
 protocol itself.  This would also make it very clear that e2e keying is the=
 application's problem (unless we _really_ want to take that on...).

For the user-level security, we don't have to worry about what bits of the=
 header are in the clear, right?  Let the infrastructure security worry=
 about maintaining the integrity of the headers and apply the e2e security=
 mechanisms only to the bundle payload?

                --keith

At 02:45 PM 5/12/2003 -0400, Howard Weiss wrote:
>At the DTN Workshop last week, there was a security discussion that never=
 came to a conclusion. =20
>
>There were two sets of opinions being expressed:
>
>    * End-to-end security services should be included in the DTN=
 architecture and therefore in the bundle specification, and=20
>    * End-to-end security services should NOT be included in the DTN=
 because it complicates the protocol structure and is best left to the=
 applications that care about such services.=20
>
>There are merits in both of these arguments.   Lets look at both.....
>
>Include E2 services (pros & cons):=20
>    * provides shareable security services (implement once, all apps can=
 use at no additional development expense)=20
>    * provides ubiquitious security services (its there, use it if you care=
 about security issues)=20
>    * implementation is part of a "core" development and the likilhood of=
 it being done correct (from a security strength perspective) is high(er)=
 than if it were done by application developer A, application developer B,=
 and also by application developer C - all of whom used different aspects of=
 security services and may or may not have used a toolkit library.=20
>    * optional service - if you don't use it, you don't pay the overhead=
 "expense" for it (but yes, the mechanisms are included in the protocol=
 machine).=20
>Don't include E2 services (pros & cons):=20
>    * "writer-to-reader" is best accomplished at the application layer=
 (e.g., email from me to you signed by me has to be accomplished at the=
 application).=20
>    * toolkits are available to implement application layer security=
 services (e.g., TLS/SSL toolkits, Cryptlib).=20
>    * each application has to do their own thing - e.g., 10 instruments=
 aboard a spacecraft and every one of them would have to implement their own=
 security mechanisms - a hit to their implementation budget and we know from=
 past experience that if there are budget issues (and when aren't there?)=
 then security gets pushed over the side.=20
>    * applications would have to find and use security folks to do the=
 security implementations - not space science application developers - if=
 they don't, the liklihood of doing the implementation wrong or establishing=
 the manner (policy) in which its used wrong will go up dramatically.  "XOR=
 is good enough for me...." mentality.=20
>
>In my way of thinking, application security mechanisms ARE needed but not=
 as the sole means of providing security. They are useful when a project=
 realizes its security needs and is willing to put forth the energy and=
 resources to accomplish the requirements.  However, I believe that there=
 will be all too many instances of applications that won't put forth the=
 resources to provide security solutions but would make use of a solution if=
 it were there anyway.  I don't think that adding in security mechanisms to=
 the DTN mucks up the protocol engine other than having to worry about the=
 issue of which parts of the protocol header needs to remain in the clear. =
 Certainly it will cost in terms of additional code and CPU cycles but the=
 code and CPU cycles will be needed whether its implemented in the bundle=
 layer or if its in the application itself.  Or it might not in either case=
 if embeddable crypto engine hardware is utilized (e.g., hand the crypto=
 module a block of plaintext data, tell it what to do with it, and get back=
 a bucket of ciphertext).
>
>What do you all think?
>
>Comments?   Discussion?
>
>Howie
>
>--=20
>                                                                   =20
>Howard Weiss     =20
>SPARTA, Inc.
>7075 Samuel Morse Drive
>Columbia, MD 21046
>410.872.1515 x201
>410.872.8079 (fax)
>

--=====================_679026==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<body>
I wonder if including some security mechanisms in the dtn library that
applications link with would be an acceptable compromise between the two
positions below.&nbsp; It would provide a set of standard, readily
available, and rigorously tested mechanisms without requiring changes to
the bundle protocol itself.&nbsp; This would also make it very clear that
e2e keying is the application's problem (unless we _really_ want to take
that on...).<br><br>
For the user-level security, we don't have to worry about what bits of
the header are in the clear, right?&nbsp; Let the infrastructure security
worry about maintaining the integrity of the headers and apply the e2e
security mechanisms only to the bundle payload?<br><br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>--keith<br><br>
At 02:45 PM 5/12/2003 -0400, Howard Weiss wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>At the DTN Workshop last week,
there was a security discussion that never came to a conclusion.&nbsp;
<br><br>
There were two sets of opinions being expressed:<br><br>
<ol>
<li>End-to-end security services <b>should </b>be included in the DTN
architecture and therefore in the bundle specification, and=20
<li>End-to-end security services should <b>NOT </b>be included in the DTN
because it complicates the protocol structure and is best left to the
applications that care about such services.
</ol><br>
There are merits in both of these arguments.&nbsp;&nbsp; Lets look at
both.....<br><br>
<u>Include E2 services (pros &amp; cons):</u>=20
<ul>
<li>provides shareable security services (implement once, all apps can
use at no additional development expense)=20
<li>provides ubiquitious security services (its there, use it if you care
about security issues)=20
<li>implementation is part of a &quot;core&quot; development and the
likilhood of it being done correct (from a security strength perspective)
is high(er) than if it were done by application developer A, application
developer B, and also by application developer C - all of whom used
different aspects of security services and may or may not have used a
toolkit library.=20
<li>optional service - if you don't use it, you don't pay the overhead
&quot;expense&quot; for it (but yes, the mechanisms are included in the
protocol machine).=20
</ul><u>Don't include E2 services (pros &amp; cons)</u>:=20
<ul>
<li>&quot;writer-to-reader&quot; is best accomplished at the application
layer (e.g., email from me to you signed by me has to be accomplished at
the application).=20
<li>toolkits are available to implement application layer security
services (e.g., TLS/SSL toolkits, Cryptlib).=20
<li>each application has to do their own thing - e.g., 10 instruments
aboard a spacecraft and every one of them would have to implement their
own security mechanisms - a hit to their implementation budget and we
know from past experience that if there are budget issues (and when
aren't there?) then security gets pushed over the side.=20
<li>applications would have to find and use security folks to do the
security implementations - not space science application developers - if
they don't, the liklihood of doing the implementation wrong or
establishing the manner (policy) in which its used wrong will go up
dramatically.&nbsp; &quot;XOR is good enough for me....&quot; mentality.=20
</ul><br>
In my way of thinking, application security mechanisms ARE needed but not
as the sole means of providing security. They are useful when a project
realizes its security needs and is willing to put forth the energy and
resources to accomplish the requirements.&nbsp; However, I believe that
there will be all too many instances of applications that won't put forth
the resources to provide security solutions but would make use of a
solution if it were there anyway.&nbsp; I don't think that adding in
security mechanisms to the DTN mucks up the protocol engine other than
having to worry about the issue of which parts of the protocol header
needs to remain in the clear.&nbsp; Certainly it will cost in terms of
additional code and CPU cycles but the code and CPU cycles will be needed
whether its implemented in the bundle layer or if its in the application
itself.&nbsp; Or it might not in either case if embeddable crypto engine
hardware is utilized (e.g., hand the crypto module a block of plaintext
data, tell it what to do with it, and get back a bucket of
ciphertext).<br><br>
What do you all think?<br><br>
Comments?&nbsp;&nbsp; Discussion?<br><br>
Howie<br><br>
<pre>--=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
Howard Weiss&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

</pre><font face=3D"Courier New, Courier"></font></blockquote></body>
<br>
</html>

--=====================_679026==.ALT--

Date: Mon, 12 May 2003 14:45:29 -0400
From: Howard Weiss <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN Security Issues
Sender: [email-masked]

--------------010203030106010809050506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

At the DTN Workshop last week, there was a security discussion that 
never came to a conclusion.  

There were two sets of opinions being expressed:

   1. End-to-end security services should be included in the DTN
      architecture and therefore in the bundle specification, and
   2. End-to-end security services should NOT be included in the DTN
      because it complicates the protocol structure and is best left to
      the applications that care about such services.

There are merits in both of these arguments.   Lets look at both.....

Include E2 services (pros & cons):

    * provides shareable security services (implement once, all apps can
      use at no additional development expense)
    * provides ubiquitious security services (its there, use it if you
      care about security issues)
    * implementation is part of a "core" development and the likilhood
      of it being done correct (from a security strength perspective) is
      high(er) than if it were done by application developer A,
      application developer B, and also by application developer C - all
      of whom used different aspects of security services and may or may
      not have used a toolkit library.
    * optional service - if you don't use it, you don't pay the overhead
      "expense" for it (but yes, the mechanisms are included in the
      protocol machine).

Don't include E2 services (pros & cons):

    * "writer-to-reader" is best accomplished at the application layer
      (e.g., email from me to you signed by me has to be accomplished at
      the application).
    * toolkits are available to implement application layer security
      services (e.g., TLS/SSL toolkits, Cryptlib).
    * each application has to do their own thing - e.g., 10 instruments
      aboard a spacecraft and every one of them would have to implement
      their own security mechanisms - a hit to their implementation
      budget and we know from past experience that if there are budget
      issues (and when aren't there?) then security gets pushed over the
      side.
    * applications would have to find and use security folks to do the
      security implementations - not space science application
      developers - if they don't, the liklihood of doing the
      implementation wrong or establishing the manner (policy) in which
      its used wrong will go up dramatically.  "XOR is good enough for
      me...." mentality.

In my way of thinking, application security mechanisms ARE needed but 
not as the sole means of providing security. They are useful when a 
project realizes its security needs and is willing to put forth the 
energy and resources to accomplish the requirements.  However, I believe 
that there will be all too many instances of applications that won't put 
forth the resources to provide security solutions but would make use of 
a solution if it were there anyway.  I don't think that adding in 
security mechanisms to the DTN mucks up the protocol engine other than 
having to worry about the issue of which parts of the protocol header 
needs to remain in the clear.  Certainly it will cost in terms of 
additional code and CPU cycles but the code and CPU cycles will be 
needed whether its implemented in the bundle layer or if its in the 
application itself.  Or it might not in either case if embeddable crypto 
engine hardware is utilized (e.g., hand the crypto module a block of 
plaintext data, tell it what to do with it, and get back a bucket of 
ciphertext).

What do you all think?

Comments?   Discussion?

Howie

-- 
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
At the DTN Workshop last week, there was a security discussion that never
came to a conclusion. &nbsp;<br>
 <br>
 There were two sets of opinions being expressed:<br>
 <br>
 
<ol>
  <li>End-to-end security services <b>should </b>be included in the DTN architecture 
and therefore in the bundle specification, and</li>
  <li>End-to-end security services should <b>NOT </b>be included in the DTN
because it complicates the protocol structure and is best left to the applications 
that care about such services.<br>
   </li>
</ol>
 <br>
 There are merits in both of these arguments. &nbsp; Lets look at both.....<br>
 <br>
 <u>Include E2 services (pros &amp; cons):</u> 
<ul>
  <li>provides shareable security services (implement once, all apps can use
at no additional development expense)</li>
  <li>provides ubiquitious security services (its there, use it if you care 
about security issues)</li>
  <li>implementation is part of a "core" development and the likilhood of 
it being done correct (from a security strength perspective) is high(er) than
if it were done by application developer A, application developer B, and
also by application developer C - all of whom used different aspects of security
services and may or may not have used a toolkit library.</li>
  <li>optional service - if you don't use it, you don't pay the overhead "expense"
for it (but yes, the mechanisms are included in the protocol machine).</li>
</ul>
 <u>Don't include E2 services (pros &amp; cons)</u>: 
<ul>
  <li>"writer-to-reader" is best accomplished at the application layer (e.g., 
email from me to you signed by me has to be accomplished at the application).</li>
  <li>toolkits are available to implement application layer security services 
(e.g., TLS/SSL toolkits, Cryptlib).</li>
  <li>each application has to do their own thing - e.g., 10 instruments aboard 
a spacecraft and every one of them would have to implement their own security 
mechanisms - a hit to their implementation budget and we know from past experience 
that if there are budget issues (and when aren't there?) then security gets 
pushed over the side.</li>
  <li>applications would have to find and use security folks to do the security 
implementations - not space science application developers - if they don't, 
the liklihood of doing the implementation wrong or establishing the manner 
(policy) in which its used wrong will go up dramatically. &nbsp;"XOR is good enough 
for me...." mentality.</li>
</ul>
 <br>
 In my way of thinking, application security mechanisms ARE needed but not 
as the sole means of providing security. They are useful when a project realizes
its security needs and is willing to put forth the energy and resources to
accomplish the requirements. &nbsp;However, I believe that there will be all too
many instances of applications that won't put forth the resources to provide
security solutions but would make use of a solution if it were there anyway.
&nbsp;I don't think that adding in security mechanisms to the DTN mucks up the
protocol engine other than having to worry about the issue of which parts
of the protocol header needs to remain in the clear. &nbsp;Certainly it will cost
in terms of additional code and CPU cycles but the code and CPU cycles will
be needed whether its implemented in the bundle layer or if its in the application
itself. &nbsp;Or it might not in either case if embeddable crypto engine hardware
is utilized (e.g., hand the crypto module a block of plaintext data, tell
it what to do with it, and get back a bucket of ciphertext).<br>
 <br>
What do you all think?<br>
<br>
Comments? &nbsp; Discussion?<br>
 <br>
 Howie<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
                                                                    
Howard Weiss      
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

</pre>
</body>
</html>

--------------010203030106010809050506--

Date: Sat, 10 May 2003 12:24:01 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] Acceptability of a packet etc..
Sender: [email-masked]

At 10:10 AM 5/9/2003 -0400, [email-masked] wrote:
>Scott,
>
>The resistance of a DTN model based on the personal finance concept can be
>computed by a formula such that it(the resistance) is directly proportional
>to
>
>1. inflow rate
>
>2. size of the bundle
>
>and inversely proportional to
>
>1. outflow rate
>
>2. free buffer space
>
>3. priority(assuming a high priority bundle gets a higher value(say 3) and
>a low priority bundle gets a 1) .
>
>In other words, we could take the inverse of the resistance which could be
>defined as the acceptability of the node to bundles, i.e. the inclination
>of a node to accept bundles.

More precisely, the inclination of the node to accept a particular bundle, 
of a particular size and priority.

>Taking the argument forward, we could define
>an acceptability for custodial transfer decisions too.

I think it's the same acceptability number; you might use this number as a 
parameter to deciding on a question of custody acceptance (that is, whether 
or not to send a Custody Accepted message to the current custodian of this 
bundle) or as input to some yet-to-be-defined "throttle level" value to 
pass down to the convergence-layer adapter that is using regional flow 
control to manage input traffic from the source of this bundle, or both.

>We will probably have to find out the exact dependance by statistical
>analysis of data obtained from simulation.

Maybe that's the right methodology here; I don't know.  I suspect that 
there's research in Economics that would be highly relevant, but I am 
wholly ignorant of it.

>Such a  value of acceptability will have to be computed for each node, and
>when the value is above or below a threshold level, the corresponding
>decision(to accept or not to accept) will have to be be taken.
>
>I would like to know if we have a control over specifying the size of
>buffers on the IPN intermediate nodes as well. If we had, one could
>calculate the amount of optimum buffer space that must be there at each
>node, based on the inflow and outflow rates for that node, so that
>congestion can be handled effectively.

I think it's safest to assume that all Bundling agents (nodes) are 
potentially intermediate in this sense, so I don't think we want to 
differentiate the algorithm based on location within the network.  A lot of 
the value of this notion comes from the fact that each node can make its 
decisions locally, independently, autonomously, and unilaterally without 
any information from anywhere else.

>Some form of RED will have to be used to make sure that the buffers never
>get completely full, and recovery subsequent to a node getting down ( a
>breakdown, in other words) is fast.

The acceptance computation algorithm has got to do exactly that.  The 
personal finance analog is that economies suffer whenever anyone goes 
completely bankrupt.

>Not having any link redundancy in the network would make the system very
>vulnerable to lockups, or breakdowns. Hence, there must be redundant links,
>or there could be a possibility of links communicating directly with the
>next good link by bypassing a dead link till the 'sick' node is well. this
>might entail a worse quality of transmission, but it will anyway be better
>than a complete breakdown.

Link redundancy would be excellent wherever it's possible, but it won't 
always be possible.  Some of these regional networks are going to be 
sparse, if only because the nodes are too expensive to justify a dense 
population.  Back-propagation of flow control at both the Bundling layer 
(refusal to accept custody) and the underlying convergence layers (reducing 
the rate at which we read on sockets, etc.) may be simply unavoidable, and 
in the worst case it can propagate clear out to the leaf nodes.

Bundles have time-to-live values which are true time intervals rather than 
hop counts; congested nodes can get un-congested eventually by destroying 
bundles as their times-to-live expire and thereby freeing up space for 
acceptance of incoming bundles.  Is that sufficient, or will there need to 
be additional management mechanisms built into the system?  We're asking 
ourselves just that question.

Scott 

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 9 May 2003 10:10:57 -0400
Subject: [dtn-interest] Acceptability of a packet etc..
Sender: [email-masked]

Scott,

The resistance of a DTN model based on the personal finance concept can be
computed by a formula such that it(the resistance) is directly proportional
to

1. inflow rate

2. size of the bundle 

and inversely proportional to 

1. outflow rate

2. free buffer space

3. priority(assuming a high priority bundle gets a higher value(say 3) and
a low priority bundle gets a 1) .

In other words, we could take the inverse of the resistance which could be
defined as the acceptability of the node to bundles, i.e. the inclination
of a node to accept bundles. Taking the argument forward, we could define
an acceptability for custodial transfer decisions too.

We will probably have to find out the exact dependance by statistical
analysis of data obtained from simulation.

Such a  value of acceptability will have to be computed for each node, and
when the value is above or below a threshold level, the corresponding
decision(to accept or not to accept) will have to be be taken.

I would like to know if we have a control over specifying the size of
buffers on the IPN intermediate nodes as well. If we had, one could
calculate the amount of optimum buffer space that must be there at each
node, based on the inflow and outflow rates for that node, so that
congestion can be handled effectively.

Some form of RED will have to be used to make sure that the buffers never
get completely full, and recovery subsequent to a node getting down ( a
breakdown, in other words) is fast.

Not having any link redundancy in the network would make the system very
vulnerable to lockups, or breakdowns. Hence, there must be redundant links,
or there could be a possibility of links communicating directly with the
next good link by bypassing a dead link till the 'sick' node is well. this
might entail a worse quality of transmission, but it will anyway be better
than a complete breakdown.

Thoughts?

Durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

To: [email-masked]
Date: Wed, 07 May 2003 11:21:16 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] thought/question on use of header compression for dtn
Sender: [email-masked]

The issue of moving DTN messages with lower [header] overhead
has arisen.

Some thinking about this has lead to the tentative conclusion
that header compression is probably best left for a
convergence layer to deal with (rather than the bundle
forwarding layer).  That means a convergence layer
would be making the decisions about what sort of
transform to apply as well as actually performing
the transformation [and inverse transformations].

The reasoning for this decision is that a CL is likely
to have the best information as to what kind of
compression is appropriate (if any).

Any thoughts on this?

- Kevin

Date: Mon, 05 May 2003 14:25:24 -0700
To: Durga Prasad Pandey <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] RE: coding schemes
Cc: [email-masked]
Sender: [email-masked]

>At 12:42 PM 5/5/2003, Durga Prasad Pandey wrote:
>Could you give me a little detail on the coding schemes used for uplink 
>and downlink?

Durga:

For "uplink" data flow (i.e., the transfer of information from Earth to 
space), the current international channel coding standard is CCSDS 
201.0-B-3 (ISO 12171):

http://www.ccsds.org/documents/201x0b3.pdf

For "downlink" data flow (i.e., the transfer of information from space to 
Earth), the current international channel coding standard is CCSDS 
101.0-B-6 (ISO 11754):

http://www.ccsds.org/documents/101x0b6.pdf

For "proximity" data flow (i.e., the transfer of information between nearby 
spacecraft, including orbiters and landed vehicles at Mars), the current 
international standard is CCSDS 211.0-B-1:

http://www.ccsds.org/documents/211x0b1.pdf

Although the current Proximity specification is self-contained, it is 
presently being re-layered via the "Pink Sheet" process into three separate 
documents to facilitate easier future evolution:

- Proximity-1 RF & Modulation
- Proximity-1 Sync & Coding
- Proximity-1 Space Data Link Protocol

I hope that this is useful. For your information, the CCSDS has just been 
restructured around an "IETF-like" organizational model - 
http://www.ccsds.org/about/organization.html. The new Space Link Services 
Area Director is Mr. Jean-Luc Gerner of the European Space Technology 
Centre, <[email-masked]>.

Best regards
Adrian

Adrian J. Hooke
Chairman, CCSDS Engineering Steering Group (CESG)
NASA Jet Propulsion Laboratory,
Interplanetary Network Directorate
M/S 303-400, 4800 Oak Grove Drive
Pasadena, California 91109-8099, USA
+1.818.354.3063 OFFICE
+1.818.653.9553 MOBILE
+1 818.393.6228 FAX
http://www.ccsds.org

Date: Mon, 5 May 2003 15:42:28 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: Scott Burleigh <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: [dtn-interest] RE: coding schemes
Sender: [email-masked]

Adrian,
Could you give me a little detail on the ci\oding schemes used for uplink 
and downlink?

Durga

Scott Burleigh <[email-masked]> wrote:
At 07:42 AM 5/5/2003 -0700, you wrote:
>Which Coding scheme is generally used?

Currently, different coding schemes are used for uplink (sending commands 
from the ground to the space craft, usually sparsely and at very low data 
rates) and downlink (sending telemetry from the spacecraft to the ground 
data system at relatively high data rates). Unfortunately I am not even 
close to being a coding expert; Adrian Hooke would be able to give you 
much 
better information. Generally speaking, I know that we typically use 
Reed-Solomon on downlink and some sort of convolutional coding on uplink, 
and I know that we typically concatenate multiple coding schemes on a 
single link to minimize the effective bit error rate.

Scott 

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Mon, 5 May 2003 10:36:39 -0400
Subject: [dtn-interest] Congestion possibilities in IPN
Sender: [email-masked]

Hi DTNsters!,

Some thoughts:

(1). We are looking at the possibilities of congestion.
Congestion will occur if:

i). A bundle doesn't reach its destination because it's lifetime has
expired.
ii). A bundle doesn't reach its destination because the buffer is full at
an intermediate node, which causes it to be discarded.

A loss of one/ a few bundles cannot be called congestion. Congestion will
be said to occur when there is an appreciable affect on the throughput
because of the above mentioned reasons.

(2). Suppose there are N intermediate nodes between Moon and Mars, on which
a scheduled transmission is going on in the direction from Moon to Mars.

Moon--->[Node 1]--->[Node 2]---[Node3]---.....[Node N-1]---[Node N]--->Mars

Suppose the link between the [nodes N-1] and [Node N] goes down, and there
is no alternative link between Mars and Moon.

[Node N-1] will now have to tell the Moon, by backward propagation, that
the link [N-1] -[N] is down, and "Could you please slow down/stop the
transmission?"

However, due to speed of light delays, it will be some finite time before
that message has been propagated to the moon. During that time, the node
nearest to [N-1] (i.e. [Node N-2] will be least affected, because it will
be the first to get the emergency call. node [N-3] will be informed
next...and so on. Thus we see that [Node 1] will be the last to receive the
notification, and will worst affected.

The effect will be in terms of increased queue lengths. 
It will also have to be seen that the overflow doesn't get so severe that
the nodes closer to the moon completely stops accepting packets, including
ones carrying emergency notification. They will have to be allowed to
bypass the queues.

(3). Now future missions to Mars will be sending plenty of data, including
images and videos. This implies thht the network has to be designed with
heavy traffic in mind. 

That's enough rambling for the moment. :-)

Durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date: Mon, 05 May 2003 09:23:34 -0400
To: [email-masked], [email-masked]
From: [email-masked] (Keith Scott)
Subject: Re: [dtn-interest] Re: [Fwd: RE: SCPS Reference Implementation II]
Sender: [email-masked]

>>The bundle seems to be taking the responsibility for the network layer 
>>too. If it be so, aren't we mixing up all the responsibilities? Do we have 
>>clearly defined Services, interfaces and protocols- the basic 
>>requirements?
>>
>The bundle layer is responsible for routing and (optionally) reliable 
>delivery as well.  The basic bundle header has routing and 
>demultiplexing capability similar to UDP/IP.  We decided to use header 
>chaining and the class of service field in the main bundle header to 
>handle reliability.  Part of the reason for this is that we have to make 
>routing _and_ custody decisions at each bundle hop.  Artificially 
>separating the two seemed counter-productive, but I'm open to any 
>argument to do so.
>
>[durga] -->> 
>I understand what a routing decision is, and have also read about custodial
>transfer, but I can't figure out what exactly a custody decision is. Is it
>a decision to be made by the next receiving node of whether it should take
>custody or not?
>If it is not a custodial node(with 'custody' powers like the NYPD :) ),
>then there is no decision to make. it just has to convey that it is not
>caqpable/authorised to take custody.
>On the other hand, if it IS a custodial node, it *may* take custody, or
>forward it without taking custody to the next node. Then the last custodial
>node will have to wait till one of the next nodes takes custody.
>I understand that custodial nodes *are* expected/required to take custody.
>Is it a voluntary action on their part based on their queue lengths/free
>buffer?

Right, the routing machinery decides on a next bundle-hop node and emits bundles towards it.  For those bundles requesting custodial transfer, the receiving bundle agent has to decide whether or not to actually take custody.  The decision could be based on physical conditions (e.g. buffer space) and/or policy (I take custody of YOUR bundles but not his, e.g.).  Regardless, the receiving node will have to examine the bundle, determine whether or not it requests custodial transfer, and make a decision that may be based on other properties of the bundle.  If the receiver does elect to take custody of the bundle, it then needs to generate a custody acknowledgement and send it to the bundle's current custodian.  If the receiver can't take custody, it may accept the bundle and, if possible, forward it later to someone who can.  Richer NACK semantics might be useful for those times when a node knows that it can't take custody and has to drop the bundle...

                --keith

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], "Scott, [email-masked]"
Subject: Re: [dtn-interest] Re: [Fwd: RE: SCPS Reference Implementation II]
Date: Sun, 4 May 2003 00:05:43 -0400
Sender: [email-masked]

"Scott,Keith L." <[email-masked]> wrote:

>Hi Keith,
>
>I still don't see the difference between encapsulation in Mobile IP and 
>handling over to upper layer in Bundling, they appear to be same to me- in 
>essence. Suppose we were to send a packet from earth to Mars, wouldn't the 
>TCP/IP headers be hidden/transparent to the bundling or its associated 
>transport layer in the DTN network?
>
Yes, the same way Ethernet (or ATM) headers are hidden/transparent to 
IP.  You're not really all that far off in thinking of things in 
MobileIP terms, but....why?  In MobileIP, IP packets really are 
tunneled, so that if you examine a packet in the HA-FA tunnel you'll see 
two IP headers.  Bundling doesn't cause a protocol to be encapsulated 
within itself.  I still think that a better analogy is to think of 
bundling as IP and the transport protocol bundling is running over as 
Etherenet (or ATM or SONET, or ...).

[durga] -->> Got it. 

>The bundle seems to be taking the responsibility for the network layer 
>too. If it be so, aren't we mixing up all the responsibilities? Do we have 
>clearly defined Services, interfaces and protocols- the basic 
>requirements?
>
The bundle layer is responsible for routing and (optionally) reliable 
delivery as well.  The basic bundle header has routing and 
demultiplexing capability similar to UDP/IP.  We decided to use header 
chaining and the class of service field in the main bundle header to 
handle reliability.  Part of the reason for this is that we have to make 
routing _and_ custody decisions at each bundle hop.  Artificially 
separating the two seemed counter-productive, but I'm open to any 
argument to do so.

[durga] -->> 
I understand what a routing decision is, and have also read about custodial
transfer, but I can't figure out what exactly a custody decision is. Is it
a decision to be made by the next receiving node of whether it should take
custody or not?
If it is not a custodial node(with 'custody' powers like the NYPD :) ),
then there is no decision to make. it just has to convey that it is not
caqpable/authorised to take custody.
On the other hand, if it IS a custodial node, it *may* take custody, or
forward it without taking custody to the next node. Then the last custodial
node will have to wait till one of the next nodes takes custody.
I understand that custodial nodes *are* expected/required to take custody.
Is it a voluntary action on their part based on their queue lengths/free
buffer?

>Quoting Eric Travis : "The simplest (and frankly at times the most useful) 
>is an emulator that the MITRE folks (in the Cc list) did ages ago..."
>
>Could you possibly send me a copy of this emulator? Or is Eric talking 
>about the SCPS software Pat sent me yesterday?
>
Eric's referring to a software link emulator, a device that imposes 
delays, queue lengths, and error rates on packets.  I'll see what it 
would take for us to ship you a copy of ours.  In the meantime, unless 
you have a real need to do exceptionally strange things I'd suggest you 
start with NISTnet for Linux or dummynet in FreeBSD.  MITRE's link 
emulator also requires either FreeBSD or Linux.  I don't know of any 
Windows equivalent, but I've never configured a Windows box as a router, 
either...

[durga] -->> I have a system running Linux, so that's not an issue I guess.
i have downloaded NISInet, and will check it out in the next few days.

>I sent some 
>information on what the config files should look like for the IPN 
>scanario a while back (4/9/2003).

[durga] -->>Yes, I have that message saved in my mailbox.

Thanks once again.

durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date: Sat, 03 May 2003 21:03:35 -0400
From: "Scott,Keith L." <[email-masked]>
To: Durga Prasad Pandey <[email-masked]>
CC: [email-masked], Patrick Feighery <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Re: [Fwd: RE: SCPS Reference Implementation II]
Sender: [email-masked]

Durga,

Durga Prasad Pandey wrote:

>Hi Keith,
>
>I still don't see the difference between encapsulation in Mobile IP and 
>handling over to upper layer in Bundling, they appear to be same to me- in 
>essence. Suppose we were to send a packet from earth to Mars, wouldn't the 
>TCP/IP headers be hidden/transparent to the bundling or its associated 
>transport layer in the DTN network?
>
Yes, the same way Ethernet (or ATM) headers are hidden/transparent to 
IP.  You're not really all that far off in thinking of things in 
MobileIP terms, but....why?  In MobileIP, IP packets really are 
tunneled, so that if you examine a packet in the HA-FA tunnel you'll see 
two IP headers.  Bundling doesn't cause a protocol to be encapsulated 
within itself.  I still think that a better analogy is to think of 
bundling as IP and the transport protocol bundling is running over as 
Etherenet (or ATM or SONET, or ...).

>Where is the bundle protocol specification available?
>
Along with the architecture draft at 
http://www.dtnrg.org/specs/draft_irtf_dtnrg_bundle_spec_00.pdf

>The bundle seems to be taking the responsibility for the network layer 
>too. If it be so, aren't we mixing up all the responsibilities? Do we have 
>clearly defined Services, interfaces and protocols- the basic 
>requirements?
>
The bundle layer is responsible for routing and (optionally) reliable 
delivery as well.  The basic bundle header has routing and 
demultiplexing capability similar to UDP/IP.  We decided to use header 
chaining and the class of service field in the main bundle header to 
handle reliability.  Part of the reason for this is that we have to make 
routing _and_ custody decisions at each bundle hop.  Artificially 
separating the two seemed counter-productive, but I'm open to any 
argument to do so.

The bundle protocol spec above lays out the service descriptions and 
describes the bundle protocol.  There's another document that describes 
the API between applications and the bundle reference implementation.  A 
document describing the interface between the bundle agent reference 
implementation and a convergence layer to a particular transport 
protocol is needed.

>Quoting Eric Travis : "The simplest (and frankly at times the most useful) 
>is an emulator that the MITRE folks (in the Cc list) did ages ago..."
>
>Could you possibly send me a copy of this emulator? Or is Eric talking 
>about the SCPS software Pat sent me yesterday?
>
Eric's referring to a software link emulator, a device that imposes 
delays, queue lengths, and error rates on packets.  I'll see what it 
would take for us to ship you a copy of ours.  In the meantime, unless 
you have a real need to do exceptionally strange things I'd suggest you 
start with NISTnet for Linux or dummynet in FreeBSD.  MITRE's link 
emulator also requires either FreeBSD or Linux.  I don't know of any 
Windows equivalent, but I've never configured a Windows box as a router, 
either...

>Thanks for your time.
>
>Durga
>
no worries, good questions.  I'd be interested to see what you think if 
you can pull a copy of the reference implementation.  I sent some 
information on what the config files should look like for the IPN 
scanario a while back (4/9/2003).

        --keith

Date: Sat, 3 May 2003 15:45:45 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Re: SCPS query (fwd)
Sender: [email-masked]

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

---------- Forwarded message ----------
Date: Sat, 3 May 2003 15:45:14 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: Patrick Feighery <[email-masked]>
Subject: Re: SCPS query

Thanks, Pat. The note is VERY well written! It has cleared up a nagging 
doubt I had about the Bandwidth Delay product.

Cheers!
Durga

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

---------- Forwarded message ----------
Date: Fri, 02 May 2003 13:22:27 -0400
From: Patrick Feighery <[email-masked]>
To: [email-masked]
Subject: Re: SCPS query

Please excuse the cutting and pasting....  I wrote a test report awhile 
ago
which I am cutting from which hopefully provides some additional
background......

The Internet has seen exponential growth over the last decade.  TCP, which
provides a reliable in-order mechanism for transferring data between 
systems
without duplications, has become ubiquitous throughout the Internet.  In
addition to providing a reliable stream TCP also contains congestion 
control
mechanisms to help prevent the network meltdown that occurred in the late
1980s. The majority of Internet applications (i.e., FTP, HTTP, E-mail, 
etc)
rely on the underlying transport mechanism provided by TCP.

Unfortunately, TCP does not perform well with stressed environments such 
as
high-delay, lossy satellite links. The following will briefly describe why
the performance degrades in these environments. First, when looking at
high-delay environments, the default TCP window size, which on most common
operating systems varies between 8 and 32 kilobytes (KB), is a major 
factor
concerning performance limitations. There is a relationship called the
Bandwidth Delay Product (BDP) which relates the network bandwidth, the
round-trip time, and the TCP window size.  The bandwidth of the link
multiplied by the round-tip delay determines the minimal buffer 
requirements
of TCP under optimal conditions to fully utilize the available bandwidth.

Thus high delay systems, (i.e., TCP connections that traverse 
Geosynchronous
satellites, which can add an additional delay of 600 milliseconds or 
more),
can easily increase the BDP product so the default TCP window sizes will
under utilize the bandwidth of the channel.  For example, if the window 
size
is 17520 bytes (as it is in windows 2000) and the round trip delay is 600
milliseconds, the maximum throughput under ideal conditions is about 225
Kbps. When this occurs, the sender must wait until it receives an ACK to
free window space, before allowing new data to be sent.  This phenomenon 
is
called being receive window limited. In terms of lossy environments, TCP
assumes all loss (i.e., loss cause by packet corruption, network 
congestion,
or even link outages) is due to congestion and its response to reduce its
transmission rate in half. Unfortunately, reducing the transmission rate 
on
an uncongested satellite link results in degraded performance.  The
congestion avoidance algorithm will then increase its transmission rate
slowly.  It will take several round trips to increase the transmission 
rate
to its pre-reduced rate. Thus the recovery rate for satellite links is 
much
slower than terrestrial links, resulting in reduced throughput.

The Space Communication Protocol Standards (SCPS) originated in 1992, when
elements of NASA and the US Air Force jointly commissioned the development
of a specialized suite of data transfer protocols expressly designed for 
the
stressed environment of satellite communications. A paramount design goal 
of
SCPS is that it had to be based on current Internet protocols and fully
interoperable with IETF standards.  SCPS was designed to meet the 
following
goals:

o Best possible use of limited bandwidth
o High link utilization
o Conservation of power
o Prioritization of traffic
o Tolerant of intermittent connectivity
o High forward/return link asymmetry

In addition to the performance objectives, the SCPS  was looking to
establish these protocols as an international standard for the space
networking community. The SCPS suite has been adopted as standards by the
International Standards Organization (ISO), the Consultative Committee on
Space Data Systems (CCSDS) and the US Department of Defense.

The SCPS reference Implementation that I send you is a freely available
software implementation of these standards.  The software comes in two
modes,  a single end system stack, and a transparent transport layer
gateway.  Most people (about 95% percent of the reciepents) use the 
gateway.

Many satellite services providers to increase the performance across their
networks use a split gateway approach. These gateways, typically 
bracketing
the satellite network (or otherwise challanged network) , split a single 
TCP
connection into three separate connections , .  These gateways communicate
via standard TCP when talking to each of the end-systems and a third
connection using an optimized rate based protocol is used when 
transferring
the data between them.  This technique allows essentially one to isolate 
the
properties of satellite networks that degrade performance from manifesting
itself to TCP.  For example, corruption loss on the satellite network does
not cause the transmission rate to be cut in half, or congestion loss on 
the
terrestrial network does not cause data to be retransmission consuming
satellite bandwidth that may be a scarce resource. This also allows the
deployment of protocols that can be tuned to match the various
characteristics of the satellite link without effective the end-systems.
Now the default TCP parameters on most end-systems are now applicable for
the terrestrial environment in which they operate.   The gateways 
implements
two transport layer protocols; TCP to communication with end-systems
ensuring the users of the system do not need to modify their systems; and
SCPS to communicate between gateways.  Once a gateway received and
acknowledges the data sent via TCP, it is responsible to reliably transmit
the data to its remote peer. Once the remote gateway receives and
acknowledges the data sent via SCPS, it is responsible to reliably 
transmit
it to the remote end-systems.  In this environment the gateway are 
completly
transparent, the applications are completly unaware of their presence.

A linux 2.4 kernel is fine there is a readme that explains how the 
configure
the linux kernel (which may already be done be default) to support the 
scps
gateway.

Does this help.

    Pat

"[email-masked]" wrote:

> I have a basic question. What does this software exactly do?
>
> I have Windows 9x/ME and Linux. Will install BSD if required.
>
> Durga
>

Date: Sat, 3 May 2003 15:43:43 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: "Scott,Keith L." <[email-masked]>
Cc: [email-masked], Patrick Feighery <[email-masked]>, <[email-masked]>
Subject: [dtn-interest] Re: [Fwd: RE: SCPS Reference Implementation II]
Sender: [email-masked]

Hi Keith,

I still don't see the difference between encapsulation in Mobile IP and 
handling over to upper layer in Bundling, they appear to be same to me- in 
essence. Suppose we were to send a packet from earth to Mars, wouldn't the 
TCP/IP headers be hidden/transparent to the bundling or its associated 
transport layer in the DTN network?

Where is the bundle protocol specification available?

The bundle seems to be taking the responsibility for the network layer 
too. If it be so, aren't we mixing up all the responsibilities? Do we have 
clearly defined Services, interfaces and protocols- the basic 
requirements?

Quoting Eric Travis : "The simplest (and frankly at times the most useful) 
is an emulator that 
the MITRE folks (in the Cc list) did ages ago..."

Could you possibly send me a copy of this emulator? Or is Eric talking 
about the SCPS software Pat sent me yesterday?

Thanks for your time.

Durga

Yahoo! Mail - [email-masked]    

                          This message is not flagged. [ Flag Message - 
Mark as 
                        Unread ] 

                              Date:Fri, 02 May 2003 22:16:41 -0400
                              From:"Scott,Keith L." <[email-masked]> | 
This is 
                              spam | Add to Address Book
                              To:[email-masked]
                              CC:[email-masked], "Patrick Feighery" 
                              <[email-masked]>
                              Subject:Re: [Fwd: RE: SCPS Reference 
                              Implementation II]

Durga,

>
>Here are a few, though not SCPS centric. I guess I should ask you a
>share of the DTN questions :)  I will try downloading the software 
tonight(the
>speed here is very slow), and install it, in 2-3 days.
>
>
>1. Which layer in the bundling reference model is supposed to provide
>flow control? Is it at layer 2 (link)?
>
>The DTN protocol (bundling) generally operates _above_ what is the 
>transport protocol in the constituent Internets.  Thus if you had an 
>internet on Mars running TCP/IP, bundling would be perfectly happy 
running over TCP/IP from your desktop to JPL's Deep Space Network bundle 
>gateway, over something TBD (such as the Long-haul Transport Protocol 
>LTP, being defined at JPL) to get to the Mars gateway, and then across 
>TCP/IP again on Mars.  At the moment flow control is imposed on a per 
>bundle-hop basis by whatever transport protocol bundling's running over. 
> Thus in a sense bundle flow control is at the 'bundle link' level, but 
>a bundle link may traverse an entire internet.  End-to-end flow control 
>really wouldn't make sense in situations where the entire message can be 
in flight before the first byte has arrived at the receiver.

>
>2. overflow of buffers: 
>I have been thinking over, about whether there could be overflow of
>buffers at intermediate nodes in a DTN(my thoughts are mostly IPN 
centric..),
>and have realised(!) that to analyse that without some real life data 
will
>be difficult.
>So could you tell me something about the amount of data/information that
>is expected to be transmitted over the IPN?
>
Probably the best thing to do would be to use past missions to 
extrapolate data requirements.  JPL might be able to provide information 
about data volumes from Mars Global Surveyer, Pathfinder, Gallileo, etc.

> 
>
>3. When we are talking of termination at the gateway, could we think it
>in terms of encapsulating the bundle and tunneling it, like what is
>envisaged in Mobile IP...?
>
Not really.  In MobileIP the HA encapsulates the entire packet, 
including the 'original' source and destination addresses, and ships it 
to the FA.  The FA strips off the encapsulating header to reveal the 
original packet and forwards the packet to the destination.  This 
generally happens once (though it is possible to have cascaded strings 
of FAs).  The relationship between bundling and tunneling is much more 
akin to the relationship between Ethernet and IP.  The Ethernet protocol 
'terminates' at each hop (let's ignore bridges) and passes the inner 
packet (which may be IP) to a higher layer for handling.  Budling uses 
an internet transport layer to ship bundles; at the bundle hop 
destinations, the transport layer headers are stripped off and the inner 
'packet' (bundle) is passed to a higher layer (bundling).

>
>4. Is there a clearly defined bundling reference model? Have the roles
>of the different layers been clearly marked?
>
There is the architecture document, the bundle protocol specification, 
and the reference implementation.  The current thinking is to chain 
bundle headers to add functionality.  Thus the 'basic' headers provide 
routing capability.  If reliable delivery is required, the bundle would 
have a 'current custodian header', etc.  There is not currently a clear 
distinction between a 'bundle routing' layer and a 'bundle custodial 
delivery' layer since both fucntions take place in the network itself.

>
>5. which layer has the responsibility/capability of handling custodial
>transfer?
>
See above.

>
>I hope the amateurishness in my queries are bearable. :-)
>
All good questions.  Hope you have fun with the SCPS and DTN reference 
implementations.

>
>Durga
>
>

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

From: Bob Braden <[email-masked]>
Date: Fri, 2 May 2003 13:23:29 -0700 (PDT)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] summary thoughts about "should"
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

   *> 
  *> to me conformant a vendor must implement all SHOULD unless they can 
  *> explain to their potential customers whay they did not and the customer
  *> accepts that explanation
  *> 

That was exactly the original intent of SHOULD.

Bob Braden

Date: Fri, 2 May 2003 13:48:38 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Re: [e2e] High Packet Loss and TCP (fwd)
Sender: [email-masked]

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

---------- Forwarded message ----------
Date: Fri, 02 May 2003 08:42:49 -0700
From: Cannara <[email-masked]>
To: [email-masked]
Subject: Re: [e2e] High Packet Loss and TCP

I've added info below...Alex

"[email-masked]" wrote:
> 
> >This means that you can often acquire congestion info from such
> >devices within portions of any network path.
> 
> How exactly is the congestion info acquired? In the context of a delay
> tolerant network(DTN), we cannot use 'chatty' protocols, as they consume
> valuable bandwidth. Looking at the techniques that are used in the normal
> Internet:
...The information is usually maintained within the system concerned, so one
would need to have either a separate management path in, or have the data
available in a private MIB, etc.  I wasn't suggesting just anyone could do
this, only that measurements could be made in cooperation with some system
owners/vendors and experimentation could be done....Alex
> 
> 1) Packet dropping: It is likely to go undetected for a long time, since
> the DTN model is very optimistic when it sends packets. To put it in
> another way, there is a high expectation that the packet will reach the
> destination. Thus the lifetimes of packets are long, compared to TCP
> packets.
> 
> 2) Notification by setting a bit in a returning packet(piggybacking): Since
> the connection is intermittent(and scheduled), I am not sure how much
> really we can rely on this technique. It still has some scope, depending on
> the availability of a packet on the return path.
> 
> 3) Explicit notification by a choke packet: This will have to the last
> resort, though a costly one.

...Either 2) or 3) could be done by using some bits in TCP headers (e.g., in
Acks) that are typically unused, so again, some experimenting could be done
with cooperating ends...Alex
> 
> >Service providers at the edge
> >have direct requirements to limit flows, because their connections to the
> >network core are more limited than the aggregate flows they might have to
> >send/receive for subscribers.
> 
> I am not sure I understand this statement. Could you rephrase it?
...Folks like Covad have from their beginnings known that they could not make
$ without oversubscription, simply because their co-location in telco offices
relies on the links between offices and eventually into the rest of the packet
network.  The links among offices are choke points because they were designed
to handle voice to/from most all subscribers at once, but not data.  So, the
providers who entered the DSL/ADSL market sold about 20 times the real
back-end capacity -- this was the common business model.  As local Bells grow
more into data services, the links among their nodes are improved, but the
current status is that the edge of the net is oversubscribed and that's where
boxes doing traffic management drop pkts. In the synchronous subnets (e.g.,
Sonet rings), Add-Drop Muxes limit flows into metro rings in the same ways
(and can backpressure router interfaces). Hope this clears it up...Alex
> 
> Thoughts?
> 
> Thanks, Alex.
> 
> PS: The DTN website is www.dtnrg.org
> 
> ---------- Forwarded message ----------
> Date: Thu, 01 May 2003 16:43:18 -0700
> From: Cannara <[email-masked]>
> To: [email-masked]
> Subject: Re: [e2e] High Packet Loss and TCP
> 
> Durga, let me mention some experience with some real products developed for
> the network edge/interior, whether security & load balancing, or just simple
> routing...
> 
> 1) The devices used now, Network Processors, Fabric Switches & Traffic
> Managers, allow firmware setting of a wide variety of policies:  priority
> queuing, weighted dropping and other forms of flow control outbound (to the
> next interface/hop).  Traffic manager chips now available can do this for a
> few hundred-thousand flows at multi-Gb rates.
> 
> 2) The device input paths allow for a variety of hardware/Layer2 flow
> control
> (e.g., CSIX, SPI4.2, etc.).
> 
> So, congestion is observed locally (within a box, a rack, or within a site)
> in
> a packet environment; and over MUXes on a metro ring, in a Sonet-like
> environment.  This means that you can often acquire congestion info from
> such
> devices within portions of any network path.  Service providers at the edge
> have direct requirements to limit flows, because their connections to the
> network core are more limited than the aggregate flows they might have to
> send/receive for subscribers.
> 
> Because "rate limiting", "traffic shaping", or whatever other nice words are
> used for "packet dropping", provide the only way edge folks currently have
> to
> tell leaves in the net to slow down, this means that congestion exists at
> two
> major spots:  edge services and core distribution (peering) points.  If you
> were only to look at these places for congestion data, you'd do pretty well,
> especially if you picked busy times for Inet traffic (e.g., daily cycles, or
> as when the Monica Lewinsky report went out :).  I don't think simulations
> will quite capture the reality of what goes on.  You might identify some
> spots
> to examine and ask for data from various researchers, like the SLAC
> "ping-around-the-world" folks (Cottrell...).
> 
> Alex
> 
> Durga Prasad Pandey wrote:
> >
> > I am looking into the possibility of congestion in a delay tolerant
> > network(Characterized by high latency, intermittent connectivity, and high
> > error rates). Since I am new to this area, could I ask for suggestions on
> > how to approach the task of checking congestion in the network as a whole?
> > In other words, if we define congestion to occur when the net amount of
> > data flowing into a network through various nodes is greater than the net
> > amount of data flowing out, what parametsrs would one use to identify
> > congestion?
> > Another question is: Are there some free network simulators available on
> > the web?
> >
> > I will appreciate any help.
> >
> > Durga

Date: Fri, 2 May 2003 13:31:52 -0400 (EDT)
From: Durga Prasad Pandey <[email-masked]>
To: "Fall, Kevin R" <[email-masked]>
Cc: "Adrian J. Hooke" <[email-masked]>, <[email-masked]>
Subject: [dtn-interest] RE: ?
Sender: [email-masked]

No it didn't bounce.
I just checked out the dtn archives and the mail is very much there. But 
somehow it didn't come into my inbox,.
Let me send this to dtn-interest and check it out.
By the way, what type of redundancy will be required to have an 
acceptable performance in a DTN(quantitatively speaking)?

DurgaOn Fri, 2 May 
2003, Fall, Kevin R 
wrote:

> I have no idea.  I don't see any problems.  Did it bounce, or what?
> 
> - K
> 
> -----Original Message-----
> From: Adrian J. Hooke [mailto:[email-masked]] 
> Sent: Friday, May 02, 2003 9:36 AM
> To: Kevin Fall (contact); Kevin Fall (contact); Fall, Kevin R
> Subject: ?
> 
> 
> >Date: Fri, 02 May 2003 12:16:49 -0400
> >From: "[email-masked]" <[email-masked]>
> >Subject:
> >X-Originating-IP: 203.197.117.229
> >To: [email-masked], [email-masked], [email-masked]
> >Reply-to: [email-masked]
> >Original-recipient: rfc822;[email-masked]
> >X-OriginalArrivalTime: 02 May 2003 16:16:26.0650 (UTC)
> >  FILETIME=[2E8457A0:01C310C6]
> >
> >The reason why the discussion isn't on dtn-interest is because
> dtn-interest
> >seems to be screening off my mails, for some reason not clear to me. I
> have
> >sent 2 mails that haven't been through the list,(they didn't reach my
> >inbox, at least).
> >
> >Durga
> 
> 

-- 
Durga Prasad Pandey
Assistant Online Editor, ACM Crossroads
[email-masked]

Reply-To: Durga Prasad Pandey<[email-masked]>
From: "[email-masked]" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 2 May 2003 09:45:05 -0400
Subject: [dtn-interest] Re: [e2e] High Packet Loss and TCP
Sender: [email-masked]

>This means that you can often acquire congestion info from such
>devices within portions of any network path.  

How exactly is the congestion info acquired? In the context of a delay
tolerant network(DTN), we cannot use 'chatty' protocols, as they consume
valuable bandwidth. Looking at the techniques that are used in the normal
Internet:

1) Packet dropping: It is likely to go undetected for a long time, since 
the DTN model is very optimistic when it sends packets. To put it in
another way, there is a high expectation that the packet will reach the
destination. Thus the lifetimes of packets are long, compared to TCP
packets. 

2) Notification by setting a bit in a returning packet(piggybacking): Since
the connection is intermittent(and scheduled), I am not sure how much
really we can rely on this technique. It still has some scope, depending on
the availability of a packet on the return path.

3) Explicit notification by a choke packet: This will have to the last
resort, though a costly one. 

>Service providers at the edge
>have direct requirements to limit flows, because their connections to the
>network core are more limited than the aggregate flows they might have to
>send/receive for subscribers.  

I am not sure I understand this statement. Could you rephrase it?

Thoughts?

Thanks, Alex. 

PS: The DTN website is www.dtnrg.org

---------- Forwarded message ----------
Date: Thu, 01 May 2003 16:43:18 -0700
From: Cannara <[email-masked]>
To: [email-masked]
Subject: Re: [e2e] High Packet Loss and TCP

Durga, let me mention some experience with some real products developed for
the network edge/interior, whether security & load balancing, or just simple
routing...

1) The devices used now, Network Processors, Fabric Switches & Traffic
Managers, allow firmware setting of a wide variety of policies:  priority
queuing, weighted dropping and other forms of flow control outbound (to the
next interface/hop).  Traffic manager chips now available can do this for a
few hundred-thousand flows at multi-Gb rates.

2) The device input paths allow for a variety of hardware/Layer2 flow
control
(e.g., CSIX, SPI4.2, etc.).

So, congestion is observed locally (within a box, a rack, or within a site)
in
a packet environment; and over MUXes on a metro ring, in a Sonet-like
environment.  This means that you can often acquire congestion info from
such
devices within portions of any network path.  Service providers at the edge
have direct requirements to limit flows, because their connections to the
network core are more limited than the aggregate flows they might have to
send/receive for subscribers.  

Because "rate limiting", "traffic shaping", or whatever other nice words are
used for "packet dropping", provide the only way edge folks currently have
to
tell leaves in the net to slow down, this means that congestion exists at
two
major spots:  edge services and core distribution (peering) points.  If you
were only to look at these places for congestion data, you'd do pretty well,
especially if you picked busy times for Inet traffic (e.g., daily cycles, or
as when the Monica Lewinsky report went out :).  I don't think simulations
will quite capture the reality of what goes on.  You might identify some
spots
to examine and ask for data from various researchers, like the SLAC
"ping-around-the-world" folks (Cottrell...).

Alex

Durga Prasad Pandey wrote:
> 
> I am looking into the possibility of congestion in a delay tolerant
> network(Characterized by high latency, intermittent connectivity, and high
> error rates). Since I am new to this area, could I ask for suggestions on
> how to approach the task of checking congestion in the network as a whole?
> In other words, if we define congestion to occur when the net amount of
> data flowing into a network through various nodes is greater than the net
> amount of data flowing out, what parametsrs would one use to identify
> congestion?
> Another question is: Are there some free network simulators available on
> the web?
> 
> I will appreciate any help.
> 
> Durga

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Reply-To: [email-masked]
From: "[email-masked]" <[email-masked]>
To: [email-masked]
Date: Thu, 1 May 2003 12:07:39 -0400
Subject: [dtn-interest] Thoughts and queries on congestion in a DTN
Sender: [email-masked]

Here are some thoughts and questions on congestion in a DTN(with some
inclination towards IPN):

1. When a router receives packets faster than it can receive, congestion
might occur.

When will it occur: If the net difference between the rate at which the
router/node is receiving packets, and the rate at which it can process and
forward them is such that the delay causes the  packets to expire, or
delays it so that its TTL is less than the mean(to be determined) time to
the destination, then there is a net loss due to congestion.

When it won't occur:  In the above situation, if the delay is not
sufficient to make the packets time out, then congestion won't be there
because the packets will be reaching their destination within their TTL.
This sounds like a repitition of the statement above, but I thought of
clearing layout out the two cases.

Thus, at any node, if the TTL is less than the time to destination from
that node, the packet/(bundle in this context)  must be dropped
immediately. Otherwise it will use up resources, and will ultimately time
out anyway before reaching the destination.

2. Insufficient buffer space on a node can cause congestion. Let's take an
example:

A(Mars) <-----------> B <-----------> C <------------->
D<----------->(Earth)
           (1 Mbps)         (64 kbps)      (32 kbps)       (1 Mbps)

Suppose we have a network where A(Mars) sends bundles to E(Earth). (The
values in brackets denote the speed of links.)
Suppose A collects a lot of pictures and weather data and starts
transmitting it on the A-B link. Since we are using a 'structural' end to
end flow control mechanism, the data output rate from A is restricted to 32
Kbps. 
Result: Gross underutilisation of bandwidth.

Now suppose there is an unexpected solar flares and other disturbance on
the C-D link, so that the throughput reduces to very less(say, 25%) of its
normal value.

What's likely to happen: A  lot of data will end up on the buffers of Node
C, which might overflow(blame custodial transfer commitments to which C is
tied). Thus there will be congestion, even though we have a flow control
mechanism.

The software on C might be programmed such that it realises that something
is wrong, and slows down it's output rate.. But that's hardly going to help
in this scenario. It will in fact reduce the utilisation of the link.
On the other hand, if the flow control mechanism actually allows data rates
greater than 32 Kbps(minimum on the link) , then the congestion is only
likely to get worse.
(Values of data rates are for qualitative analysis only).

3. Congestion on a network can be compared to traffic congestion in a city.
I have a hunch that the problem of whether or not congestion will occur,
could benefit from  research on traffic congestion, or it could be a
mathematical problem that could be attempted using flow models(such as
liquid flow, or heat flow). Are you aware of any such approaches in solving
this problem?

4. What software is generally used for simulation in this context? Will I
need to design a software from scratch, or is there a package already
available? A simulation could speed up work by taking things from
speculation to testing.

5. Does the Bundling reference model envisage a link layer, where the
equivalent of 'framing' on terrestrial internet could be done?
If Yes: then doesn't this come into conflict with our idea of using large
bundles? If FEC is there, why use framing at all?

If not: In the TCP/IP model, framing is vital, because if a frame is lost
in transit, it is a much smaller loss compared to a loss of a packet(byte
wise speaking). So by not using frames, aren't we losing the opportunity to
minimise loss due to complete bundle losses?

6. Which layer(s) in the Bundling reference model do we expect to provide
us Flow Control?

7. I would like to understand the significance of checking if "the network
as a whole is not congested when we use hop by hop backward propagation of
flow control'. 
Why are we looking at the network as a whole? Is it for reference/benchmark
purposes?

8. I have seen a lot of work on congestion control, but there is little
reference to congestion control in the overall network. Are you aware of
any work on this?

Congratulations! You have one good quality: Patience :)

Cheers!
Durga

--
Durga Prasad Pandey
Assistant Online Editor
ACM Crossroads, www.acm.org/crossroads/

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date: Thu, 01 May 2003 16:32:21 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN security model
Sender: [email-masked]

All,

In the comments I sent on the architecture I was a little
critical of the security model as reflected in the documents
so far. So, to be fair, I probably ought to pop my own head
over the parapet rather than sniping from the sidelines
or hurling on the ditch (a beer in LA for anyone who can
correctly unmix those metaphors:-)

Anyway, I've now made a stab at that [1], so feel free to
tell me I'm dumb.

Regards,
Stephen.

[1] http://down.dsg.cs.tcd.ie/ipn/models/dtnsec.html