Subject: [dtn-interest] Announce: RAPID Router for DTN
From: Brian Lynn <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Date: Tue, 24 Jun 2008 13:08:36 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

We have released an implementation of the RAPID routing protocol as an 
external router for DTN. The RAPID routing algorithm was created as a 
result of research performed on DieselNet, a mobile network test bed 
developed by the University of Massachusetts, Amherst. RAPID is written 
in Java, and it has been released as open source (Apache license).

Documentation and code are available here:

   http://prisms.cs.umass.edu/rapid/

The original paper describing RAPID can be found here:

   http://prisms.cs.umass.edu/brian/pubs/balasubramanian.sigcomm.2007.pdf

Brian Lynn
University of Massachusetts, Amherst

Date: Fri, 20 Jun 2008 09:16:12 +0100
From: Stephen Farrell <[email-masked]>
To: Michael Demmer <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>, dtn-users mailing list <[email-masked]>
Subject: Re: [dtn-interest] moving dtn code to sourceforge

Michael Demmer wrote:
> In addition to the continued interest from Berkeley / Intel in the DTN  
> work, some folks at Trinity College may be picking up some of the  
> maintenance tasks -- Steven Farrell can elaborate more.

Sure, but not much. Basically, as part of our new DTN project (N4C) [1]
we have budget for the next 3 years that includes effort for some
DTN code maintenance, so we're happy, (and this time able:-), to help
with this,

S.

[1] http://www.n4c.eu/

From: Michael Demmer <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>,  dtn-users mailing list <[email-masked]>
Date: Thu, 19 Jun 2008 15:56:59 -0700
Subject: [dtn-interest] moving dtn code to sourceforge

As you may or may not know, I'm going to be graduating shortly and  
will no longer be the maintainer of the DTN reference implementation  
source tree.

In addition to the continued interest from Berkeley / Intel in the DTN  
work, some folks at Trinity College may be picking up some of the  
maintenance tasks -- Steven Farrell can elaborate more.

Given this transition though, we have been considering moving the main  
hosting location for the code repository to sourceforge. This should  
enable other folks to contribute to the project administration more  
easily, as the sourceforge site has resources to support multiple  
administrators, has separate access control to code repositories,  
documentation, etc, and thus will make the process more straightforward.

I've done some investigation and it looks like this should work fine,  
and I've tested the ability to access a mercurial repository in  
essentially the same way that we set it up on code.dtnrg.org. There  
will certainly be some transition pains, but all in all I personally  
think this is the right direction to go.

So, the main reason for this email is to a) inform you all of the  
potential move and b) to solicit feedback from anyone who thinks this  
is a bad idea and wants to propose an alternative. Barring any  
objections, I'm planning on doing the move sometime early next week.

Cheers,
-mike

Date: Wed, 18 Jun 2008 19:24:56 -0700 (PDT)
From: Varun Sharma <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] HELP with DTN timers
Reply-To: [email-masked]

--0-1264164456-1213842296=:38968
Content-Type: text/plain; charset=us-ascii

Hi,

We have been trying to setup a testbed using dtn-2.5.0.
I wanted to ask that if a node is configured to have more than one link (link in the terminology of dtn.conf) - say link1 and link2, then how does it poll/schedule discovery for the 2 links (assuming ONDEMAND).
I mean if there has been some recent activity on Link1 and then it became unavailable - then will the daemon poll the for Link1 more frequently than Link2 for some time ??

How is the polling for ONDEMAND links actually done ??

Thanks
Varun

      
--0-1264164456-1213842296=:38968
Content-Type: text/html; charset=us-ascii

<table cellspacing='0' cellpadding='0' border='0' ><tr><td valign='top' style='font: inherit;'>Hi,<br><br>We have been trying to setup a testbed using dtn-2.5.0.<br>I wanted to ask that if a node is configured to have more than one link (link in the terminology of dtn.conf) - say link1 and link2, then how does it poll/schedule discovery for the 2 links (assuming ONDEMAND).<br>I mean if there has been some recent activity on Link1 and then it became unavailable - then will the daemon poll the for Link1 more frequently than Link2 for some time ??<br><br>How is the polling for ONDEMAND links actually done ??<br><br>Thanks<br>Varun<br></td></tr></table><br>

--0-1264164456-1213842296=:38968--

Date: Tue, 10 Jun 2008 11:44:43 -0700
From: Katia Obraczka <[email-masked]>
To: [email-masked], [email-masked]
Subject: [dtn-interest] CHANTS 2008 still accepting demo submissions

CHANTS 2008 is still accepting demo submissions until June 14th. More
details can be found in the Call for Demos below.

Looking forward to receiving your demo proposals, 

					Katia Obraczka
					UC Santa Cruz
					CHANTS'08 Demo Chair

==============
Call for Demos
Third Workshop on Challenged Networks (CHANTS 2008)
Co-located with Mobicom 2008, 15 September 2008, San Francisco, CA, USA

Workshop URI:			http://wavedesk.usc.edu/chants/

Important Dates: 
Demo submission deadline:             14 June 2008 (extended)
Demo acceptance notification:         16 June 2008
Camera-ready due:     	           29 June 2008
Workshop date:                     15 September 2008

Challenged networks are characterized by a heterogeneous mix of nodes
and widely varying network conditions.  Nodes in today's challenged
networks often include mobile nodes, space-based nodes,
sensor/actuator nodes and other devices.  Performance of the network
paths interconnecting such nodes can be highly varying in terms of
bandwidth, latency, disruption characteristics and security
requirements.  Conventional Internet access in performance-limited
environments such as developing countries can also be regarded as
challenged networks as can be ad-hoc communication between personal
devices.

The Internet protocol architecture suffers some problems when used in
a challenged network setting.  For example, when disconnection and
reconnection is common or link performance is highly variable or
extreme, one or more of the traditional Internet protocols do not work
well. In this workshop following CHANTS 2007, CHANTS 2006 and WDTN
2005, we wish to explore ongoing efforts in dealing with physical
networks that operate significantly differently from wired, connected
networks and the protocol architectures and algorithms used to deal
with such situations.  Techniques for making applications tolerant to
disruptions and/or high delays are also in scope.

CHANTS 2008 Demonstration Program offers an excellent way to showcase
to attendees from academia and industry tangible results from research
and development in the exciting area of challenged networks. Demos
have the ability to communicate ideas and concepts in a very powerful
way. We invite you to contribute your vision and experience with
challenged networks to CHANTS 2008 Demonstration Program. Demo
proposals shall present recent practical results from the area of
challenged networks.  In exceptional cases, where live demos are
simply not practical to present, poster or video presentations of
practical results are acceptable, too. Accepted demonstration
abstracts will be published in the Conference proceedings.

Topics:

	Characterization of performance-challenged networks e.g. 
                  measurements, modelling.
	Networking systems operating over unusual/challenged networks.
	Protocol design and evaluation of operations over challenged 
                  networks.
	System architecture and design for challenged networks.
	Applications in challenged networks.
	Robust network application design and implementation techniques.
	Delay tolerant and disruption tolerant networks (DTN).
	Configuration and management of challenged networks.

Format and submission instructions:

Demo proposal abstracts (to be published as part of the proceedings)
shall not be longer than 3 pages plus 1 page description of the
precise setup and requirements.  Submitted abstracts should be
formatted in two columns, with characters no smaller than 10 point
fonts, and must fit properly on US "Letter"-sized paper (8.5x11
inches). Margins must be of 1 inch on all edges (top, bottom, left,
and right) of each page. Demo proposals should be sent as a pdf e-mail
attachment to [email-masked].

Content-class: urn:content-classes:message
Date: Tue, 3 Jun 2008 08:19:20 -0500
From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: "Gautam Thaker" <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] how does RON and DTN relate?

>From the descriptions such as "The RON nodes monitor the functioning and
quality of the Internet paths among themselves, and use this information
to decide whether to route packets directly over the Internet or by way
of other RON nodes, optimizing application-specific routing metrics."
this appears require low latency and thus would not be "delay" tolerant
but may be "disruption" tolerant.  It also doesn't appear to be geared
at and sense of bundling - just running existing Internet-based
applications of an application-layer networking overlay.

When I see things like "probing and outage detection" that indicates a
low-latency system to me.  So, this looks like investigating alternative
or enhanced ways to improve routing convergence by adding some
additional intelligence into systems and networks.

"A Resilient Overlay Network (RON) is an architecture that allows
distributed Internet applications to detect and recover from path
outages and periods of degraded performance within several seconds,
improving over today's wide-area routing protocols that take at least
several minutes to recover. A RON is an application-layer overlay on top
of the existing Internet routing substrate. The RON nodes monitor the
functioning and quality of the Internet paths among themselves, and use
this information to decide whether to route packets directly over the
Internet or by way of other RON nodes, optimizing application-specific
routing metrics."

RON nodes monitor Internet paths.  In a DTN, there is often no path to
monitor until is exists.

In conclusion, "How does RON and DTN relate?"   Very little in my
opinion.

/will
******************************

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Gautam Thaker
> Sent: Monday, June 02, 2008 4:33 PM
> To: [email-masked]
> Subject: [dtn-interest] how does RON and DTN relate?
> 
> Hi:
> 
> http://nms.csail.mit.edu/ron/  does not mention DTN. Is there 
> a paper that compares DTN to the prior RON work (I can see 
> some of the differences, but I wonder if there is good 
> coverage of this in a paper some place?)
> 
> Gautam
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Mon, 02 Jun 2008 16:32:54 -0400
From: Gautam Thaker <[email-masked]>
To: [email-masked]
Organization: Lockheed Martin -- Advanced Technology Laboratories
Subject: [dtn-interest] how does RON and DTN relate?

Hi:

http://nms.csail.mit.edu/ron/  does not mention DTN. Is there a paper 
that compares DTN to the prior RON work (I can see some of the 
differences, but I wonder if there is good coverage of this in a paper 
some place?)

Gautam