Subject: Re: [dtn-interest] extension headers in bundle protocol
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Date: Mon, 30 Aug 2004 09:09:42 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

At 11:46 AM 8/27/2004 -0700, Michael Demmer wrote:

>I'd like to propose that we add a facility for extensible headers to
>the bundle protocol specification. Currently, the specification
>assumes that all compliant implementations interpret and parse all the
>header type codes, even if the header represents an optional
>feature. As a side effect of this, there is no generic framework for
>encoding the length of headers, as for each header type, the length is
>either inferrable from the format of the header itself or encoded in a
>header-specific manner.
>
>I would like to add support to the protocol for the development of
>experimental features do not require implementation by all bundling
>nodes in the interior of the network, but may require header
>information that is interpreted by participating nodes. To this end,
>these features shouldn't require a new revision of the protocol to
>support their header information, but rather need some means by which
>"old" nodes can ignore the feature's headers, while "new" nodes parse
>and interpret the headers.
>
>Therefore, I'd like to add three new type codes to the specification:
>EXT1, EXT2, and EXT4. Each will include one byte for the next header
>type, one byte for the extension typecode, and one, two, or four
>bytes, respectively. Graphically:
>
>EXT1:
>+----------------+----------------+----------------+
>| Next Header    | Extension Type | Length (1 byte)|
>+----------------+----------------+----------------+
>
>EXT2:
>+----------------+----------------+----------------+----------------+
>| Next Header    | Extension Type | Length (2 bytes)                |
>+----------------+----------------+----------------+----------------+
>
>EXT4:
>+----------------+----------------+--------+-------+--------+-------+
>| Next Header    | Extension Type | Length (4 bytes) ...            |
>+----------------+----------------+--------+-------+--------+-------+
>
>All compliant bundle implementations must be able to parse the
>extension header formats, and given that the header length is
>explicit, the node can skip over an unimplemented header and parse the
>next header.
>
>Comments are of course requested.

For what it's worth, I think this is a fine idea.

Scott 

Date: Fri, 27 Aug 2004 11:46:54 -0700
From: Michael Demmer <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [dtn-interest] extension headers in bundle protocol
Sender: [email-masked]

I'd like to propose that we add a facility for extensible headers to
the bundle protocol specification. Currently, the specification
assumes that all compliant implementations interpret and parse all the
header type codes, even if the header represents an optional
feature. As a side effect of this, there is no generic framework for
encoding the length of headers, as for each header type, the length is
either inferrable from the format of the header itself or encoded in a
header-specific manner.

I would like to add support to the protocol for the development of
experimental features do not require implementation by all bundling
nodes in the interior of the network, but may require header
information that is interpreted by participating nodes. To this end,
these features shouldn't require a new revision of the protocol to
support their header information, but rather need some means by which
"old" nodes can ignore the feature's headers, while "new" nodes parse
and interpret the headers.

Therefore, I'd like to add three new type codes to the specification:
EXT1, EXT2, and EXT4. Each will include one byte for the next header
type, one byte for the extension typecode, and one, two, or four
bytes, respectively. Graphically:

EXT1:
+----------------+----------------+----------------+
| Next Header    | Extension Type | Length (1 byte)|
+----------------+----------------+----------------+

EXT2:
+----------------+----------------+----------------+----------------+
| Next Header    | Extension Type | Length (2 bytes)                |
+----------------+----------------+----------------+----------------+

EXT4:
+----------------+----------------+--------+-------+--------+-------+
| Next Header    | Extension Type | Length (4 bytes) ...            |
+----------------+----------------+--------+-------+--------+-------+

All compliant bundle implementations must be able to parse the
extension header formats, and given that the header length is
explicit, the node can skip over an unimplemented header and parse the
next header.

Comments are of course requested.

-mike

To: [email-masked]
Date: Fri, 20 Aug 2004 11:43:42 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] web site updated with talks from IETF/San Diego
Sender: [email-masked]

Well, I have finally put up the slides from the event in San Diego.
For those of you not there, we had about 50 people show up (about
10 more than I initially expected) and some interesting talks.
I would declare the event a success :).

Thanks to ISOC for sponsoring the room.

As a "gentle reminder", I would like to progress the DTN architecture
draft toward an eventual RFC.  As such, I would like to once again
solicit comments on it (positive or negative, especially from
people who were not directly involved in writing it).  No response
will be taken as "it sounds good to me", so please speak up now
before I put it into the IESG hopper...

Thanks again to all who showed up in San Diego.  Based on the consensus
at the meeting, it appears we may target another DTNRG meeting to be held
in conjuncttion with the 62nd IETF in March, 2005.

cheers,
- Kevin
http://www.dtnrg.org

From: "Micah Beck" <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] ideas and issues 
Date: Wed, 11 Aug 2004 14:08:02 -0400
Sender: [email-masked]

Kevin,

I see we've moved from listing technical ideas to discussing their merits,
which is fine with me...

> If we are going to create a convergence layer that refers indirectly to
the
> data content, why not use a storage system already designed for disruption
> tolerance, and that supports locking, access control, etc?  [e.g. Coda].?

I think the issue here is what the expected attributes of the convergence
layer are.

A convergence layer based on Coda (or any such distributed file or database
system) would presumably allow a collection of bundle agents to have access
to a shared file store which they could use for reliable, efficient
communication of large bundles.  This would optimize communication within a
collection of bundle agents that were closely enough coupled, in
communication and administrative domain, to share access through such a
distributed system.

A convergence layer based on IBP would be able to leverage resources
provisioned for the use of a more loosely coupled community, one in which
the bundle agents might not be closely enough coupled to share access
through a distributed file system.  There could be many factors that would
keep communicating bundle agents from being closely coupled, from high
mobility to a lack of sufficient trust.  While any resource-sharing
community requires some degree of stability and trust among its members, IBP
is designed to minimize such requirements in order to maximize its
deployment scalability.  As a result of such weakened assumptions regarding
the community served, IBP places a greater burden on the bundle agents that
would seek to use the resources it provides, in the form of end-to-end
protocols and algorithms that they must implement to ensure reliability and
safe sharing of resources.  IBP is also much more general than a typical
file system, incorporating a mechanism for programmability that would enable
DTN  to offload much more than file storage and locking.

One problem with adapting solutions developed in the context of distributed
systems to networking applications is the question of scalability.
Distributed systems tend to look first for the functionality that assists in
the implementation of applications (complex locking and access control
mechanisms are an example) and then seek to make those solutions scale to
large communities in the wide area.  Successful networking application are
often developed the other way around, asking what the minimum required
services are that enable the application, and seeking to deploy
infrastructure that is as limited as possible in order to maximize its
deployment scalability.  It's the End-to-End Principle.

IBP does provide primitive support for the sequentialization of operations,
and we prefer to wait until requirements are well-understood before adding
new functionality.  We consider such caution in adding features as a
strength of our design methodology.

/micah

----- Original Message ----- 
From: "Kevin Fall" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 09, 2004 1:31 PM
Subject: Re: [dtn-interest] ideas and issues

> >
> > From:  Scott Burleigh <[email-masked]>
> > To:    [email-masked]
> > Subject: Re: [dtn-interest] ideas and issues
> > Date:  Mon, 09 Aug 2004 07:39:15 PDT
> >
> > At 12:52 PM 8/7/2004 -0400, Micah Beck wrote:
> > >Scott,
> > >
> > >Another DTN design idea that has come up in technical conversations
over the
> > >past few years:
> > >
> > >Implementing DTN on top of a more generic distributed storage
infrastructure
> > >in order to enable sharing of resources with related services and
> > >applications that have a substantial state-mangement requirement.  To
the
> > >extent that such a distributed storage infrastructure wasalso
> > >programmable, this may address the idea of putting some functionality
> > >similar to active networking into DTN.  One approach to this idea would
be
> > >to impelment DTN on top of the Internet Backplane Protocol, a highly
generic
> > >distributed storage service that incorporates programmability.
> > >
> > >/micah
> >
> > Thanks, Micah, you're right, we've been thinking about applying IBP to
DTN
> > problems for a little over four years, since March of 2000.  In
particular,
> > it seems like an adapter enabling IBP to run as a convergence-layer
> > protocol under Bundling could be very useful.  Up to now it has been a
> > little challenging to develop new DTN convergence layer adapters, but as
> > development of the new reference implementation begins to standardize
some
> > interfaces this work should become less daunting.
> >
> > Scott
>
> If we are going to create a convergence layer that refers indirectly to
the
> data content, why not use a storage system already designed for disruption
> tolerance, and that supports locking, access control, etc?  [e.g. Coda].?
>
> - K
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

To: Scott Burleigh <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] ideas and issues 
Date: Mon, 09 Aug 2004 10:31:39 -0700
From: Kevin Fall <[email-masked]>
Sender: [email-masked]

>
> From:  Scott Burleigh <[email-masked]>
> To:    [email-masked]
> Subject: Re: [dtn-interest] ideas and issues
> Date:  Mon, 09 Aug 2004 07:39:15 PDT
>
> At 12:52 PM 8/7/2004 -0400, Micah Beck wrote:
> >Scott,
> >
> >Another DTN design idea that has come up in technical conversations over the
> >past few years:
> >
> >Implementing DTN on top of a more generic distributed storage infrastructure
> >in order to enable sharing of resources with related services and
> >applications that have a substantial state-mangement requirement.  To the
> >extent that such a distributed storage infrastructure wasalso
> >programmable, this may address the idea of putting some functionality
> >similar to active networking into DTN.  One approach to this idea would be
> >to impelment DTN on top of the Internet Backplane Protocol, a highly generic
> >distributed storage service that incorporates programmability.
> >
> >/micah
> 
> Thanks, Micah, you're right, we've been thinking about applying IBP to DTN 
> problems for a little over four years, since March of 2000.  In particular, 
> it seems like an adapter enabling IBP to run as a convergence-layer 
> protocol under Bundling could be very useful.  Up to now it has been a 
> little challenging to develop new DTN convergence layer adapters, but as 
> development of the new reference implementation begins to standardize some 
> interfaces this work should become less daunting.
> 
> Scott 

If we are going to create a convergence layer that refers indirectly to the
data content, why not use a storage system already designed for disruption
tolerance, and that supports locking, access control, etc?  [e.g. Coda].?

- K

Date: Mon, 09 Aug 2004 07:39:15 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: Re: [dtn-interest] ideas and issues
Sender: [email-masked]

At 12:52 PM 8/7/2004 -0400, Micah Beck wrote:
>Scott,
>
>Another DTN design idea that has come up in technical conversations over the
>past few years:
>
>Implementing DTN on top of a more generic distributed storage infrastructure
>in order to enable sharing of resources with related services and
>applications that have a substantial state-mangement requirement.  To the
>extent that such a distributed storage infrastructure wasalso
>programmable, this may address the idea of putting some functionality
>similar to active networking into DTN.  One approach to this idea would be
>to impelment DTN on top of the Internet Backplane Protocol, a highly generic
>distributed storage service that incorporates programmability.
>
>/micah

Thanks, Micah, you're right, we've been thinking about applying IBP to DTN 
problems for a little over four years, since March of 2000.  In particular, 
it seems like an adapter enabling IBP to run as a convergence-layer 
protocol under Bundling could be very useful.  Up to now it has been a 
little challenging to develop new DTN convergence layer adapters, but as 
development of the new reference implementation begins to standardize some 
interfaces this work should become less daunting.

Scott 

From: "Micah Beck" <[email-masked]>
To: <[email-masked]>, "Scott Burleigh" <[email-masked]>
Subject: Re: [dtn-interest] ideas and issues
Date: Sat, 7 Aug 2004 12:52:34 -0400
Sender: [email-masked]

Scott,

Another DTN design idea that has come up in technical conversations over the
past few years:

Implementing DTN on top of a more generic distributed storage infrastructure
in order to enable sharing of resources with related services and
applications that have a substantial state-mangement requirement.  To the
extent that such a distributed storage infrastructure wasalso
programmable, this may address the idea of putting some functionality
similar to active networking into DTN.  One approach to this idea would be
to impelment DTN on top of the Internet Backplane Protocol, a highly generic
distributed storage service that incorporates programmability.

/micah

----- Original Message ----- 
From: "Scott Burleigh" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 06, 2004 2:08 AM
Subject: [dtn-interest] ideas and issues

> Hi.  Just to get them collected and written down somewhere, and maybe
spark
> some further discussion on this list, here are a few issues in DTN design
> that have come up in technical conversations over the past few years but
> haven't yet made their way into the formal documents.
>
> Time synchronization across a delay-afflicted network is both necessary
(if
> only to make the TTL mechanism work) and challenging.  Since mid-2001 Dave
> Mills and his folks at University of Delaware have done a ton of work on
> this, which at some point we need to insert into our thinking.
>
> At various times since late 1999 we've discussed the possible usefulness
of
> somehow associating an economic "cost" with sending a bundle, maybe just
as
> a mechanism to help address problems like congestion control, spam, and
QoS
> accommodation, but maybe even as a way to finance the growth and operation
> of the network.  Still an open question, I think.
>
> In general, flow control and congestion control remain open
> issues.  Durga's investigations of machine learning-based congestion
> measurement are promising, but we don't yet know how well this will work.
>
> Erasure coding along the lines of Digital Fountain Raptor codes looks like
> an excellent way to improve reliability in transmission across a
> delay-tolerant network.  We started talking about this in some depth in
> late 2001, but as early as August of 1999 the idea of "smearing"metadata
> across a number of packets to improve the chance of getting it delivered
> had come up in email.
>
> Since late 1998 we have occasionally contemplated applying active network
> ideas to DTN, i.e., shipping some sort of executable code as part of the
> bundle header.  It has seemed like a potential security issue, but maybe
> still worth exploring.
>
> Although many Internet applications couldn't be expected to work
> out-of-the-box on a delay-afflicted network, back in August of 1998 we
> began thinking about developing proxies that would present familiar
> application interfaces to users and (one way or another) insulate them
from
> the communication delay.
>
> In March of 2000 we briefly discussed coming up with some sort of
mechanism
> to enable competition among multiple providers of IPN service.  May still
> be worth pursuing.
>
> Over the years we've spent many, many hours considering various routing
> strategies.  Source routing still looks appealing for some kinds of
> applications; some variant of flood routing (I called one notion of
dynamic
> variable flood routing "seepage routing") seems to make sense in some
> contexts; etc.  We've also considered mechanisms for rescinding routing
> decisions, which becomes possible in a delay-tolerant network because
> actual transmission in service of a routing decision may be deferred due
to
> temporary unavailability of the selected forward link.
>
> While custody transfer itself has been pretty thoroughly discussed in the
> Architecture and Bundling I-Ds, the notion of increasing reliability by
> generalizing custody transfer -- allowing for two or more custodians in
> series -- has so far been just idle talk (dating from spring of 2002).
>
> Early this year Mike Demming suggested another interesting possibility,
> which I think of as a new automatic bundle abandonment or pruning option
in
> addition to TTL expiration: a node might be instructed to keep in its
> forwarding queue only the most recent N (rather than all; N might only be
> 1) bundles destined for a given DTN endpoint.  Where bundle content is
> generally idempotent, this could be a way to avert some kinds of
congestion
> at forwarding nodes that are frequently disconnected.
>
> Finally (also early this year), we've contemplated supporting some sort of
> network service to help locate a DTN-speaking entity that has a single
> functional identity but is not always in the same region and therefore
> isn't always addressable by the same DTN endpoint ID (tuple).  One
possible
> mechanism along these lines would be a global directory that might map an
> entity's invariant, global identifier to its current endpoint ID; a
> generalization of this idea might be to associate with that identifier a
> "flight plan" of endpoint IDs that are expected to map to that entity at
> various times in the future, as the entity moves from region to region.
>
> Anybody think of anything I've missed?
>
> Scott
>
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Fri, 06 Aug 2004 23:49:39 -0700
From: Melissa Ho <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] IETF DTN Meeting Minutes
Sender: [email-masked]

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

Hi,

Thanks to all who travelled to San Diego for the meeting today, and 
thanks to all who presented.. It was great to see what everyone is 
working on. For those of you who couldn't make it (and for those of you 
who did make it), I've attached my notes from the meeting.

Just as a reminder, the latest architecture draft (v2), LTP (v1), and an 
update of the bundle specification (v3e) are available - please comment.

Here are the links to the various projects presented.
Saami Paper: http://www.sm.luth.se/~dugdale/publications/icr_lindgren.pdf
Mindstream: http://mindstream.watsmore.net
Firefighting: http://hpwren.ucsd.edu/
Routing: 
http://www.acm.org/sigs/sigcomm/sigcomm2004/papers/p299-jain111111.pdf
UCLA:
EmStar: http://cvs.cents.ucla.edu/emstar
Roofnet/Click for Stargate: http://www.cs.ucla.edu/~adparker
Q330 Interface/Antelope Emulator: http://www.cs.ucla.edu/~adparker
DataMule repository: http://cvs.nesl.ucla.edu
Drive-Thru-Internet: http://www.drive-thru-internet.org/

Links to presentations and papers referenced are also available at 
http://www.dtnrg.org

Melissa

--------------050806010502050904020307
Content-Type: text/plain;
 name="ietf-meeting-080604.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ietf-meeting-080604.txt"

IETF DTN Meeting Minutes
Friday, August 6, 2004
Sheraton San Diego Hotel and Marina 

* Introductions
* Overview - Status of DTN
  - slides will be posted

==========================================
Keshav
Tetherless Computing Research Update
------------------------------------------

recent projects related to disconnected computing
* a lot of wireless 

*** connect-disconnect-connect idea **

* disconection management
* mobility management
* identity management
 --> low control overhead
 --> car driving by hotspot -> needs to happen in seconds

3 applications
  - healthcare
     - send doctors test results
     - disconnection within hospotal
  - environmental monitoring
     - sensors, flyover to collect data
  - rural development

The "Always in-sync iPod"

Four tracks
   architecture, solving fundamental problems, prototype, realworld apps

Connection case 1 (see slide)
 * closest connected dtn router (CCDR) proxies bundle transfer
 * mobile updates its trigger
 * sender sender updates

Case 2: mobile has just move to new region and is passed by a bus
* two villages connected by a bus
 - i3 requires that data travels through i3 nodes
 - also requires name resolution
* use something else
  - use globally unique dtn identifier as part of dtn address
  - openhash to store translations from dtn addresses to ccdrs ip address
  - late binding (already present for admin name)
    - region name may need late binding as well, eg for PDA that wants
      to connect to any arbitrary node
---> question: isn't the destination an "internet" region, even in bus 
  case?

* globally unique id (GUID) is use to map to CCDR
  - for 
  - internet region can resolve unknown names (default route)

Questions: administration of global naming?
 - need recognizable name, to be used for routing
 - concerns that it really needs to be used for routing
 - routing decision is made based on guid
 - directly vs indirectly
   - counting heavily on flat openhashing rather than locators
 - concerns about embedding loc

if you know information about who is going to talk to you in advance
then you don't need guid -> but then you can store information in
a public place --> openhash?

Identity Management
* hierarchical identity based encryption
  - if you know identity,  you know public keyu
  - catch is that you need to get private key from pk server
  - some problems with revokation
* 1 keyserver per region (administrative)
  - get key from "home" region , but not dependent on region name

Hotspot detection
* how does signal strength of beacons change for mobility
* collecting data using train on track
* decision theory for determining optimal time - are we in hot spot?

consider approach with single strong point vs long (continuous) weak point
suggest: decision process that allows you to back out
critical to lower the risk (vs. always making the right decision)

try to exchange data as part of decision? not tcp...

Priority Boosting
* muddle with os scheduler (linux 2.4, 2.6, freebsd)
* get 10-40% improvement using techniques

Custody Transfer Timeout
* routing changes on same time scale as data transmission
* compare performance of oracle-based vs implementable/conservative scheme
* best possible is comparable to reasonability

Building a Prototype
* installed dtn on variety of platforms
* not as robust as we would like
* installed i3 code
* mindstream blog - log in pda, and update automatically as walk through campus
* hardware: soekris (x86, pebble linux), sensor motes (moteproxy, moteblogs),
  sharp zaurus 6500 (flaky but works okay), iPAQ, doesn't support linux yet

Applications
* medical applications
 - working with guelph general hospital
 - lots of lead (xray) -> very disconnected environment
* formula sae: data acquisition, on board application, communicate each lap

Conclusion

http://mindstream.watsmore.net

==========================================
Hans-Werner Braun (UCSD)
Firefighting Application
------------------------------------------
** note: really should check out pictures from presentation **

* large scale wireless network 802.11b
* working with firefighters to provide connectivity
* how to use camera technology on airplanes?
  - benefit from disruption/delay tolerant protocols

High Performance Wireless Research and Education Network 
NSF-funded
leveraging between infrastructure and research

* picture taking: superbowl deployment
 - taking photos automatically based on events, motion sensing
 - lightining, fireworks, etc

heavily grounded antennas
360 degree cameras - enclosed because in harsh environment

like high resolution, predicable, high quality images

Ramona CDF - detected smoke/fire, airplane motion

Jan 2001 Demo
* ad hoc connection with relay in middle
* build, demo, tear down in 3 hours
* 45mbps link to emergency command center, airtac base

* take photos from the ground using connected network camera on plane

* using backbone network, can set up connectivity quickly when the fire occurs

* flyover plane directs trucks on ground
* potentially fragment data -> drop data as connections available

=========================================================
Avri Doria
Saami Network connectivity
-----------------------------------
semi-nomadic reindeer herders
- part of year in connected villages
- half year in areas w/out instrastructure

funded by swedish govt and industry (since january)
sapmi == lapland, northern sweden/finland/norway to russia

Working with saami in Sirges Vilage

Why would reindeer herders want connectivity?
* living at subsistence level - anything helps
* entrepeneurs/businessmen
* want to take part in local community
* network limited to 20% of the world!

First Assumptions
* it is useful (even if just email)
* cheap in terms of capital
* cheap in terms of sustainablity (locally)

Constraints
* no wireline, antennas not there due to financial restrictions, and because
it is nature preserve - GSM 3G not viable
* WiFi
* satellite is expensive and limited bandwidht and intermitten
* solution: relay between remote hotzones and interent

Solution Space
* "proper work of dtnrg"
* opportunistic use of components of other work 
* local web caching (predicted based on community)
  - curriculum based
  - predict width/breadth tree of pages about what you need
* use any availabel network infrastructure, interconnect with mobility

Possible applications
* future: herd tracking ( allow remote herding later)
* email, voicemel, video mmail, photo transfer
* cached web service
* file transfer
* e-govt

Long term plan
* SUSTAINABLE
* models to allow for apid deployment within the interested communities
* establish local saami community around it
* working with UN and taskforce to extend to other communities

LTH, UU, and KTH working together 
- topographical mapping
- relay routing algorithm and protocol
- dtn web cache support
- remote hot spots
* portable relays in backpacks, vehicles, helicopter traffic

Routing Subproject (paper on website/conference proceedings)
* epidemic routing - connectivity is opportunistic 
  - best path at high cost
  - high probablity of delivery at high resource usage
* saami mobility is not random
  - connections will probably recur - it *is* predictable
  - PROPHET, a probabilisit routing protocol using history of encounters
    and transitivity
* probabilistic metric 
  - update probablity metric of node upon encounter
  - transitive property - includes bench factor
  - decrease value as the metric ages
* can we transfer custody if reliability is high enough?
* epidemic flood back of acks
* operation
  - A->B summary vector, delivery pred
  - B->A summary vector, delivery pred
  - ...  (see slides)

Simulation
* pruning the model did not harm effectiveness of epidemic model
* still need custodianship (in spite of mass replication) for the duration
   of the bundle lifetime because epidemic has separate delivery timeout

==================================================
Sushant Jain
Routing in a Delay Tolerant Network
--------------------------------------------------
* remove village connectivity scenario
  - satellite 3-4x/day
  - bike 1x/day
  - dialup ondemand, expensive during day, cheap at night
* dtn routing challenges
  - traditional e2e path may not exist
  - time depending routes (store and forward/mail will not work
  - splitting and multipath     
* dtn multigraph
* cost based approach
* modified dijkstra's algorithm

(See paper and presentation)

Questions:

EDAQ: Need to Know Traffic Matrix? same as LP?
  - knowing future traffic vs current traffic matrix
  - with reservations - allows denial of traffic
  - greedy assignment
  - modify cost function for time
 - max flow is a more optimal algorithm

Have we taken into account errors along the path?
 - no, we assume that links are error free

Propose a heuristic routing may result in similar performance?
 - heuristic approach is better for probabilistic links
 - if splitting is allowed 

====================================================
Mike Demmer
Reference Implementation
----------------------------------------------------
Motivations/background
  - a lot of components due to organic growth
  - exists a lot of unrelated code      
  - avoid second system effect
Highlevel design goals
  1. Code Clarity
  2. Subsystem Mobility
  3. Flexibility in Deployment
  4. Ease of extention and prototyping
  ...
High Level Design Decisions
  - rewrite in c++  and STL
  - diligent 
  - storage manager
  - all bundle metadata is always in memor
  - forwarding decision is separate from actualy implementation
Specific Components - Routing
 * bundlerouter makes all decisions related to bundles
 * dispatch interface to receive internal events
   - router can be embedded in simulator environment
 * challenge: action list specification that can handle range of instructions
Persistent Store
 * abstract storage interface
 * single function for store, update, and retreival of records
 * postgres, berkeleydb, and mysql implementations

Client API
* modeled after sockets
* dtn apps link wth a thin library of api functions for bundling
* making code clearer and provide framework for understanding it.
* questions: sockets api with dtn? is appropriate? how are semantics different?
  - tension between doing something with it vs adding complexity to code
  - do application developers *know* that they need to be delay tolerant
  - WILL BE distinct api -> it's not just a drop in
    - need dtn registration 
    - similarity to sockets potentially misleading?

advice: Choose cleanliness of code over optimization.

question: when? answer: umm. not yet, but eventually

Current Status (daunting to-do list)
interoperability

===============================================================
Andrew Parker
UCLA DTN Sensor Networks update
------------------------------------------------------------
Sensor Networks and DTN
Current Projects
Software

Network Platforms
* hw/sw platforms
  - motes (berkeley) 8 bit processors, crossbow mica2
  - microservers (32 bit processors), stargates
* existing projects and deployments
  - stationary microservers
  - stationary motes/ static microservers
  - stationary motes, mobile data mules (NIMS)

Sensor Network Communication
* bandwidth is a constraint     bw == power == lifetime
* tree building protocol
* intermittent connectivity (duty cycling, sleep to conserve power)
  - hop by hop reliability
  - custody transfer
  - Q:do you have end to end ack A: seismic

Current projects
* ad hoc seismic array
* data mule
* status

Ad Hoc Seismic Array
* mexico deployment in nov 2004
  - stargates w/ omni/uni directional antenna
* garner valley

Software Architecture
(see slide)
* bundle server: prepend bundle metadata
* file mover: for moving files between nodes
* hbh reliable transport
* routing: roofnet, microdiff later

Q: will you use bundling?
A: we want to inter-operate
   will be easier to do things from scratch for the platform, etc

Data Mule
* mobile element travels through network to collect data
* data must be delay tolerant
* robot and stargate
* mule transmits beacons
* motes track "level" from robot path
* choose mote with maximum queue space for next hop
* custody transfer replaced e2e ack

Algorithms

* sensor nodes
  1. sample periodically
  2. bundle is ready to be transferred
  3. bundle query is heard
* robot...
  (see slides)

Software pointers
EmStar: http://cvs.cents.ucla.edu/emstar
Roofnet/Click for Stargate: http://www.cs.ucla.edu/~adparker
Q330 Interface/Antelope Emulator: http://www.cs.ucla.edu/~adparker
DataMule repository: http://cvs.nesl.ucla.edu

====================================================
Scott Burleigh, JPL 
Stephen Farrell, Trinity College Dublin 
Hans Kruse
Licklider Transmission Protocol (LTP) Overview
----------------------------------------------------
What is it?
* Retransmisison protocol for delay tolerant reliable communication
* designed to serve as CL protocol 
* may be useful for terrestrial applications
* with TCP/IP layer

How it works
* block of data to be transmitted is divided into segmetns
* some are flagged as checkpoints
* receiver returns *report* of cumulative reception
* can be multiple transmissions at a time (keep the pipe full)
* knowing changes in peers transmission state may revise timers
* deferred transmission

Features
* tolerates interruption of link w/out data los
* minimal overhead on low capacity/asymmetric links
* segments cna be extened (eg for security coding)
* tranmission of blocks can be canceled
* accelerated retransmission : multiple checkpoints per transmitted block
* partial reliability: checkppointing and retransmission can be enabled
  for specific part of the data to be transmitted (selective checkpointing)

Current Status
* LTP v1 announced on july 15, 2004
* v2 in progress
* Stephen Farrell working on implementation

LTP Resoruces
* reousrce page and mailing list
  http://masaka.cs.ohiou.edu/ltp
  http://irg.cs.ohiou.edu/mailman/listinfo/ltp
* Reserach team at Ohio University: Hans, Mani, Kavitha

Work Items for the -02 draft
* split draft into four parts
  - background/motivation
  - protocol
  - extensions
  - samples
* Extension Mechanisms
  - how do we extend this?
* Cookies
  - security model is not great- allows DOS attacks
  - key distribution to mars?
* LTP-auth extension
  - crypto-based signature protects ltp header
  - required key dist
* Partially reliable block transmission
  - bundle payload delivery is best effort only
  - need header though!
* SCTP 

Perfume: LTP Implementation
* a sockets api for ltp
  - allows rebote without affecting state of open LTP
  - can "hibernate" node
* Part of SeNDT project 

Build
* cygwin, SuSE and arm-linux
* C++/C, few system libraries

SPIs for
- handlign schedules/contacts, etc
- lower layer comms (currently udp, ipaddrs as ltp names

Status
* mostly maps well to -01 draft (minus accelerated stuff)
* seems to work well, not well tested
* can accelerate release if necessary

============================================================
Jorg Ott. TZI Center for computing Technologies  ([email-masked])
Drive-thru Internet
www.drive-thru-internet.org
------------------------------------------------------------
Scenario
- driving from work to home
  - continue application/communication without manual setup
  - will run into hotspots sporadically

* Graph of 802.11g Data Rate (120 km/h)
  - entry 6s
  - production 30 s
  - exit 12s
* Data Volume
  - if you are the only car
  
Extreme Connectivity Variations
* long periods of connectivity while 'stationary'
Communication Characterisitics
Goal: Use today's partially interactive applications
* need to shield applications from temporary disconnections
* support user mobility and provid epersisten transport
* provide e2e or bundle style operation depending on connectivity

Architecture Outline
* Application Client
* Drive-thru proxy
* AC accesses proxy through hotspots

Application Operation: Mixed Paradignms
E2E
Disconnected Operation
* bundle requests: app client to dt client
* forwarding bundles: dtc -> dt proxy
* retrieving and bundle results: dtp-> appl server-> dtp
* forwarding bundles: dtp->dtc
* retreiving results: dtc-> app client
Mixed operation
* forwarding/retreival is one step -> arrive at destination to retrieve rest

Summary
* dt client and proxy comparabel to dtn routers/custodians
* provide e2e as well as disconnected oipration
* issues with applications
* ultimate goal; enables apps to deal with intermittent connectivity e2e
Using rest areas as hot spots...

=====================================
Kevin Fall
Summary
-------------------------------------
Architecture Document at "Final Call"
LTP Draft out
Bundle Protocol Specification (not official ID) 
* expired, but current availabie
IPN Bundle Transfer is expired

DARPA Program: Disruption Tolerant Networking
* call for proposals: ended july
* now in review process
* latebinding, routing, etc
* dtnrg gets to aggregate output of program

Next Meeting
* not every IETF meeting, but at many
* next IETF is in November, too early - maybe later?

--------------050806010502050904020307--

Date: Fri, 06 Aug 2004 16:35:37 +0100
From: Stef Coetzee <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] UK Mobile Data News
Sender: [email-masked]

The UK based Mobile Data Association (MDA) have expanded their Mobile 
Data News and it occurred to me that the publication might be of 
interest to DTN readers

If you think that you or your assocaites might like to receive the 
publication electronically every quarter or so (its free) you can 
register at http://www.mobiledata.org.uk/register/

Cheers
Stef

Date: Thu, 05 Aug 2004 23:08:00 -0700
To: [email-masked]
From: Scott Burleigh <[email-masked]>
Subject: [dtn-interest] ideas and issues
Sender: [email-masked]

Hi.  Just to get them collected and written down somewhere, and maybe spark 
some further discussion on this list, here are a few issues in DTN design 
that have come up in technical conversations over the past few years but 
haven't yet made their way into the formal documents.

Time synchronization across a delay-afflicted network is both necessary (if 
only to make the TTL mechanism work) and challenging.  Since mid-2001 Dave 
Mills and his folks at University of Delaware have done a ton of work on 
this, which at some point we need to insert into our thinking.

At various times since late 1999 we've discussed the possible usefulness of 
somehow associating an economic "cost" with sending a bundle, maybe just as 
a mechanism to help address problems like congestion control, spam, and QoS 
accommodation, but maybe even as a way to finance the growth and operation 
of the network.  Still an open question, I think.

In general, flow control and congestion control remain open 
issues.  Durga's investigations of machine learning-based congestion 
measurement are promising, but we don't yet know how well this will work.

Erasure coding along the lines of Digital Fountain Raptor codes looks like 
an excellent way to improve reliability in transmission across a 
delay-tolerant network.  We started talking about this in some depth in 
late 2001, but as early as August of 1999 the idea of "smearing"metadata 
across a number of packets to improve the chance of getting it delivered 
had come up in email.

Since late 1998 we have occasionally contemplated applying active network 
ideas to DTN, i.e., shipping some sort of executable code as part of the 
bundle header.  It has seemed like a potential security issue, but maybe 
still worth exploring.

Although many Internet applications couldn't be expected to work 
out-of-the-box on a delay-afflicted network, back in August of 1998 we 
began thinking about developing proxies that would present familiar 
application interfaces to users and (one way or another) insulate them from 
the communication delay.

In March of 2000 we briefly discussed coming up with some sort of mechanism 
to enable competition among multiple providers of IPN service.  May still 
be worth pursuing.

Over the years we've spent many, many hours considering various routing 
strategies.  Source routing still looks appealing for some kinds of 
applications; some variant of flood routing (I called one notion of dynamic 
variable flood routing "seepage routing") seems to make sense in some 
contexts; etc.  We've also considered mechanisms for rescinding routing 
decisions, which becomes possible in a delay-tolerant network because 
actual transmission in service of a routing decision may be deferred due to 
temporary unavailability of the selected forward link.

While custody transfer itself has been pretty thoroughly discussed in the 
Architecture and Bundling I-Ds, the notion of increasing reliability by 
generalizing custody transfer -- allowing for two or more custodians in 
series -- has so far been just idle talk (dating from spring of 2002).

Early this year Mike Demming suggested another interesting possibility, 
which I think of as a new automatic bundle abandonment or pruning option in 
addition to TTL expiration: a node might be instructed to keep in its 
forwarding queue only the most recent N (rather than all; N might only be 
1) bundles destined for a given DTN endpoint.  Where bundle content is 
generally idempotent, this could be a way to avert some kinds of congestion 
at forwarding nodes that are frequently disconnected.

Finally (also early this year), we've contemplated supporting some sort of 
network service to help locate a DTN-speaking entity that has a single 
functional identity but is not always in the same region and therefore 
isn't always addressable by the same DTN endpoint ID (tuple).  One possible 
mechanism along these lines would be a global directory that might map an 
entity's invariant, global identifier to its current endpoint ID; a 
generalization of this idea might be to associate with that identifier a 
"flight plan" of endpoint IDs that are expected to map to that entity at 
various times in the future, as the entity moves from region to region.

Anybody think of anything I've missed?

Scott

  

To: [email-masked]
cc: Deborah Estrin <[email-masked]>, [email-masked]
Date: Tue, 03 Aug 2004 14:42:26 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] Updated DTNRG Agenda for Friday Aug 6
Sender: [email-masked]

Here is an updated agenda for friday:

Delay Tolerant Networking Research Group (DTNRG)
Proposed Meeting Agenda

Friday, Aug 2 12:30 - 4:00pm
Point Loma Room, Sheraton San Diego Hotel & Marina (4th floor, West Tower)

12:30		Introduction / Agenda Bashing		K. Fall
1:00		Mindstream Project (Waterloo)		S. Keshav
1:30		Firefighting Application (SDSC)		Hans-Werner Braun
1:45		SNC Project				Avri Doria
2pm		break
2:15		Routing in a DTN (U. Washington)	S. Jain
2:45		DTN Reference Implementation Update	M. Demmer (UCB)
3:00		UCLA Update				A. Parker
3:15		LTP, Sensor Project (JPL/UCLA)		Scott Burleigh (JPL),
							Stephen Farrell (Trinity College)
3:40		Futures discussion			All, K. Fall
			IETF Documents
			DARPA DTN Program
			[agenda creep]

We actually have this room somewhat later than 4pm, so we may be able to go
a bit longer if people wish to.

To: [email-masked]
Date: Mon, 02 Aug 2004 21:14:01 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] of possible interest - IETF Lemonade Working Group
Sender: [email-masked]

For those of you interested, IETF has a 'Lemonade' working group.

The first paragrasph of their charter is as follows:

	Lemonade is tasked to provide a set of enhancements and profiles of 
	Internet email submission, transport, and retrieval protocols to 
	facilitate operation on platforms with constrained resources, or 
	communications links with high latency or limited bandwidth. A primary 
	goal of this work is to ensure that those profiles and enhancements 
	continue to interoperate with the existing Internet email protocols in 
	use on the Internet, so that these environments and more traditional 
	Internet users have access to a seamless service.

More details here: http://www.ietf.org/html.charters/lemonade-charter.html

- Kevin

To: [email-masked]
cc: [email-masked], [email-masked]
Date: Mon, 02 Aug 2004 14:59:19 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] DTNRG Agenda for Friday Aug 6
Sender: [email-masked]

Note that this may change a bit, but here is what I have so far...

Delay Tolerant Networking Research Group (DTNRG)
Proposed Meeting Agenda

Friday, Aug 6 12:30 - 4:00pm
Point Loma Room, Sheraton San Diego Hotel & Marina (4th floor, West Tower)

12:30		Introduction / Agenda Bashing		K. Fall
1:00		Mindstream Project (Waterloo)		S. Keshav
1:30		Firefighting Application (SDSC)		Hans-Werner Braun
1:45		SNC Project				Avri Doria
2pm		break
2:15		Routing in a DTN (U. Washington)	S. Jain
2:45		DTN Reference Implementation Update	M. Demmer (UCB)
3:15		LTP, Sensor Project (JPL/UCLA)		Scott Burleigh (JPL)
3:30		IETF & Futures discussion		All, K. Fall
			IETF Documents
			DARPA DTN Program
			[agenda creep]

We actually have this room somewhat later than 4pm, so we may be able to go
a bit longer if people wish to.

To: [email-masked]
Date: Sun, 01 Aug 2004 08:58:27 -0700
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] web site updated
Sender: [email-masked]

I've just updated the dtnrg web site in preparation for the meeting on friday.
Also, below is the recent DTNRG status update I sent to IETF.

See you friday!

- Kevin

DTNRG Update (July 2004)
http://www.dtnrg.org
Kevin Fall, DTNRG Chair

DTNRG Meeting in conjunction with IETF

	DTNRG will be holding its first co-located meeting (with IETF) at the upcoming 60th IETF
	meeting in San Diego.  The meeting will take place Friday, July 6 at the Sheraton San Diego
	Hotel and Marina [Point Loma Room] starting at 12:30pm.

IETF Documents

	The second edition of the Licklider Transmission Protocol specification, 
	draft-irtf-dtnrg-ltp-01.txt, was announced by IETF on 15 July 2004.

	The current description of the Delay-Tolerant Network Architecture, 
	draft-irtf-dtnrg-arch-02.txt, was announced by IETF on 19 July 2004.

	The specification for version 3 of the Bundling protocol specification was 
	issued to the dtn-interest mailing list on 30 July 2004 but has not yet 
	been submitted to IETF as an Internet Draft.

DARPA Program

	DARPA's Disruption Tolerant Networking Program, based on the work of DTNRG,
	received several proposals, and bidding is now closed.  Pending final approvals
	within DARPA, awards are likely to be given before the end of the year.
	The call for proposals included the following language:

	DTN is a new DARPA project
	(http://www.darpa.mil/ato/solicit/DTN/index.htm), based on the Delay
	Tolerant Networking work being done under IETF auspices, focusing
	on the differences between management of Mobile, Ad-hoc Networks
	(MANET) (such as those in the JTRS radio network) and Internet based networks
	(such as office LANs and WANs)...

	Products
		The products to come out of this effort are:

		Bundling - Organizing information into "Bundles" that can be Delivered by Network 
		Fuzzy Scheduling - Making Network Routing Decisions in the Presence of Uncertainty about Available or
			Optimal Paths 
		Policy Cognitive Operation - Moving Intelligence into Network to Make "Best" Choices on Delivery 
		Deferred/Hierarchical Address Binding - Enable Network to Deliver Traffic Without End to End
			Address and Routing Info 
	Phases
	The project is currently planned for three phases spanning approximately 44-48 months.

		Phase I
		Demonstrate Bundle Delivery Mechanism with 80 % Utilization and 100 % Reliability on Links of
			less than 20 % Availability 
		Demonstrate Trusted Delivery 
		Establish NASA and DoD Program MOA for IPN Demonstration 

		Phase II
		Demonstrate Bundle Mechanism in IPN 
		Demonstrate Late Binding of Bundle Messages 
		Demonstrate Policy Language Control Over Delivery Choices 
		Maintain Phase 1 Metric 
		Establish MOA for Implementing Phase III in Typical Military System Program Objectives 

		(End of Phase III)
		Demonstrate Integrated Bundling and Late Binding in Military Applications 
		Demonstrate late Binding in IP Networks 

DTN Reference Implementation

	DTNRG has recently started a second public implementation of the architecture.  This 
	effort spans several institutions: UC Berkeley, MITRE, Intel Research (Berkeley), Univ. of Waterloo

DTN-Related Papers and Presentations

	A paper describing the DTN architecture appeared at SIGCOMM 2003.
	A new paper entitled 'Routing in a Delay Tolerant Network' will appear at this forthcoming SIGCOMM 2004.
	A tutorial entitled 'Architectural Considerations for Unusual and Challenged Internetworks' will
		be presented by Bob Durst (MITRE) and Kevin Fall (Intel) at SIGCOMM.  For details, see:
			http://www.acm.org/sigs/sigcomm/sigcomm2004/tutorials.html
	The Workshop 'Future Directions in Network Architecture (FDNA)' will be held at SIGCOMM 2004, co-chaired
		by S. Keshav (U. Waterloo) and Kevin Fall (Intel).  For details, see:
			http://www.acm.org/sigs/sigcomm/sigcomm2004/fdna.html