Subject: Re: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
From: "Lawrence C. Freudinger" <[email-masked]>
To: Micah Beck <[email-masked]>
Cc: "Adrian J. Hooke" <[email-masked]>, [email-masked]
Date: Sun, 20 Jun 2004 22:14:41 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

All:

I'd be interested in hearing what others have to say about DTN and its
relationship to evolution of broadly useful buffering layer(s) for network
communications.  I believe I read an old paper where someone lamented it was a
mistake to not put a buffering layer into the Internet the beginning... maybe
DTN will be the path through which the buffering layer idea is carefully
revisited.

Best regards,
larry

Micah Beck wrote:

> []
> The question I would pose to the delay/disruption tolerant networking
> community is whether the current DTN model (bundles, custody transfer, late
> binding) appropriately supports all of the services that are now and will in
> future be required?  If not, are we sure that any variant of the currently
> defined service can be flexible enough to serve such diverse purposes?  Or
> is it possible that a store-and-forward convergence layer, implemented as a
> generic model of buffers and services, is required below the DTN layer to
> act as a basis for interoperability?
> []
>
> Intelligence, fault tolerance and other heavyweight services may be required
> in DTN, but history has shown that attention to appropriate layering at the
> lower layers, with an eye towards issues of interoperability, are the
> foundation of success for any scalable network.

[]

From: "Micah Beck" <[email-masked]>
To: "Lawrence C. Freudinger" <[email-masked]>, "Adrian J. Hooke" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
Date: Sun, 20 Jun 2004 13:54:58 -0400
Sender: [email-masked]

Hi Larry, Adrian and everyone!

Larry describes the differing views of data buffering taken by DTN and RBNB
as follows:

--- Begin quote ---
DTN is basically for routing across disconnected transport mechanisms,
whereas RBNB is basically for routing across  disconnected applications.

Whereas TCP objects being managed are packets, DTN manages finite-size
messages called bundles.  RBNB manages finite-size objects called RMaps.
DTN implements features to manage the delivery of the bundle with classes of
service analogous to the Postal system, whereas RBNB has in general used the
underlying TCP transport for delivery of the RMap.  In DTN a bundle seems to
be standalone, where in RBNB successive RMaps create a stream and are
managed in configurable ring buffers.
Both DTN and RBNB implicitly agree that the store & forward model is a good
idea, DTN for messaging, RBNB for message streams.
--- End quote ---

He also proposes an overlay "Buffering layer" that would put RBNB above DTN:

--- Begin quote ---
If we consider a "Buffering layer" above the transport layer that serves the
needs of sensor web applications across disconnected environments, what that
buffering layer needs are two complimentary sublayers.  The lower DTN layer
implements the intelligence to get the information across the difficult
hops, while the RBNB layer above DTN creates a distributed memory through
which producers and consumers interact.
--- End quote ---

This architectural approach assumes that model implmented by DTN is the
appropriate one for RBNB to be implemented on top of in a delay/disruption
tolerant environment.  If there are any aspects of the DTN model that are
not well suited to layering the RBNB streaming model on top of, RBNB will
have to take that part that fits well with that part that might fit less
well.

Another approach to addressing differing uses of store-and-forward in
delay/disruption-tolerant environments has been proposed, which is to
implement a highly generic buffering layer and implement DTN services *on
top of* it.  The buffer management protocol we have proposed to accomplish
this has been the Internet Backplane Protocol (IBP).  The buffer services
needed by DTN can then be implemented directly on top of IBP, and then the
current DTN services can be implemented on top of those.

The benefit of this approach is that, since IBP is highly generic, the
buffering services so implemented can also be quite generic, and can be
applied to high level models that are quite different.  We proposed this
architectural approach to the IPN Research Group a long time ago at a
meeting in Anapolis (Eric Travis was there; I have forgotten the year) as a
way of enabling the storage resources that underlie IPN to be used for more
diverse purposes than just messaging.  At the time, if was felt that IPN was
destined to be single-purpose due to the restrictions of deep space
missions.  We have continued to suggest this approach to the DTN community
whenever an occassion presented itself, for example at the Space Interenet
Workshop in 2003 (http://www.cs.utk.edu/~mbeck/isw-03.pdf) and at the
DTN proposers day in 2004 (http://www.cs.utk.edu/~mbeck/dtn-04.pdf).

More information on IBP is avilable at the LoCI lab Web site
http://loci.cs.utk.edu

The issue  we see with requiring that every service in the delay/distruption
tolerant environment be layered over the a single model of DTN services is
the possibility that some services might have conflicting requirements.  We
propose using IBP as a more primitive, generic "convergence layer" on which
common services can be implemented.  These common services can then be used
in the implementation of highly diverse high level services.

The question I would pose to the delay/disruption tolerant networking
community is whether the current DTN model (bundles, custody transfer, late
binding) appropriately supports all of the services that are now and will in
future be required?  If not, are we sure that any variant of the currently
defined service can be flexible enough to serve such diverse purposes?  Or
is it possible that a store-and-forward convergence layer, implemented as a
generic model of buffers and services, is required below the DTN layer to
act as a basis for interoperability?

If the idea of such an interoperable buffer management layer makes sense to
you, then I suggest looking into IBP as a possible mechanism.  IBP is very
primitive, its implementation is open source and its specification is going
to be submitted to the IETF as an informational RFC.  IBP has
implementations on a variety of execution platforms, and the client has been
reimplemented in multiple languages.  IBP is deployed globally over
infrastructure that includes but is not limited to PlanetLab, with up to 300
, managing storage up to 30TB.  Dept of Energy application communities
including Fusion and Astrophysics simulation are relying on it as a
mechanism for managing massive datasets in the high performance network.  It
also supports a public content distribution network that is used to
distributed Linux ISOs among other purposes.

Intelligence, fault tolerance and other heavyweight services may be required
in DTN, but history has shown that attention to appropriate layering at the
lower layers, with an eye towards issues of interoperability, are the
foundation of success for any scalable network.

Micah Beck
Associate Professor, Computer Science
Director, Logistical Computing and Internetworking Lab
University of Tennessee

----- Original Message ----- 
From: Lawrence C. Freudinger
To: Adrian J. Hooke
Cc: [email-masked]
Sent: Saturday, June 19, 2004 4:38 AM
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of
fragmentation)?

"Adrian J. Hooke" wrote:
At 10:47 AM 6/16/2004, Matt Miller wrote:
... But whereas DTN seems to focus on message (bundle) delivery, RBNB
focuses on sequenced (e.g. streaming) data..... I would appreciate any
insight as to how these technologies may be complementary.

Keith Scott and I had a chat with Larry at lunch on Wednesday, and I think
that we are in agreement that the two technologies align very
well[...]Larry - any comments?
[...]
Adrian:
The comparison between DTN & RBNB is incomplete.  You're right about the
fact that they are complimentary, but why this is the case will take some
discussion.  I'll give it a shot, but I'll preface it by requesting
forgiveness if I make a mistake and say things that are just plain wrong.
Hopefully I'll add value but the conversation needs to continue.
The short answer is that both technologies combine to create a basic
buffering layer above the transport layer.
DTN is a routing and transport service when a distributed cache is the only
way to get from point A to point B.  It's the only way when there is no
end-to-end connectivity,  either because (simplified thinking) the
end-to-end link is broken for significant or infinite amounts of time or two
or more endpoints don't speak the same language.  Necessary features of a
DTN architecture include
- Transfer of responsibility to intermediate nodes,
- a security model, and a
- naming scheme that eliminates dependence on any underlying network naming
or addressing scheme.
RBNB is a distributed caching service when multiple applications distributed
over a network need to share multiple datasets.  Necessary features of an
RBNB architecture include
- The ability to dynamically combine, dissect, distribute, and recombine
channels of possibly time-varying datasets, and
- a dataset naming or addressing scheme that eliminates dependence on the
underlying network addressing scheme
- A security model that doesn't hamper high performance streaming operations
DTN is basically for routing across disconnected transport mechanisms,
whereas RBNB is basically for routing across disconnected applications.
Whereas TCP objects being managed are packets, DTN manages finite-size
messages called bundles.  RBNB manages finite-size objects called RMaps.
DTN implements features to manage the delivery of the bundle with classes of
service analogous to the Postal system, whereas RBNB has in general used the
underlying TCP transport for delivery of the RMap.  In DTN a bundle seems to
be standalone, where in RBNB successive RMaps create a stream and are
managed in configurable ring buffers.
Both DTN and RBNB implicitly agree that the store & forward model is a good
idea, DTN for messaging, RBNB for message streams.
The DTN architecture defines a "network of internets" comprised of  "DTN
regions."  An RBNB architecture defines a  network of dynamically accessible
memory.  The counterpart to the DTN region is simply called a "parent
 server" in the RBNB world, although the use of tuples for opaque namespace
management within a region might not have a counterpart in RBNB.
Once a bundle is delivered successfully to its destination, the DTN
infrastructure generally releases custody (the bundle is purged).  In the
RBNB network, only the source or administrative functions can purge the
Rmap.  In other words, bundles (Rmaps) do not get purged simply because of
successful downstream delivery.  Consumers can only read what producers
write, and an RBNB network could in fact be used as a long term storage
mechanism (network memory+filesystem).
So, how might these two ideas be complimentary?
If we consider a "Buffering layer" above the transport layer that serves the
needs of sensor web applications across disconnected environments, what that
buffering layer needs are two complimentary sublayers.  The lower DTN layer
implements the intelligence to get the information across the difficult
hops, while the RBNB layer above DTN creates a distributed memory through
which producers and consumers interact.
The {DTN-enabled, RBNB-enabled} buffering layer is what I see as a missing
link for sensor webs.  RBNB enables the signal processing to be distributed,
while DTN enables the distribution to occur over heterogeneous and
challenging communications environments.
The interface between the buffering layer and the application should have
mechanisms to enable queries to the infrastructure so it can adapt (e.g. the
application needs to adjust behavior to match the quantity or quality of
bandwidth. or the DTN sublayer tells the application when it expects the
link to come back up).  I think I'm wandering off subject...
In my mind these two components as they exist now are just the beginning.  I
see the emergence over time of intelligent, adaptive mechanisms in the
buffering layer and a larger, more diverse set of intelligent, adaptive
management services above the buffering layer.  That's a few years down the
road.
best regards,
larry
______________________
Lawrence C. Freudinger
Lead, Measurement Process Automation
 NASA Dryden Flight Research Center
 Edwards, California 93523-0273, USA
 Mail Stop M:1623A
 Ph: +1.661.276.3542
 Fx: +1.661.276.5819
 Em: "Larry Freudinger" <[email-masked]>
_____________________

----- Original Message ----- 
From: Lawrence C. Freudinger
To: Adrian J. Hooke
Cc: [email-masked]
Sent: Saturday, June 19, 2004 4:38 AM
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of
fragmentation)?

"Adrian J. Hooke" wrote:
At 10:47 AM 6/16/2004, Matt Miller wrote:
... But whereas DTN seems to focus on message (bundle) delivery, RBNB
focuses on sequenced (e.g. streaming) data..... I would appreciate any
insight as to how these technologies may be complementary.

Keith Scott and I had a chat with Larry at lunch on Wednesday, and I think
that we are in agreement that the two technologies align very
well[...]Larry - any comments?
[...]
Adrian:
The comparison between DTN & RBNB is incomplete.  You're right about the
fact that they are complimentary, but why this is the case will take some
discussion.  I'll give it a shot, but I'll preface it by requesting
forgiveness if I make a mistake and say things that are just plain wrong.
Hopefully I'll add value but the conversation needs to continue.
The short answer is that both technologies combine to create a basic
buffering layer above the transport layer.
DTN is a routing and transport service when a distributed cache is the only
way to get from point A to point B.  It's the only way when there is no
end-to-end connectivity,  either because (simplified thinking) the
end-to-end link is broken for significant or infinite amounts of time or two
or more endpoints don't speak the same language.  Necessary features of a
DTN architecture include
- Transfer of responsibility to intermediate nodes,
- a security model, and a
- naming scheme that eliminates dependence on any underlying network naming
or addressing scheme.
RBNB is a distributed caching service when multiple applications distributed
over a network need to share multiple datasets.  Necessary features of an
RBNB architecture include
- The ability to dynamically combine, dissect, distribute, and recombine
channels of possibly time-varying datasets, and
- a dataset naming or addressing scheme that eliminates dependence on the
underlying network addressing scheme
- A security model that doesn't hamper high performance streaming operations
DTN is basically for routing across disconnected transport mechanisms,
whereas RBNB is basically for routing across disconnected applications.
Whereas TCP objects being managed are packets, DTN manages finite-size
messages called bundles.  RBNB manages finite-size objects called RMaps.
DTN implements features to manage the delivery of the bundle with classes of
service analogous to the Postal system, whereas RBNB has in general used the
underlying TCP transport for delivery of the RMap.  In DTN a bundle seems to
be standalone, where in RBNB successive RMaps create a stream and are
managed in configurable ring buffers.
Both DTN and RBNB implicitly agree that the store & forward model is a good
idea, DTN for messaging, RBNB for message streams.
The DTN architecture defines a "network of internets" comprised of  "DTN
regions."  An RBNB architecture defines a  network of dynamically accessible
memory.  The counterpart to the DTN region is simply called a "parent
 server" in the RBNB world, although the use of tuples for opaque namespace
management within a region might not have a counterpart in RBNB.
Once a bundle is delivered successfully to its destination, the DTN
infrastructure generally releases custody (the bundle is purged).  In the
RBNB network, only the source or administrative functions can purge the
Rmap.  In other words, bundles (Rmaps) do not get purged simply because of
successful downstream delivery.  Consumers can only read what producers
write, and an RBNB network could in fact be used as a long term storage
mechanism (network memory+filesystem).
So, how might these two ideas be complimentary?
If we consider a "Buffering layer" above the transport layer that serves the
needs of sensor web applications across disconnected environments, what that
buffering layer needs are two complimentary sublayers.  The lower DTN layer
implements the intelligence to get the information across the difficult
hops, while the RBNB layer above DTN creates a distributed memory through
which producers and consumers interact.
The {DTN-enabled, RBNB-enabled} buffering layer is what I see as a missing
link for sensor webs.  RBNB enables the signal processing to be distributed,
while DTN enables the distribution to occur over heterogeneous and
challenging communications environments.
The interface between the buffering layer and the application should have
mechanisms to enable queries to the infrastructure so it can adapt (e.g. the
application needs to adjust behavior to match the quantity or quality of
bandwidth. or the DTN sublayer tells the application when it expects the
link to come back up).  I think I'm wandering off subject...
In my mind these two components as they exist now are just the beginning.  I
see the emergence over time of intelligent, adaptive mechanisms in the
buffering layer and a larger, more diverse set of intelligent, adaptive
management services above the buffering layer.  That's a few years down the
road.
best regards,
larry
______________________
Lawrence C. Freudinger
Lead, Measurement Process Automation
 NASA Dryden Flight Research Center
 Edwards, California 93523-0273, USA
 Mail Stop M:1623A
 Ph: +1.661.276.3542
 Fx: +1.661.276.5819
 Em: "Larry Freudinger" <[email-masked]>
_____________________

Date: Sat, 19 Jun 2004 01:38:37 -0700
From: "Lawrence C. Freudinger" <[email-masked]>
To: "Adrian J. Hooke" <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
Sender: [email-masked]

--------------3641C7EC9C38BA72BCBC6952
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

"Adrian J. Hooke" wrote:

> At 10:47 AM 6/16/2004, Matt Miller wrote:
>
>> ... But whereas DTN seems to focus on message (bundle) delivery,
>> RBNB focuses on sequenced (e.g. streaming) data..... I would
>> appreciate any insight as to how these technologies may be
>> complementary.
>
>
> Keith Scott and I had a chat with Larry at lunch on Wednesday, and I
> think that we are in agreement that the two technologies align very
> well[...]Larry - any comments?

[...]

Adrian:

The comparison between DTN & RBNB is incomplete.  You're right about the
fact that they are complimentary, but why this is the case will take
some discussion.  I'll give it a shot, but I=92ll preface it by requestin=
g
forgiveness if I make a mistake and say things that are just plain
wrong.   Hopefully I'll add value but the conversation needs to
continue.

The short answer is that both technologies combine to create a basic
buffering layer above the transport layer.

DTN is a routing and transport service when a distributed cache is the
only way to get from point A to point B.  It=92s the only way when there
is no end-to-end connectivity,  either because (simplified thinking) the
end-to-end link is broken for significant or infinite amounts of time or
two or more endpoints don=92t speak the same language.  Necessary feature=
s
of a DTN architecture include
- Transfer of responsibility to intermediate nodes,
- a security model, and a
- naming scheme that eliminates dependence on any underlying network
naming or addressing scheme.

RBNB is a distributed caching service when multiple applications
distributed over a network need to share multiple datasets.  Necessary
features of an RBNB architecture include
- The ability to dynamically combine, dissect, distribute, and recombine
channels of possibly time-varying datasets, and
- a dataset naming or addressing scheme that eliminates dependence on
the underlying network addressing scheme
- A security model that doesn=92t hamper high performance streaming
operations

DTN is basically for routing across disconnected transport mechanisms,
whereas RBNB is basically for routing across disconnected applications.

Whereas TCP objects being managed are packets, DTN manages finite-size
messages called bundles.  RBNB manages finite-size objects called
RMaps.  DTN implements features to manage the delivery of the bundle
with classes of service analogous to the Postal system, whereas RBNB has
in general used the underlying TCP transport for delivery of the RMap.
In DTN a bundle seems to be standalone, where in RBNB successive RMaps
create a stream and are managed in configurable ring buffers.

Both DTN and RBNB implicitly agree that the store & forward model is a
good idea, DTN for messaging, RBNB for message streams.

The DTN architecture defines a "network of internets" comprised of  "DTN
regions."  An RBNB architecture defines a  network of dynamically
accessible memory.  The counterpart to the DTN region is simply called a
=93parent server=94 in the RBNB world, although the use of tuples for opa=
que
namespace management within a region might not have a counterpart in
RBNB.

Once a bundle is delivered successfully to its destination, the DTN
infrastructure generally releases custody (the bundle is purged).  In
the RBNB network, only the source or administrative functions can purge
the Rmap.  In other words, bundles (Rmaps) do not get purged simply
because of successful downstream delivery.  Consumers can only read what
producers write, and an RBNB network could in fact be used as a long
term storage mechanism (network memory+filesystem).

So, how might these two ideas be complimentary?

If we consider a =93Buffering layer=94 above the transport layer that ser=
ves
the needs of sensor web applications across disconnected environments,
what that buffering layer needs are two complimentary sublayers.  The
lower DTN layer implements the intelligence to get the information
across the difficult hops, while the RBNB layer above DTN creates a
distributed memory through which producers and consumers interact.

The {DTN-enabled, RBNB-enabled} buffering layer is what I see as a
missing link for sensor webs.  RBNB enables the signal processing to be
distributed, while DTN enables the distribution to occur over
heterogeneous and challenging communications environments.

The interface between the buffering layer and the application should
have mechanisms to enable queries to the infrastructure so it can adapt
(e.g. the application needs to adjust behavior to match the quantity or
quality of bandwidth=85 or the DTN sublayer tells the application when it=

expects the link to come back up).  I think I'm wandering off subject...

In my mind these two components as they exist now are just the
beginning.  I see the emergence over time of intelligent, adaptive
mechanisms in the buffering layer and a larger, more diverse set of
intelligent, adaptive management services above the buffering layer.
That's a few years down the road.

best regards,
larry

______________________
Lawrence C. Freudinger
Lead, Measurement Process Automation

 NASA Dryden Flight Research Center
 Edwards, California 93523-0273, USA
 Mail Stop M:1623A
 Ph: +1.661.276.3542
 Fx: +1.661.276.5819
 Em: "Larry Freudinger" <[email-masked]>
_____________________

--------------3641C7EC9C38BA72BCBC6952
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"Adrian J. Hooke" wrote:
<blockquote TYPE=3DCITE><font color=3D"#0000FF">At 10:47 AM 6/16/2004, Ma=
tt
Miller wrote:</font>
<blockquote type=3Dcite class=3Dcite cite><font color=3D"#0000FF">... But=
 whereas
DTN seems to focus on message (bundle) delivery, RBNB focuses on sequence=
d
(e.g. streaming) data..... I would appreciate any insight as to how these=

technologies may be complementary.</font></blockquote>

<p><br>Keith Scott and I had a chat with Larry at lunch on Wednesday, and=

I think that we are in agreement that the two technologies align very wel=
l[...]Larry
- any comments?</blockquote>
[...]
<p>Adrian:
<p>The comparison between DTN &amp; RBNB is incomplete.&nbsp; You're righ=
t
about the fact that they are complimentary, but why this is the case will=

take some discussion.&nbsp; I'll give it a shot, but I=92ll preface it by=

requesting forgiveness if I make a mistake and say things that are just
plain wrong.&nbsp;&nbsp; Hopefully I'll add value but the conversation
needs to continue.
<p>The short answer is that both technologies combine to create a basic
buffering layer above the transport layer.
<p>DTN is a routing and transport service when a distributed cache is the=

only way to get from point A to point B.&nbsp; It=92s the only way when t=
here
is no end-to-end connectivity,&nbsp; either because (simplified thinking)=

the end-to-end link is broken for significant or infinite amounts of time=

or two or more endpoints don=92t speak the same language.&nbsp; Necessary=

features of a DTN architecture include
<br>- Transfer of responsibility to intermediate nodes,
<br>- a security model, and a
<br>- naming scheme that eliminates dependence on any underlying network
naming or addressing scheme.
<p>RBNB is a distributed caching service when multiple applications distr=
ibuted
over a network need to share multiple datasets.&nbsp; Necessary features
of an RBNB architecture include
<br>- The ability to dynamically combine, dissect, distribute, and recomb=
ine
channels of possibly time-varying datasets, and
<br>- a dataset naming or addressing scheme that eliminates dependence
on the underlying network addressing scheme
<br>- A security model that doesn=92t hamper high performance streaming o=
perations
<p>DTN is basically for routing across disconnected transport mechanisms,=

whereas RBNB is basically for routing across disconnected applications.
<p>Whereas TCP objects being managed are packets, DTN manages finite-size=

messages called bundles.&nbsp; RBNB manages finite-size objects called
RMaps.&nbsp; DTN implements features to manage the delivery of the bundle=

with classes of service analogous to the Postal system, whereas RBNB has
in general used the underlying TCP transport for delivery of the RMap.&nb=
sp;
In DTN a bundle seems to be standalone, where in RBNB successive RMaps
create a stream and are managed in configurable ring buffers.
<p>Both DTN and RBNB implicitly agree that the store &amp; forward model
is a good idea, DTN for messaging, RBNB for message streams.
<p>The DTN architecture defines a "network of internets" comprised of&nbs=
p;
"DTN regions."&nbsp; An RBNB architecture defines a&nbsp; network of dyna=
mically
accessible memory.&nbsp; The counterpart to the DTN region is simply call=
ed
a =93parent server=94 in the RBNB world, although the use of tuples for o=
paque
namespace management within a region might not have a counterpart in RBNB=
=2E
<p>Once a bundle is delivered successfully to its destination, the DTN
infrastructure generally releases custody (the bundle is purged).&nbsp;
In the RBNB network, only the source or administrative functions can purg=
e
the Rmap.&nbsp; In other words, bundles (Rmaps) do not get purged simply
because of successful downstream delivery.&nbsp; Consumers can only read
what producers write, and an RBNB network could in fact be used as a long=

term storage mechanism (network memory+filesystem).
<p>So, how might these two ideas be complimentary?
<p>If we consider a =93Buffering layer=94 above the transport layer that =
serves
the needs of sensor web applications across disconnected environments,
what that buffering layer needs are two complimentary sublayers.&nbsp;
The lower DTN layer implements the intelligence to get the information
across the difficult hops, while the RBNB layer above DTN creates a distr=
ibuted
memory through which producers and consumers interact.
<p>The {DTN-enabled, RBNB-enabled} buffering layer is what I see as a mis=
sing
link for sensor webs.&nbsp; RBNB enables the signal processing to be dist=
ributed,
while DTN enables the distribution to occur over heterogeneous and challe=
nging
communications environments.
<p>The interface between the buffering layer and the application should
have mechanisms to enable queries to the infrastructure so it can adapt
(e.g. the application needs to adjust behavior to match the quantity or
quality of bandwidth=85 or the DTN sublayer tells the application when it=

expects the link to come back up).&nbsp; I think I'm wandering off subjec=
t...
<p>In my mind these two components as they exist now are just the beginni=
ng.&nbsp;
I see the emergence over time of intelligent, adaptive mechanisms in the
buffering layer and a larger, more diverse set of intelligent, adaptive
management services above the buffering layer.&nbsp; That's a few years
down the road.
<p>best regards,
<br>larry
<p>______________________
<br>Lawrence C. Freudinger
<br>Lead, Measurement Process Automation
<p>&nbsp;NASA Dryden Flight Research Center
<br>&nbsp;Edwards, California 93523-0273, USA
<br>&nbsp;Mail Stop M:1623A
<br>&nbsp;Ph: +1.661.276.3542
<br>&nbsp;Fx: +1.661.276.5819
<br>&nbsp;Em: "Larry Freudinger" &lt;[email-masked]>
<br>_____________________
<br>&nbsp;</html>

--------------3641C7EC9C38BA72BCBC6952--

Date: Fri, 18 Jun 2004 10:22:43 -0700
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
Cc: [email-masked]
Sender: [email-masked]

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

At 10:47 AM 6/16/2004, Matt Miller wrote:
>......I am an inventor of RBNB (http://rbnb.creare.com), notably  the 
>inspiration for the "whirly-gig" DTN icon

Matt: yes, many thanks for what we thought was a really neat icon, and for 
the permission that Larry Freudinger gave us in early 2003 to adapt it for 
DTNRG use.

>... But whereas DTN seems to focus on message (bundle) delivery, RBNB 
>focuses on sequenced (e.g. streaming) data..... I would appreciate any 
>insight as to how these technologies may be complementary.

Keith Scott and I had a chat with Larry at lunch on Wednesday, and I think 
that we are in agreement that the two technologies align very well:

1. RBNB is middleware that can be used to capture and encapsulate a 
time-series of measurements at one place on the network.

2. DTN is an Application service that encapsulates and delivers the RBNB 
data sets across a (possibly disconnected) network.

3. RBNB reconstructs the time series for display at the user end.

So in the case of aircraft flight test, the little RBNB turbines would be 
gathering and capturing the the instantaneous state of the flight systems, 
the little DTN turbines would be moving each of those RBNB turbine 
snapshots across the onboard, air/ground and ground networks, and on the 
ground the little RBNB turbines would be re-sequencing the data and driving 
the displays that allow the ground analyst to be "telepresent" on the 
vehicle. The reverse flow would allow the user to drag-and-drop command 
data back up to the test article.

Larry - any comments?

Best regards
Adrian

Adrian J. Hooke
Principal Member of the Technical Staff
Interplanetary Network Directorate
Jet Propulsion Laboratory,
M/S 303-400, 4800 Oak Grove Drive
Pasadena, California 91109-8099, USA
+1.818.354.3063
--=====================_323606953==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font color="#0000FF">At 10:47 AM 6/16/2004, Matt Miller wrote:<br>
<blockquote type=cite class=cite cite>......I am an inventor of RBNB
(<a href="http://rbnb.creare.com/" eudora="autourl">http://rbnb.creare.com</a>),
notably&nbsp; the inspiration for the &quot;whirly-gig&quot; DTN icon
</font></blockquote><br>
Matt: yes, many thanks for what we thought was a really neat icon, and
for the permission that Larry Freudinger gave us in early 2003 to adapt
it for DTNRG use.<br><br>
<blockquote type=cite class=cite cite><font color="#0000FF">... But
whereas DTN seems to focus on message (bundle) delivery, RBNB focuses on
sequenced (e.g. streaming) data..... I would appreciate any insight as to
how these technologies may be complementary.</font></blockquote><br>
Keith Scott and I had a chat with Larry at lunch on Wednesday, and I
think that we are in agreement that the two technologies align very
well:<br><br>
1. RBNB is middleware that can be used to capture and encapsulate a
time-series of measurements at one place on the network.<br><br>
2. DTN is an Application service that encapsulates and delivers the RBNB
data sets across a (possibly disconnected) network.<br><br>
3. RBNB reconstructs the time series for display at the user
end.<br><br>
So in the case of aircraft flight test, the little RBNB turbines would be
gathering and capturing the the instantaneous state of the flight
systems, the little DTN turbines would be moving each of those RBNB
turbine snapshots across the onboard, air/ground and ground networks, and
on the ground the little RBNB turbines would be re-sequencing the data
and driving the displays that allow the ground analyst to be
&quot;telepresent&quot; on the vehicle. The reverse flow would allow the
user to drag-and-drop command data back up to the test article.<br><br>
Larry - any comments?<br><br>
Best regards<br>
Adrian<br>
<x-sigsep><p></x-sigsep>
Adrian J. Hooke<br>
Principal Member of the Technical Staff<br>
Interplanetary Network Directorate<br>
Jet Propulsion Laboratory, <br>
M/S 303-400, 4800 Oak Grove Drive<br>
Pasadena, California 91109-8099, USA<br>
+1.818.354.3063</html>

--=====================_323606953==_.ALT--

To: [email-masked]
Date: Fri, 18 Jun 2004 09:16:13 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fyi - IETF I-D Process Update
Sender: [email-masked]

------- Forwarded Message

>
> From:  Harald Alvestrand <[email-masked]>
> To:    IETF Announcement list <[email-masked]>
> cc:    
> Subject: New versions of guidelines for Internet-Drafts 
> Date:  Thu, 17 Jun 2004 18:29:24 EDT
>
> The IESG has emitted new versions of the following guideline documents:
> 
> "Guidelines to authors of Internet-Drafts"
> http://www.ietf.org/ietf/1id-guidelines.txt
> 
> which has been updated to reflect the new IPR policy RFCs (3667 and 3668):
> Note that in this process, we discovered a bug in one of the RFCs; the docume
nt 
> ontains a temporary fix, but the details of a permanent fix are still being 
> worked out on the IPR WG list.
> 
> "Checklist for Internet-Drafts submitted for RFC publication"
> http://www.ietf.org/ID-Checklist.html
> 
> This has had a more thorough review/revision, and should be re-read by all 
> participants. Note in particular the new language about IANA considerations.
> 
> (This was actually posted a month ago, but has not been announced to this lis
t 
> et, so I am including it in this announcement.)
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

------- End of Forwarded Message

Date: Thu, 17 Jun 2004 00:42:23 -0700
From: Melissa Ho <[email-masked]>
To: Matt Miller <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
Sender: [email-masked]

Hi Matt,

You are right in that DTN focuses on bundle delivery rather than 
sequenced/streaming data, and that bundle transfers are point to point 
(where each point is a dtn node, and a bundle may traverse multiple 
hops/points to reach its final destination).  The other main difference 
is that DTNs deal with intermittent (and possibly high latency) 
connections rather than real-time always on data, and that not all dtn 
links are bidirectional.  One key result of this is that our motivation 
for fragmentation is to allow large bundles to be delivered over 
multiple links - either concurrent or serial, and that we want this 
fragmentation to be able to occur mid-network.  For example, let's say 
we have a 1000MB file that needs to be sent first via a datamule (a hard 
drive sitting in a car) from a rural area in California then via a set 
of LEO satellites from Hollywood to Australia.  There's no need for 
fragmentation during the first hop, but it turns out that each LEO 
contact can only carry 100MB of data, so the bundle must be fragmented 
in Hollywood in order to fit on the links. We could schedule all 10 
fragments for the same satellite, using 10 sequential contacts, or we 
could schedule the fragments for 10 different satellites, and ship some 
data in parallel. Given that there's probably no good way to know ahead 
of time (ie at the source) about the minimum contact size, due to large 
end-to-end delay and heterogenity of transmission mediums, we can't make 
a decision at the beginning on how to fragment the bundle for the 
duration of its transmission.  We also support "reactive" fragmentation, 
in which the sender and the next-hop receiver automatically fragment a 
bundle (on both sides) if its transmission was interrupted. In theory 
the sender and receiver need to agree on where to fragment the bundle, 
especially if custody transfer is involved...

In general, most of the semantic difficulty with fragmention arises with 
custody transfer and multipath routing (sending different fragments on 
different paths).

As fragmentation in DTN stands now, each bundle fragment carries and 
offset and length, which indicates which subset of the original bundle 
it represents. There's no mechanism for multicast (yet) which might be a 
potential crossover with rbnb, and nothing for sequential streams.  We 
are thinking about using rateless erasure codes as a 
fragmentation/reliability mechanism, in which case, we would have 
smaller fragments, but no need for sequence numbers (just code block 
identification numbers)

I think we choose not to explicitly support streams, because the idea 
doesn't quite fit in with the concept of delay tolerant networking, 
although it is conceivable that you would want to send traditionally 
streamed data over DTNs. The closest we have (someone correct me if I'm 
wrong) is service classes. The routing is flexible enough that we could 
support pseudo-virtual circuits, given enough knowledge about the path, 
such that bundles with the same src-dest will most likely take the same 
path.  The other approach, of course, would be to support pubsub and 
sequenced bundles in the application layer - there's an end-to-end 
acknowledgement that the application can use to implement their own 
retransmission mechanisms.

My brain is a bit discontiguous at the moment... apologies if my email 
reflects that.

Melissa

Matt Miller wrote:

> Hello,
>
> This is my first post to this list but I have been following much of 
> the discussion.
> I am an inventor of RBNB (http://rbnb.creare.com), notably  the 
> inspiration for the
> "whirly-gig" DTN icon and perhaps some related buffer-in-the-middle 
> ideas.
> Both DTN and RBNB share the concept of buffered network nodes.  But 
> whereas
> DTN seems to focus on message (bundle) delivery, RBNB focuses on 
> sequenced
> (e.g. streaming) data.
>
> It occurs to me that the problem of how to handle fragmented bundles 
> might fit
> very well with the time-sequenced data-frame concept in RBNB.  Rather 
> than
> presuming a data source sends only whole messages, one might
> consider a source that sends a sequenced, related sequence of 
> (fragmented)
> messages.  E.g. video frames, status updates, chapters of a book,
> updated versions, on-going chat messages, etc.
>
> If a source can sequence its bundles, then a corollary function would 
> be for
> a destination to request subsets of that sequence (e.g. send me
> status updates from yesterday noon until now).  This points to another
> potential distinction between DTN (as I understand it) and RBNB.  With 
> RBNB,
> data is not sent point-to-point, but rather source-to-middle, 
> middle-to-destination.
> These can be linked to accomplish seamless source-to-destination, but 
> also
> defer the who-gets-it decision such that concepts like subset-request and
> publish-subscribe can be implemented using a common paradigm.
>
> Please clarify or correct any misunderstandings I may have. I would
> appreciate any insight as to how these technologies may be complementary.
>
> Thanks,
> Matt Miller
> Creare Inc
>
>

Date: Wed, 16 Jun 2004 15:01:01 -0700 (PDT)
From: Nirupama Bulusu <[email-masked]>
To: [email-masked], "Prof. Sanjay Jha" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] EmNetS-I: Call for Papers (submission deadline is now June 22nd)
Sender: [email-masked]

CALL FOR PAPERS

     The First IEEE Workshop on Embedded Networked Sensors (EmNetS-I)
               http://www.cse.unsw.edu.au/~emnet

                 To be held in conjunction with
  The 29th Annual IEEE Conference on Local Computer Networks (LCN 2004)
             16th November 2004, Tampa, Florida
           (Please also visit http://www.ieeelcn.org) 
 
      Keynote Speaker: Professor Daniela Rus, CSAIL, MIT

      Sponsored By: IEEE, IEEE Computer Society, Intel, Crossbow,
                    Millennial Net, Coronis Systems, Smart Internet CRC,
                    National ICT Australia Limited (NICTA)

The First Workshop on Embedded Networked Sensors (EmNetS) will bring 
together researchers working in the broad area of embedded, networked 
sensors.  The goal of the workshop is to promote community-wide 
discussion of nascent but innovative ideas, spanning a wide spectrum of 
technical issues in the area of sensor networks. We particularly 
encourage submissions exploring how  practical considerations or novel 
application scenarios and requirements shape the design of these sensor 
networks.

Topics of interest include, but are not limited to: 
o  Algorithms, protocols and systems for communication, coordination, 
   data dissemination and storage, sensor tasking and control/actuation 
o  Energy and resource management, sharing, quality of service, operating 
   system support for sensor networks. 
o  Experimental tools and results from operational sensor networks 
o  Sensor network deployment and management, traffic engineering, and
   real-world experience 
o  Reliability and fault-tolerance, debugging and troubleshooting for
   sensor networks 
o  Novel applications for sensor networks 
o  Sensor network security, vulnerabilities and defenses 
o  Programmable architectures and infrastructure for sensor networks 
o  Lessons about scalability and energy-efficiency, insights and models
   of the structure and behavior of sensor networks 

Authors are invited to submit full (8-page) or short (2-page) papers for 
presentation at the workshop. Papers will be selected based on their 
originality, technical merit and topical relevance. Detailed submission 
instructions will be posted at the workshop website.

Important Dates:

      Submissions due: 22 June 2004 
      Notification of Acceptance:  5 August 2004 
      Camera-ready copy due:  25 August 2004 
      Author registration deadline:  20 August 2004 
      Workshop: 16 November 2004

Workshop Organizers: 
General Chair:   
      Deborah Estrin (University of California Los Angeles)
 
Program Committee Co-Chairs:   
      Nirupama Bulusu (OGI/OHSU) 
      Sanjay Jha (University of New South Wales) 

Program Committee Members: 
      Dharma Agrawal (University of Cincinnati) 
      Andrew Campbell (Columbia University) 
      Rachel Cardell-Oliver (University of Western Australia) 
      Peter Corke (CSIRO, Australia)
      David Culler (UC Berkeley) 
      Kevin Fall (Intel Research Berkeley) 
      Wu-chi Feng (OGI/OHSU) 
      Massimo Franceschetti (UC Berkeley) 
      Richard Han (UC Boulder) 
      John Heidemann (USC Information Sciences Institute)
      Holger Karl (TU Berlin) 
      Roger Kermode (Alimua Pty Ltd) 
      Tham Chen Khong (NUS Singapore) 
      Bhaskar Krishnamachari (University of Southern California) 
      Maria Papadopouli (UNC Chapel Hill) 
      Miodrag Potkonjak (UCLA) 
      Gaurav Sukhatme (University of Southern California) 
      Mark Yarvis (Intel Corporation) 
      Ying Zhang (Palo Alto Research Center)

From: Matt Miller <[email-masked]>
Date: Wed, 16 Jun 2004 13:47:07 -0400
To: [email-masked]
Subject: [dtn-interest] Support for sequenced bundles (a form of fragmentation)?
Sender: [email-masked]

Hello,

This is my first post to this list but I have been following much of 
the discussion.
I am an inventor of RBNB (http://rbnb.creare.com), notably  the 
inspiration for the
"whirly-gig" DTN icon and perhaps some related buffer-in-the-middle 
ideas.
Both DTN and RBNB share the concept of buffered network nodes.  But 
whereas
DTN seems to focus on message (bundle) delivery, RBNB focuses on 
sequenced
(e.g. streaming) data.

It occurs to me that the problem of how to handle fragmented bundles 
might fit
very well with the time-sequenced data-frame concept in RBNB.  Rather 
than
presuming a data source sends only whole messages, one might
consider a source that sends a sequenced, related sequence of 
(fragmented)
messages.  E.g. video frames, status updates, chapters of a book,
updated versions, on-going chat messages, etc.

If a source can sequence its bundles, then a corollary function would 
be for
a destination to request subsets of that sequence (e.g. send me
status updates from yesterday noon until now).  This points to another
potential distinction between DTN (as I understand it) and RBNB.  With 
RBNB,
data is not sent point-to-point, but rather source-to-middle, 
middle-to-destination.
These can be linked to accomplish seamless source-to-destination, but 
also
defer the who-gets-it decision such that concepts like subset-request 
and
publish-subscribe can be implemented using a common paradigm.

Please clarify or correct any misunderstandings I may have. I would
appreciate any insight as to how these technologies may be 
complementary.

Thanks,
Matt Miller
Creare Inc

From: [email-masked] (Mostafa Ammar)
To: [email-masked]
Date: Fri, 11 Jun 2004 20:57:58 -0400 (EDT)
Cc: [email-masked]
Subject: [dtn-interest] Message Ferrying Project
Sender: [email-masked]

  Hi

 Can you please link our DTN-related
Message Ferrying project to the DTNRG web page.

The project web page is at

http://www.cc.gatech.edu/fac/Mostafa.Ammar/ferrying.html

Thank you.

 Mostafa

=================================================================
Mostafa Ammar                        Phone:(404)894-3292
Regents' Professor                   Fax:  (404)385-0332
College of Computing                 E-mail: [email-masked]
Georgia Institute of Technology     
Atlanta, GA 30332          
		   WWW:http://www.cc.gatech.edu/fac/Mostafa.Ammar
=================================================================

Date: Fri, 11 Jun 2004 16:21:51 -0700 (PDT)
From: Nirupama Bulusu <[email-masked]>
To: [email-masked]
cc: "Prof. Sanjay Jha" <[email-masked]>
Subject: [dtn-interest] DTN related project at NICTA, Australia
Sender: [email-masked]

Hi!

Please could you link the following project in the DTNRG web page.

"Node localization using mobile robots in delay-tolerant sensor networks"
at NICTA, Australia
http://www.cse.unsw.edu.au/~sensar/research/projects/localization/

Our group is addressing research challenges relevant to delay-tolerant
sensor networks, such as localization using mobile robots,
optimal path planning for data collection, communication architectures
and applications of delay-tolerant sensor networks.
This web page highlights our localization work.

Thanks,
Nirupama Bulusu.
Sanjay Jha.

Subject: Re: [dtn-interest] mote applications question
From: Keith Scott <[email-masked]>
To: Markose Thomas <[email-masked]>
Cc: [email-masked]
Date: Mon, 07 Jun 2004 14:52:39 -0400
Sender: [email-masked]

The RcvMote GUI was designed to run with the mote convergence layer, now
depricated.  The MoteProxy application probably passes something
different.  You may be able to update the RcvMote GUI app to work with
MoteProxy, but it'll take some work.

		--keith

On Fri, 2004-06-04 at 00:44, Markose Thomas wrote: 
> hi,
>   I am using the xbow mote kits with the MTS300 sensor boards, the MICA2 
> boards and the MIB510CA board.
> My question is whether the MoteProxy application and the RcvMote 
> applications are compatible with these
> boards? I ask this because I get weird results when I use the RcvMote 
> and Moteproxy applications.
>   My current setup is one base MICA2 board connected to the MIB510, and 
> two MTS300 sensor boards attached to
> two MICA2 boards. I am currently only sending data through MoteProxy to 
> the loopback interface. MoteProxy delivers
> bundles of 101 bytes at regular intervals, but RcvMote only scans 36 
> bytes of these. The CRCS computed do not match,
> and the source_node_id it shows also seems wrong. Moreover no data 
> packets are displayed in the RcvMote GUI.
>  How can I fix this?..Any help would be appreciated..
> 
> thanks
> mark
> 
> #### moteproxy command issued ####
>  moteproxy -b localhost  -D bundles://loopback/tcp://localhost:5000/ -t 
> /dev/ttyS0 -d 10
> 
> #### /etc/bundles/bundleNode.conf (interfaces part) #####
>  
> interface bundles://loopback/tcp://localhost:5000/ ondemand
> interface bundles://internet/tcp://10.1.5.47:5000/ ondemand
> 
> ####
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 

Keith Scott <[email-masked]>

Date: Fri, 04 Jun 2004 00:44:51 -0400
From: Markose Thomas <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] mote applications question
Sender: [email-masked]

hi,
  I am using the xbow mote kits with the MTS300 sensor boards, the MICA2 
boards and the MIB510CA board.
My question is whether the MoteProxy application and the RcvMote 
applications are compatible with these
boards? I ask this because I get weird results when I use the RcvMote 
and Moteproxy applications.
  My current setup is one base MICA2 board connected to the MIB510, and 
two MTS300 sensor boards attached to
two MICA2 boards. I am currently only sending data through MoteProxy to 
the loopback interface. MoteProxy delivers
bundles of 101 bytes at regular intervals, but RcvMote only scans 36 
bytes of these. The CRCS computed do not match,
and the source_node_id it shows also seems wrong. Moreover no data 
packets are displayed in the RcvMote GUI.
 How can I fix this?..Any help would be appreciated..

thanks
mark

#### moteproxy command issued ####
 moteproxy -b localhost  -D bundles://loopback/tcp://localhost:5000/ -t 
/dev/ttyS0 -d 10

#### /etc/bundles/bundleNode.conf (interfaces part) #####
 
interface bundles://loopback/tcp://localhost:5000/ ondemand
interface bundles://internet/tcp://10.1.5.47:5000/ ondemand

####