Subject: Re: [dtn-interest] Question about routing
From: Michael Demmer <[email-masked]>
To: Piero Cornice <[email-masked]>
Cc: [email-masked]
Date: Wed, 30 Mar 2005 08:24:18 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

> Hi,
>     there's a thing i didn't understand about routing.
> At first i thought that EACH machine in a dtn must have bundle daemon running, 
> in order to accomplish routing issues.
> Then i read "Implementing Delay Tolerant Networking" and the doubt now is: 
> let's assume i have two dtn regions, R1 (using TCP) and R2 (non-TCP). A machine 
> in R2 sends a bundle to a machine in R1, so the bundle will pass through a 
> gateway (common to both R1 and R2) and then it will be delivered to the 
> destination machine, in a certain number of hops.
>
> >From gateway to destination, shall i always use bundle router, or could i 
> simply use TCP/IP routing features, without any bundle layer running on 
> intermediate machines?

The basic answer to your question is that it depends on the
characteristics of the TCP part of the network. If you believe that
the machines or connections between them will be intermittent, then
you should probably run bundle daemons at each hop. If instead you
believe that it's a well connected network, then you can simply run a
bundle daemon at the gateway and a daemon at the end point
destination, effectively treating a set of IP hops as a single DTN
hop.

-m

Date: Wed, 30 Mar 2005 11:30:29 +0200
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Question about routing
Sender: [email-masked]

Hi,
    there's a thing i didn't understand about routing.
At first i thought that EACH machine in a dtn must have bundle daemon running, 
in order to accomplish routing issues.
Then i read "Implementing Delay Tolerant Networking" and the doubt now is: 
let's assume i have two dtn regions, R1 (using TCP) and R2 (non-TCP). A machine 
in R2 sends a bundle to a machine in R1, so the bundle will pass through a 
gateway (common to both R1 and R2) and then it will be delivered to the 
destination machine, in a certain number of hops.
>From gateway to destination, shall i always use bundle router, or could i 
simply use TCP/IP routing features, without any bundle layer running on 
intermediate machines?
Thanks,
   Piero Cornice

Date: Tue, 29 Mar 2005 14:01:43 -0800
To: [email-masked]
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] FYI: E2E research visions
Sender: [email-masked]

>Date: Tue, 29 Mar 2005 15:38:37 -0500
>From: Craig Partridge <[email-masked]>
>Subject: [e2e] E2E research visions
>To: [email-masked]
>List-Post: <mailto:[email-masked]>
>List-Subscribe: <http://www.postel.org/mailman/listinfo/end2end-interest>,
>         <mailto:[email-masked]?subject=subscribe>
>
>
>Hi folks:
>
>At the most recent meeting of the End2End Research Group, the group, along 
>with some attendees, had a discussion of possible research visions that 
>could inspire innovative communications research over the next ten years 
>or so.  Dave Clark and I, with help from several other participants in the 
>discussion, have written up the ideas from that discussion and a copy is 
>available on my website
>
>     http://www.ir.bbn.com/~craig/e2e-vision.pdf
>
>for anyone who is interested.
>
>Craig

Date: Tue, 29 Mar 2005 12:01:07 -0800
From: Michael Demmer <[email-masked]>
To: Matt Miller <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Trying to run DTN2 demo
Mail-Followup-To: Matt Miller <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a better question for the dtn-users mailing list. Please sign
up if you plan to continue working with the reference implementation.

I will post the reply to this message to that list.

-m

> Hi. I working with Larry Freudinger of NASA DFRC.
> We are trying to get the DTN2 installed and running on a Linux box
> to evaluate it and possibly link it to our RBNB technology.  I am having
> problems getting the DTN2 code running (per the DTN2 Manual).
> 
> Is there someone who could help get me started?
> I don't want to inappropriately clutter this forum, so respond directly 
> to
> me if that is best. I am probably making a dumb mistake.
> 
> Thanks!
> Matt Miller
> [email-masked]
> 
> 
> Error printout at startup (it doesn't like udp interface it seems):
> 
> daemon/dtnd -c /home/mjm/dtn/dtn.conf --init-db
> [1112106892.145595 /dtnd info] Bundle Daemon Initializing...
> [1112106892.145630 /dtnd info] random seed is 145629
> [1112106892.229823 /dtnd info] parsing configuration file 
> /home/mjm/dtn/dtn.conf...
> [1112106892.230252 /dtnd info] dtnd parsing configuration...
> [1112106892.231783 /interface info] adding interface tcp 
> host://0.0.0.0:5000/
> [1112106892.232457 /bundle/tuple error] unknown schema 'host' in admin 
> 'host://0.0.0.0:6000/'
> [1112106892.232559 /command error] error: line 94: 'invalid interface 
> admin string 'host://0.0.0.0:6000/'':
> invalid interface admin string 'host://0.0.0.0:6000/'
>     while executing
> "interface add udp host://0.0.0.0:6000/"
>     (file "/home... (truncated)
> 
> If I comment out the udp line, it successfully initializes the 
> database, and starts the dtnd.
> But when I try the ping app:
> 
> DTN2/apps/dtnping/dtnping bundles://internet/host://0.0.0.0:5000
> source_tuple [internet host://localhost.localdomain/ping.0]
> replyto_tuple [internet host://localhost.localdomain/ping.0]
> dtn_register succeeded, regid 0xf
> checking for bundles already queued...
> PING [internet host://0.0.0.0:5000]...
> error sending bundle: 129 (payload too large)
> 
> The dtnd output for this is:
> [1112107958.941821 /bundle/tuple error] unknown schema 'host' in admin 
> 'host://localhost.localdomain/ping.0'
> [1112107958.941843 /bundle/tuple error] no address family for admin in 
> 'bundles://internet/host://localhost.localdomain/ping.0'
> [1112107958.941860 /bundle/tuple error] invalid admin tuple in 
> 'bundles://internet/host://localhost.localdomain/ping.0'
> [1112107958.947794 /registration info] adding registration 
> 16/bundles://internet/host://localhost.localdomain/ping.0
> [1112107958.956081 /bundle/tuple error] unknown schema 'host' in admin 
> 'host://localhost.localdomain/ping.0'
> [1112107958.956103 /bundle/tuple error] no address family for admin in 
> 'bundles://internet/host://localhost.localdomain/ping.0'
> [1112107958.956121 /bundle/tuple error] invalid admin tuple in 
> 'bundles://internet/host://localhost.localdomain/ping.0'
> [1112107958.956136 /apisrv error] invalid replyto tuple [internet 
> host://localhost.localdomain/ping.0]
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: Matt Miller <[email-masked]>
Date: Tue, 29 Mar 2005 09:53:27 -0500
To: [email-masked]
Subject: [dtn-interest] Trying to run DTN2 demo
Sender: [email-masked]

Hi. I working with Larry Freudinger of NASA DFRC.
We are trying to get the DTN2 installed and running on a Linux box
to evaluate it and possibly link it to our RBNB technology.  I am having
problems getting the DTN2 code running (per the DTN2 Manual).

Is there someone who could help get me started?
I don't want to inappropriately clutter this forum, so respond directly 
to
me if that is best. I am probably making a dumb mistake.

Thanks!
Matt Miller
[email-masked]

Error printout at startup (it doesn't like udp interface it seems):

daemon/dtnd -c /home/mjm/dtn/dtn.conf --init-db
[1112106892.145595 /dtnd info] Bundle Daemon Initializing...
[1112106892.145630 /dtnd info] random seed is 145629
[1112106892.229823 /dtnd info] parsing configuration file 
/home/mjm/dtn/dtn.conf...
[1112106892.230252 /dtnd info] dtnd parsing configuration...
[1112106892.231783 /interface info] adding interface tcp 
host://0.0.0.0:5000/
[1112106892.232457 /bundle/tuple error] unknown schema 'host' in admin 
'host://0.0.0.0:6000/'
[1112106892.232559 /command error] error: line 94: 'invalid interface 
admin string 'host://0.0.0.0:6000/'':
invalid interface admin string 'host://0.0.0.0:6000/'
     while executing
"interface add udp host://0.0.0.0:6000/"
     (file "/home... (truncated)

If I comment out the udp line, it successfully initializes the 
database, and starts the dtnd.
But when I try the ping app:

DTN2/apps/dtnping/dtnping bundles://internet/host://0.0.0.0:5000
source_tuple [internet host://localhost.localdomain/ping.0]
replyto_tuple [internet host://localhost.localdomain/ping.0]
dtn_register succeeded, regid 0xf
checking for bundles already queued...
PING [internet host://0.0.0.0:5000]...
error sending bundle: 129 (payload too large)

The dtnd output for this is:
[1112107958.941821 /bundle/tuple error] unknown schema 'host' in admin 
'host://localhost.localdomain/ping.0'
[1112107958.941843 /bundle/tuple error] no address family for admin in 
'bundles://internet/host://localhost.localdomain/ping.0'
[1112107958.941860 /bundle/tuple error] invalid admin tuple in 
'bundles://internet/host://localhost.localdomain/ping.0'
[1112107958.947794 /registration info] adding registration 
16/bundles://internet/host://localhost.localdomain/ping.0
[1112107958.956081 /bundle/tuple error] unknown schema 'host' in admin 
'host://localhost.localdomain/ping.0'
[1112107958.956103 /bundle/tuple error] no address family for admin in 
'bundles://internet/host://localhost.localdomain/ping.0'
[1112107958.956121 /bundle/tuple error] invalid admin tuple in 
'bundles://internet/host://localhost.localdomain/ping.0'
[1112107958.956136 /apisrv error] invalid replyto tuple [internet 
host://localhost.localdomain/ping.0]

Date: Sun, 27 Mar 2005 18:13:47 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [dtn-interest] DTN2 version 2.1.1 released
Sender: [email-masked]

I have just put out a new release of DTN2 version 2.1.1. This is just
a minor bug fix release, mostly to fix problems on Mac OS X. I plan to
try to keep doing minor bug fix releases like this one on average once
per month.

See http://www.dtnrg.org/wiki/Code for download instructions and links
to the documentation.

-mike

---

Release Notes for version 2.1.1 (March 2005)
--------------------------------------------

- Patch to configure script to fix build problems on Apple OS X due to
  a conflict with a system include file.

- Bug fix in oasys/io/NetUtils.cc so getaddrinfo works properly on OS
  X (or generally any IPv6 enabled system).

- Minor updates to the manual and tutorials (jra).

Date: Fri, 25 Mar 2005 18:11:42 -0800
From: Melissa Ho <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] SIGCOMM WDTN deadline extended
Sender: [email-masked]

    Sigcomm 2005 - Workshop on Delay Tolerant Networking (WDTN-05)

To be held with SIGCOMM 2005: Aug 20-26, 2005, Philidelphia, PA, USA
Call for Papers (pdf) 
<http://www.dtnrg.org/docs/docs/dtnw-cfpv3-onepage.pdf>

      Paper Format and Submission Instructions

Submitted papers must be no more than 8 pages long, with no characters 
in smaller font than 10pt. Papers can be submitted via the submission 
site <http://blizzard.cs.uwaterloo.ca/DTNCRP>.

      Deadlines

Extended Submission Deadline: April 6, 2005, 11:59pm Pacific Time

Notification Deadline: May 10, 2005

Camera Ready Deadline: June 2, 2005

Date: Thu, 24 Mar 2005 16:04:23 -0800
From: Melissa Ho <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: Darren Long <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dtn-interest] Using getaddrinfo() on Mac OS X causes bad name/address lookup in dtnd
Sender: [email-masked]

Cross-posting to dtn-users list.

Michael Demmer wrote:

>Thanks. I've actually done a better fix that passes the appropriate
>hints to getaddrinfo() to force it to return an IPv4 address, which
>I've tested and works on OS X.
>
>This fix is currently available from the CVS snapshot, and will be
>folded into a bug fix release coming soon.
>
>-m
>
>  
>
>>Hi,
>>
>>I seem to have found an issue with dns lookups in dtnd running on Mac  
>>OS X.
>>
>>With:
>>	 link add tcp0 host://name:5000 ONDEMAND tcp
>>
>>added to my dtn.conf, I got connection attempts to strange IP adresses.  
>> Correct behaviour was observed when I replaced name with the IP  
>>address in the dtn.conf line instead.
>>
>>As this works fine on my intel based Linux box, but not on the PowerPC  
>>based iBook. I dug into the code and found in NetUtils.cc in function:
>>	int gethostbyname(const char* name, in_addr_t* addr)
>>
>>on line number 166:
>>
>>	    err = getaddrinfo(name, 0, 0, &res);
>>
>>the call results in an incorrect address being returned via addr, as  
>>show in context below.
>>
>>/* comment out this block for Mac OS X workaround
>>#elif defined(HAVE_GETADDRINFO)
>>
>>    struct addrinfo *res;
>>    int              err;
>>
>>    err = getaddrinfo(name, 0, 0, &res);
>>    if(err != 0)
>>        return -1;
>>
>>    ASSERT(res != 0);
>>    *addr = ((struct in_addr*) &res->ai_addr)->s_addr;
>>
>>    freeaddrinfo(res);
>>    return 0;
>>
>>*/
>>/* End Mac OS X workaround
>>
>>#elif defined(HAVE_GETHOSTBYNAME)
>>
>>
>>Commenting out the #elif defined(HAVE_GETADDRINFO) block lets the name  
>>lookup processing be handled by the #elif defined(HAVE_GETHOSTBYNAME)  
>>block, resulting in a call to getaaddrinfo() instead.  I'm not sure  
>>what side affects this may have, but for a quick hack it seems to be  
>>successful, and the name lookups now return valid IPv4 addresses.
>>
>>I've noticed that other sites report problems with getaddrinfo on Mac  
>>OS X  
>>(http://www.geektimes.com/macintosh/os/x/10_0/and/ 
>>openssh_install.html).  I'm not sure that I'm best suited to figuring  
>>out a long-term solution.
>>
>>I'm keen to find a way to make better use of dynamic DNS  now.  With a  
>>dyndns.org client running on my iBook, I'd like my server to be able to  
>>find my iBook both on my wireless LAN and when I'm out in the world  
>>using GPRS.  Nicely enough, the dyndns.org client on the iBook results  
>>in the dynamic DNS system reporting my local private IP when I'm on the  
>>wireless LAN, and the ISP assigned one when I get a GPRS connection  
>>through my phone over bluetooth, so the dtnd on my server could  
>>potentially respond to a changing IP address when opening a link.  Is  
>>this feasible?
>>
>>cheers
>>
>>Darren
>>
>>In theory, theory and practice are the same.  In practice, they are not.
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>    
>>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

Date: Thu, 24 Mar 2005 11:39:52 -0800
From: Michael Demmer <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Using getaddrinfo() on Mac OS X causes bad name/address lookup in dtnd
Mail-Followup-To: Darren Long <[email-masked]>, [email-masked]
Sender: [email-masked]

Thanks. I've actually done a better fix that passes the appropriate
hints to getaddrinfo() to force it to return an IPv4 address, which
I've tested and works on OS X.

This fix is currently available from the CVS snapshot, and will be
folded into a bug fix release coming soon.

-m

> Hi,
> 
> I seem to have found an issue with dns lookups in dtnd running on Mac  
> OS X.
> 
> With:
> 	 link add tcp0 host://name:5000 ONDEMAND tcp
> 
> added to my dtn.conf, I got connection attempts to strange IP adresses.  
>  Correct behaviour was observed when I replaced name with the IP  
> address in the dtn.conf line instead.
> 
> As this works fine on my intel based Linux box, but not on the PowerPC  
> based iBook. I dug into the code and found in NetUtils.cc in function:
> 	int gethostbyname(const char* name, in_addr_t* addr)
> 
> on line number 166:
> 
> 	    err = getaddrinfo(name, 0, 0, &res);
> 
> the call results in an incorrect address being returned via addr, as  
> show in context below.
> 
> /* comment out this block for Mac OS X workaround
> #elif defined(HAVE_GETADDRINFO)
> 
>     struct addrinfo *res;
>     int              err;
> 
>     err = getaddrinfo(name, 0, 0, &res);
>     if(err != 0)
>         return -1;
> 
>     ASSERT(res != 0);
>     *addr = ((struct in_addr*) &res->ai_addr)->s_addr;
> 
>     freeaddrinfo(res);
>     return 0;
> 
> */
> /* End Mac OS X workaround
> 
> #elif defined(HAVE_GETHOSTBYNAME)
> 
> 
> Commenting out the #elif defined(HAVE_GETADDRINFO) block lets the name  
> lookup processing be handled by the #elif defined(HAVE_GETHOSTBYNAME)  
> block, resulting in a call to getaaddrinfo() instead.  I'm not sure  
> what side affects this may have, but for a quick hack it seems to be  
> successful, and the name lookups now return valid IPv4 addresses.
> 
> I've noticed that other sites report problems with getaddrinfo on Mac  
> OS X  
> (http://www.geektimes.com/macintosh/os/x/10_0/and/ 
> openssh_install.html).  I'm not sure that I'm best suited to figuring  
> out a long-term solution.
> 
> I'm keen to find a way to make better use of dynamic DNS  now.  With a  
> dyndns.org client running on my iBook, I'd like my server to be able to  
> find my iBook both on my wireless LAN and when I'm out in the world  
> using GPRS.  Nicely enough, the dyndns.org client on the iBook results  
> in the dynamic DNS system reporting my local private IP when I'm on the  
> wireless LAN, and the ISP assigned one when I get a GPRS connection  
> through my phone over bluetooth, so the dtnd on my server could  
> potentially respond to a changing IP address when opening a link.  Is  
> this feasible?
> 
> cheers
> 
> Darren
> 
> In theory, theory and practice are the same.  In practice, they are not.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 24 Mar 2005 11:32:02 -0800
From: Melissa Ho <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] dtn-users mailing list
Sender: [email-masked]

Hi!

For those of you using the DTN reference implementation, or interested 
in using it, we have established a dtn-users mailing list.

To post, email:
  [email-masked]

To subscribe, visit the list info page here:
  http://mailman.dtnrg.org/mailman/listinfo/dtn-users

All future questions specific to the reference implementation, including 
how the code works, how to configure it or  how to compile it should be 
posted to this new list (subscription required).  The archives will be 
publicly available.

Bugs should still be posted to [email-masked]

Melissa

Date: Thu, 24 Mar 2005 09:50:09 -0800
From: Michael Demmer <[email-masked]>
To: Jeff Wilson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] contributing
Mail-Followup-To: Jeff Wilson <[email-masked]>, [email-masked]
Sender: [email-masked]

> I recently downloaded and installed the 2.1.0 version.  Where can I
> read more about contributing to the DTN implementation?  I have two
> goals:  1) implement a new routing strategy, and 2) implement a new
> convergence layer.

Great. Contributions are of course appreciated.

> For the convergence layer, I found and printed the excellent
> document, clapi_doc.ps ...

Actually, this document refers to the first version of the DTN
implementation, not the DTN2 version, so it's basically of no use to
you. I'll remove it from the repository so there's no more confusion.

> is there something similar for the routing algorithms?  I found
> Melissa's routingreqs.txt from last April, and the impl* discussion
> ... did I miss some others?

Not really. More documentation would of course be appreciated, but
no-one so far has had the time or resources to work on this. 

> I haven't yet figured out how to search the archives on dtn-interest
> (well, Google - duh!), that's probably my next step.  Is this the
> right list for asking these kinds of questions?

I'd say yes, for now. We will be setting up a dtn-users mailing list
in the future for questions like these that are specific to the
reference implementation.

-m

Date: Thu, 24 Mar 2005 09:34:56 -0800
From: Michael Demmer <[email-masked]>
To: Agam Brahma <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Regarding simulation
Mail-Followup-To: Agam Brahma <[email-masked]>, [email-masked]
Sender: [email-masked]

> ok .... and how soon will that be available ?

Well -- currently I'm the only person who'se been working on it and I
have several other committments that will take precedence. If you (or
anyone else on the list) is motivated to help out with the
development, I would of course appreciate it. As I said previously,
any new progress will be announced here on the mailing list.

-m

Date: Thu, 24 Mar 2005 09:26:05 -0600
From: Jeff Wilson <[email-masked]>
Reply-To: Jeff Wilson <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] contributing
Sender: [email-masked]

I recently downloaded and installed the 2.1.0 version.  Where can I
read more about contributing to the DTN implementation?  I have two
goals:  1) implement a new routing strategy, and 2) implement a new
convergence layer.

For the convergence layer, I found and printed the excellent document,
clapi_doc.ps ... is there something similar for the routing
algorithms?  I found Melissa's routingreqs.txt from last April, and
the impl* discussion ... did I miss some others?  I haven't yet
figured out how to search the archives on dtn-interest (well, Google -
duh!), that's probably my next step.  Is this the right list for
asking these kinds of questions?

    Thanks for your time,

    Jeff Wilson
    Baylor University (Master's candidate, Computer Science)
    Waco, TX

Date: Thu, 24 Mar 2005 10:59:33 +0000
From: Agam Brahma <[email-masked]>
Reply-To: Agam Brahma <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding simulation
Sender: [email-masked]

ok .... and how soon will that be available ?

regards,
agam

On Wed, 23 Mar 2005 18:02:11 -0800, Michael Demmer
<[email-masked]> wrote:
> 
> > any pointers on using the simulator provided with the DTN reference
> > implementation -- and how it compares with the java-based simulator ?
> 
> at present, the simulator in the DTN reference implementation is
> incomplete, so the java based one will likely be your best bet.
> 
> i will post an announcement when the former is available, probably in
> conjunction with a new reference implementation release announcement.
> 
> -m
> 

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Date: Wed, 23 Mar 2005 18:02:11 -0800
From: Michael Demmer <[email-masked]>
To: Agam Brahma <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Regarding simulation
Mail-Followup-To: Agam Brahma <[email-masked]>, [email-masked]
Sender: [email-masked]

> any pointers on using the simulator provided with the DTN reference
> implementation -- and how it compares with the java-based simulator ?

at present, the simulator in the DTN reference implementation is
incomplete, so the java based one will likely be your best bet.

i will post an announcement when the former is available, probably in
conjunction with a new reference implementation release announcement.

-m

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project
To: [email-masked] (Stephen Farrell)
Date: Tue, 22 Mar 2005 17:23:10 -0500 (EST)
Cc: [email-masked], [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

Hi Stephen,

> Hi Rajesh,
> 
> >   - Disruptions occurring at short timescales (the focus is on tolerance 
> >     to delays at large timescales)
> 
> I think you're correct in this and that its an interesting twist
> on how we've (well, me anyway;-) approached parts of DTN.
> 
> When I started in on this IPN stuff, I found some of the tutorial-like
> emails that the JPL folks sent to be very useful in understanding the
> types of delay and disruption an IPN could experience.
> 
> Do you guys have any disruption scenarios (esp. if you can indicate
> possible timings and tolerances) that would explain the types of use
> case you'd like supported?

The following examples come to mind.

* High mobility, say, the duration of the contact is comparable to the
  link RTT.  If there is only time to either send a frame or receive
  a frame before the node moves out of range, then traditional neighbor 
  discovery using beacons will not work well.  By high mobility, I do 
  not necessarily mean the speed the node is traveling at.  A ground 
  vehicle driving by a sensor field at say 60 mph dwells within the 
  communications range of individual sensor nodes for a much shorter 
  time than say a UAV traveling overhead at four times the speed might 
  (assuming the UAV has a larger communications footprint etc.). OTOH,
  the UAV seeing all the sensor nodes at once may have less spatial 
  reuse, which is another kind of disruption.

* Directional antennas, say, with a fixed number of switched beams that
  are fewer than the number of potential neighbors, links are disrupted 
  for short durations.  (Currently, a solution to this problem involves 
  hiding the link dynamics from the routing protocol -- using virtual
  adjacencies -- and silently queuing the packet until the beam can be 
  switched.) This could instead be modeled as scheduled DTN contacts (but 
  the timescales will be in ms). 

We do not have more concrete scenarios (use cases) specified yet.  

> For example, from your comments, I'm guessing that you think its
> likely that you'd see disruption that lasts for much less than the
> duration of a scheduled contact, but would multiple such disruptions
> in a single scheduled contact be likely and/or how often would a
> recoverable flow of bytes (from the same bundle/fragment/LTP segment)
> tend to follow such disruption(s)?

I had not thought about disruptions to scheduled contacts, but I suppose 
those are possible.  This is exacerbated when link RTTs are large relative 
to each contact duration such that discovery / neighbor-maintenance is 
not a valid option.

> Cheers,
> Stephen.

-Rajesh

Date: Wed, 23 Mar 2005 03:43:41 +0530
From: Agam Brahma <[email-masked]>
Reply-To: Agam Brahma <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Regarding simulation
Sender: [email-masked]

hi

any pointers on using the simulator provided with the DTN reference
implementation -- and how it compares with the java-based simulator ?

regards,
Agam
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

To: [email-masked]
Date: Tue, 22 Mar 2005 11:08:38 -0800
From: Kevin Fall <[email-masked]>
Subject: [dtn-interest] fyi - new IRTF announce list
Sender: [email-masked]

------- Forwarded Message

>
> From:  [email-masked]
> Subject: [rgchairs] New Mailing List: IRTF-Announce
> Date:  Tue, 22 Mar 2005 10:57:26 PST
>
> A new mailing list has been created to inform the Internet community
> of activities relating to the Internet Research Task Force. This
> broadcast list will receive notices of IRTF Research Group creation
> and termination, document publication, invitations for feedback and
> participation, and other IRTF activities. Subscription to this list
> is list is open to anyone. Posting to this list is at the discretion
> of the IRTF Chair.
> 
> Subscription URL:
> https://www1.ietf.org/mailman/listinfo/irtf-announce
> 
> Archive URL:
> http://www1.ietf.org/mail-archive/web/irtf-announce/current/index.html
> 
> Please forward this notice to Internet research communities who might
> find it of interest.  (RGCHAIRS, please forward this to your RGs.)
> 
> --Aaron
>   IRTF Chair

------- End of Forwarded Message

Date: Tue, 22 Mar 2005 09:44:14 -0800 (PST)
From: Sushant Jain <[email-masked]>
To: Piero Cornice <[email-masked]>
cc: [email-masked]
Subject: Re: [dtn-interest] routing in DTNs and other stuff...
Sender: [email-masked]

>    i'm Piero from Italy. I'm writing my final discussion about DTNs and i have
> to describe the routing mechanism, so i read "Routing in a Delay Tolerant
> Networking" by S. Jain, K. Fall, R. Patra. It describes some routing techniques,
> but i didn't undestand which of them is actually used by DTN architecture. Can
> anybody tell me?

The DTN architecture does not talk about specifics of routing
algorithms used (and hence does not use any routing algorithm as such). 
Routing algorithms are wide open for research
and will vary depending upon type of connectivity patterns in DTN 
(scheduled, opportunistic, etc).
The paper talks about one set of routing mechanisms suitable for
scheduled connectivity and evaluates the tradeoffs using simulation.

Hope that helps,
if you have more questions feel free to direct them to me,

Sushant

> 
> Second question: i have to modify "iperf" (a well-known open-source software) in
> order to use it with DTN and make benchmarks. Is there anybody who already tried
> do to that? Or anybody knows a good benchmark sw for DTNs?
> 
> Thank you,
>    Piero
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Tue, 22 Mar 2005 16:08:03 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] routing in DTNs and other stuff...
Sender: [email-masked]

Hello,
   i'm Piero from Italy. I'm writing my final discussion about DTNs and i have
to describe the routing mechanism, so i read "Routing in a Delay Tolerant
Networking" by S. Jain, K. Fall, R. Patra. It describes some routing techniques,
but i didn't undestand which of them is actually used by DTN architecture. Can
anybody tell me?

Second question: i have to modify "iperf" (a well-known open-source software) in
order to use it with DTN and make benchmarks. Is there anybody who already tried
do to that? Or anybody knows a good benchmark sw for DTNs?

Thank you,
   Piero

Date: Mon, 21 Mar 2005 18:38:22 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project team
Sender: [email-masked]

Hi Rajesh,

>   - Disruptions occurring at short timescales (the focus is on tolerance 
>     to delays at large timescales)

I think you're correct in this and that its an interesting twist
on how we've (well, me anyway;-) approached parts of DTN.

When I started in on this IPN stuff, I found some of the tutorial-like
emails that the JPL folks sent to be very useful in understanding the
types of delay and disruption an IPN could experience.

Do you guys have any disruption scenarios (esp. if you can indicate
possible timings and tolerances) that would explain the types of use
case you'd like supported?

For example, from your comments, I'm guessing that you think its
likely that you'd see disruption that lasts for much less than the
duration of a scheduled contact, but would multiple such disruptions
in a single scheduled contact be likely and/or how often would a
recoverable flow of bytes (from the same bundle/fragment/LTP segment)
tend to follow such disruption(s)?

Cheers,
Stephen.

Date: Mon, 21 Mar 2005 18:25:22 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Michael Demmer <[email-masked]>, Melissa Ho <[email-masked]>, "Scott Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

Without going into detail I'd like to see support
for >4GB bundles, but without forcing 32-bit
implementations to be non-compliant.

I guess this may amount to a new error code "bundle too
big" or somesuch, otherwise the 1st 4GB is gonna drop
on the floor which'd be painful. So, if the overall
payload length isn't there (e.g. in fragments?), then
define an extension header and RECOMMEND that it be
used for BIG bundles. Then #define BIG to be whatever's
appropriate in your environment.

Also note that that extension header may be needed if
the payload length isn't known at the start of the
bundle (e.g. for streaming-like applications). In some
other work I've done I defined an estimated payload
length extension for this reason.

Lastly, do we need to allow 16- or 8-bit implementations
to be compliant? If so do they need anything similar?

Stephen.

Rajesh Krishnan wrote:

>>I'm not strictly opposed to it, I just feel like the utility doesn't
>>totally pay for the constraint. Perhaps we could structure the
>>protocol spec to make > 32 bit support optional?
> 
> 
> I agree that it may not pay if we only consider utility in the short term 
> and within a narrow application focus.  
> 
> A (IETF-) standardized message-switching service tolerant to disconnection
> (namely DTN) could radically change the landscape of distributed filesystems/
> databases/storage/middleware/applications.  I can imagine high-performance 
> message-passing multicomputer networks based on DTN some day.   While these 
> applications may not be the primary targets for DTN today, they may well end 
> up as important areas where DTN gets used.  I cannot argue that any of these
> will be totally crippled by 4G message sizes. Yet it would be nice to be able 
> to send a dual layer DVD+R image in a single bundle.
> 
> I have said enough already, so I'll let others weigh in on this.
> 
> 
>>>P.S.: If TCP is the underlay, and we fragment messages a lot, then the 
>>>      bundle daemon could incorporate techniques such as persistent 
>>>      connections (a la HTTP 1.1), or sharing path capacity state across 
>>>      TCP connections to avoid having to open up the pipe (via slow-start) 
>>>      multiple times.
>>
>>Already done. The TCP CL currently pipelines a connection for multiple
>>bundles.
> 
> 
> Mike, that's excellent.  Thanks, I should go back and read your paper again.
> 
> -Rajesh
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 
> 

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Sun, 20 Mar 2005 20:45:31 +0000
Subject: [dtn-interest] Using getaddrinfo() on Mac OS X causes bad name/address lookup in dtnd
Sender: [email-masked]

Hi,

I seem to have found an issue with dns lookups in dtnd running on Mac  
OS X.

With:
	 link add tcp0 host://name:5000 ONDEMAND tcp

added to my dtn.conf, I got connection attempts to strange IP adresses.  
  Correct behaviour was observed when I replaced name with the IP  
address in the dtn.conf line instead.

As this works fine on my intel based Linux box, but not on the PowerPC  
based iBook. I dug into the code and found in NetUtils.cc in function:
	int gethostbyname(const char* name, in_addr_t* addr)

on line number 166:

	    err = getaddrinfo(name, 0, 0, &res);

the call results in an incorrect address being returned via addr, as  
show in context below.

/* comment out this block for Mac OS X workaround
#elif defined(HAVE_GETADDRINFO)

     struct addrinfo *res;
     int              err;

     err = getaddrinfo(name, 0, 0, &res);
     if(err != 0)
         return -1;

     ASSERT(res != 0);
     *addr = ((struct in_addr*) &res->ai_addr)->s_addr;

     freeaddrinfo(res);
     return 0;

*/
/* End Mac OS X workaround

#elif defined(HAVE_GETHOSTBYNAME)

Commenting out the #elif defined(HAVE_GETADDRINFO) block lets the name  
lookup processing be handled by the #elif defined(HAVE_GETHOSTBYNAME)  
block, resulting in a call to getaaddrinfo() instead.  I'm not sure  
what side affects this may have, but for a quick hack it seems to be  
successful, and the name lookups now return valid IPv4 addresses.

I've noticed that other sites report problems with getaddrinfo on Mac  
OS X  
(http://www.geektimes.com/macintosh/os/x/10_0/and/ 
openssh_install.html).  I'm not sure that I'm best suited to figuring  
out a long-term solution.

I'm keen to find a way to make better use of dynamic DNS  now.  With a  
dyndns.org client running on my iBook, I'd like my server to be able to  
find my iBook both on my wireless LAN and when I'm out in the world  
using GPRS.  Nicely enough, the dyndns.org client on the iBook results  
in the dynamic DNS system reporting my local private IP when I'm on the  
wireless LAN, and the ISP assigned one when I get a GPRS connection  
through my phone over bluetooth, so the dtnd on my server could  
potentially respond to a changing IP address when opening a link.  Is  
this feasible?

cheers

Darren

In theory, theory and practice are the same.  In practice, they are not.

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
To: [email-masked] (Michael Demmer)
Date: Fri, 18 Mar 2005 18:46:14 -0500 (EST)
Cc: [email-masked] (Rajesh Krishnan), [email-masked] (Melissa Ho), [email-masked] (Scott Keith L.), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

> I'm not strictly opposed to it, I just feel like the utility doesn't
> totally pay for the constraint. Perhaps we could structure the
> protocol spec to make > 32 bit support optional?

I agree that it may not pay if we only consider utility in the short term 
and within a narrow application focus.  

A (IETF-) standardized message-switching service tolerant to disconnection
(namely DTN) could radically change the landscape of distributed filesystems/
databases/storage/middleware/applications.  I can imagine high-performance 
message-passing multicomputer networks based on DTN some day.   While these 
applications may not be the primary targets for DTN today, they may well end 
up as important areas where DTN gets used.  I cannot argue that any of these
will be totally crippled by 4G message sizes. Yet it would be nice to be able 
to send a dual layer DVD+R image in a single bundle.

I have said enough already, so I'll let others weigh in on this.

> > P.S.: If TCP is the underlay, and we fragment messages a lot, then the 
> >       bundle daemon could incorporate techniques such as persistent 
> >       connections (a la HTTP 1.1), or sharing path capacity state across 
> >       TCP connections to avoid having to open up the pipe (via slow-start) 
> >       multiple times.
> 
> Already done. The TCP CL currently pipelines a connection for multiple
> bundles.

Mike, that's excellent.  Thanks, I should go back and read your paper again.

-Rajesh

Date: Fri, 18 Mar 2005 14:19:04 -0800
From: Michael Demmer <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Cc: Melissa Ho <[email-masked]>, "Scott Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Mail-Followup-To: Rajesh Krishnan <[email-masked]>, Melissa Ho <[email-masked]>, "Scott Keith L." <[email-masked]>, [email-masked]
Sender: [email-masked]

> The primary argument for >4GB is future-proofing.  Implementation
> expediency in a 32-bit wor(l)d of today may not matter in a 64-bit
> wor(l)d of the future.

Point taken and agreeed. But another facet of the question is whether
it becomes a requirement for all systems that will run the bundle
protocol that they be capable of handling 64 bit bundle sizes (and by
implication, corresponding file offsets). 

I'm not strictly opposed to it, I just feel like the utility doesn't
totally pay for the constraint. Perhaps we could structure the
protocol spec to make > 32 bit support optional?

> It is true that the additional fragmentation header does not add
> much overhead to a large payload, however, we must also consider the
> additional state/processing (if any) at each node due to
> fragmentation.

Agreed. There are other ways around this being a burden.

> Lesser issues that are engineerable.  Depending on the protocols
> used, fragmentation might introduce additional round trip delays
> (e.g. if a protocol ever gates on outstanding bundle status
> indications).  Also if many payloads in a traffic mix are large,
> then with fragmentation, there is an increased chance of having many
> partially delivered bundles at a given time (depending on how the
> scheduling gets done).

Perhaps. Though I'd counter that it seems much easier for a network to
get several fragments through than requiring that each hop be able to
completely transfer a > 4GB payload.

> P.S.: If TCP is the underlay, and we fragment messages a lot, then the 
>       bundle daemon could incorporate techniques such as persistent 
>       connections (a la HTTP 1.1), or sharing path capacity state across 
>       TCP connections to avoid having to open up the pipe (via slow-start) 
>       multiple times.

Already done. The TCP CL currently pipelines a connection for multiple
bundles.

-m

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
To: [email-masked] (Michael Demmer)
Date: Fri, 18 Mar 2005 16:55:53 -0500 (EST)
Cc: [email-masked] (Melissa Ho), [email-masked] (Scott Keith L.), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

The primary argument for >4GB is future-proofing.  Implementation 
expediency in a 32-bit wor(l)d of today may not matter in a 64-bit 
wor(l)d of the future.

It is true that the additional fragmentation header does not add much 
overhead to a large payload, however, we must also consider the additional 
state/processing (if any) at each node due to fragmentation.  

Lesser issues that are engineerable.  Depending on the protocols used, 
fragmentation might introduce additional round trip delays (e.g. if a 
protocol ever gates on outstanding bundle status indications).  Also if 
many payloads in a traffic mix are large, then with fragmentation, there 
is an increased chance of having many partially delivered bundles at a 
given time (depending on how the scheduling gets done). 

-Rajesh

P.S.: If TCP is the underlay, and we fragment messages a lot, then the 
      bundle daemon could incorporate techniques such as persistent 
      connections (a la HTTP 1.1), or sharing path capacity state across 
      TCP connections to avoid having to open up the pipe (via slow-start) 
      multiple times.

> > How about using one byte for the length of the length field,
> > followed by the length itself?
> 
> I'm not a huge fan of this since it ends up wasting a bunch of bits in
> both the flags and this new length-of-length field.
> 
> The former only has a handful of flags, and the latter only really
> requires two bits (0x0 = 1 byte, 0x1 = 2 bytes, 0x2 = 4 bytes, 0x3 = 8
> bytes). It sounds like maybe the thing to is define something like
> this as a length-of-length format, like Keith alluded to in his
> original email.
> 
> You do raise a good point regarding the fragmentation header, in which
> if we allow lengths to be larger than 32 bits, both the length and the
> offset field need to be self-delimiting.
> 
> I guess the big picture question is whether we allow bundles to be
> bigger than 4GB, or if we require that to support bigger application
> payloads, the sender daemon must fragment. Personally, my inclination
> is that the latter makes the implementation easier, as we can assume a
> stnadard 32 bit word for all lengths and offsets within the bundle
> processing. Also, the overhead of adding a separate fragmentation
> header and bundle header is negligible as a percentage of the overall
> huge payload.
> 
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Fri, 18 Mar 2005 10:00:50 -0800
From: Michael Demmer <[email-masked]>
To: Melissa Ho <[email-masked]>
Cc: "Scott,Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Mail-Followup-To: Melissa Ho <[email-masked]>, "Scott,Keith L." <[email-masked]>, [email-masked]
Sender: [email-masked]

> How about using one byte for the length of the length field,
> followed by the length itself?

I'm not a huge fan of this since it ends up wasting a bunch of bits in
both the flags and this new length-of-length field.

The former only has a handful of flags, and the latter only really
requires two bits (0x0 = 1 byte, 0x1 = 2 bytes, 0x2 = 4 bytes, 0x3 = 8
bytes). It sounds like maybe the thing to is define something like
this as a length-of-length format, like Keith alluded to in his
original email.

You do raise a good point regarding the fragmentation header, in which
if we allow lengths to be larger than 32 bits, both the length and the
offset field need to be self-delimiting.

I guess the big picture question is whether we allow bundles to be
bigger than 4GB, or if we require that to support bigger application
payloads, the sender daemon must fragment. Personally, my inclination
is that the latter makes the implementation easier, as we can assume a
stnadard 32 bit word for all lengths and offsets within the bundle
processing. Also, the overhead of adding a separate fragmentation
header and bundle header is negligible as a percentage of the overall
huge payload.

-m

Date: Fri, 18 Mar 2005 09:49:44 -0800
From: Melissa Ho <[email-masked]>
To: Michael Demmer <[email-masked]>
CC: "Scott,Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

Don't forget that if we allow length extensions for the payload, we need 
to modify the fragment header (orig payload length) field accordingly.

How about using one byte for the length of the length field, followed by 
the length itself?

Melissa

Michael Demmer wrote:

>In terms of the questions regarding the header length field and header
>flags interpretation, my preference would be to do the following.
>Suggestions and criticisms are certainly welcomed.
>
>As Keith describes, all headers except the primary bundle header are
>preceded by a common top part. In terms of the length field, I'd like
>to advocate using two bytes by default. We could then use one bit from
>the flags to denote an optional 'length extension' that immediately
>follows the top part.
>
>Thus a header with length <= 16K would be:
>
>+----------------+----------------+----------------+----------------+ 
>|  Header Type   | Flags (ext=0)  |            length               |
>+----------------+----------------+----------------+----------------+ 
>
>and header with length <= 4GB would be:
>
>+----------------+----------------+----------------+----------------+ 
>|  Header Type   | Flags (ext=1)  |            length               
>+----------------+----------------+----------------+----------------+ 
>             length               |
>+----------------+----------------+ 
>
>This has a couple properties that I like: First of all, it obviates
>the need for any additional formatting for the PayloadHeader, since as
>Keith points out, we will get rid of the payload class field, and the
>payload length is expressable in the above format. It also means that
>the default header top part fits in one word, and so most of the other
>headers will also be word-aligned on the wire. This addresses Keith's
>point #4 as well, as he mentioned.
>
>If we need to (though I don't think we will), we could use another bit
>to allow 64-bit lengths.
>
>As to the question of what to do with the flags, I would prefer the
>more expressible alternative that Keith proposed -- that there are at
>least three flag options for:
>
>  1) forward the unknown header unmodified
>  2) skip and remove the unknown header
>  3) delete the bundle
>
>That's all for now.
>
>-mike
>
>
>  
>
>>The bundle protocol spec internet draft is nearly expired, which is an
>>excellent opportunity to make additions / clarifications. Here are a number
>>of changes I'd like to discuss.
>>
>> 
>>
>>1. Remove the 'payload class' field in the payload header. The payload class
>>is a way to tell a bundle daemon that a particular bundle is a 'bundle
>>system' message such as a custody acknowledgement, end-to-end
>>acknowledgement, etc. The concept of a (set of) bundle-level 'administrative
>>endpoints' for bundle routers has been proposed, where a particular bundle
>>router would have a (set of) endpoints whose purpose is to handle these
>>system-level messages. This would obviate the need for the payload class
>>byte.
>>
>>2. Change the 'next header type' field in each of the bundle headers to be
>>'current header type'. It would identify the type of the current header.
>>
>>3. Add a length field to all headers except the primary bundle header. These
>>length fields would immediately follow the header type fields and be XX
>>bytes in length. [QUESTION: 1 byte, 2 bytes, self-delimiting integer, ...]
>>Self-delimiting integers might be the way to go, but they themselves are
>>variable-length. The length field specifies the length of the ENTIRE header,
>>including the 'header type' byte. This will make it easier to parse past
>>headers that are either not needed for a particular operation or not
>>understood by the router.
>>
>>4. Make sure that the the dictionary header length field can hold several
>>full-size DTN tuple strings. The rationale for this is that each individual
>>string record can be up to 255 bytes in length; 1 byte here would never be
>>enough. [This will not be an issue if the answer to (3) is either
>>self-delimiting integer or 2 bytes; this is an issue if the answer to 3 is 1
>>byte length fields].
>>
>>I submit that we should consider adding a NOTE saying that implementations
>>MAY pad the dictionary header by specifying a length value that is longer
>>than the sum of the string records.
>>
>>5. State explicitly that if an implementation receives a header with a type
>>that it does not understand, that it handles it as specified in the header's
>>flags field (described below). This requires that the 'top part of' headers
>>have a standard format [header type, length, flags], Header type is 1 byte
>>identifying the header. Length is as per (3), and flags is a set of flags
>>that says what should be done with the header. Possible values for the flags
>>could be: silently skip the header and leave it in place, silently skip the
>>header and remove it, drop the bundle (and issue an error message), ...
>>QUESTION: do we need the flags, or just say that implementaitons that don't
>>understand a particular option just silently skip over it?
>>
>>5a. The combination of (3,5) allows experimenters to define new header types
>>(with dtnrg as the interim numbering authority?) and experiment with them.
>>
>>=====================================================
>>
>>QUESTIONS (things that we may want but that I think are less well-developed
>>than the above). Discussion highly encouraged.
>>
>>=====================================================
>>
>>If we go to using a (current) header type, then we free up a byte in the
>>primary bundle header. Thoughts about what to do with that?
>>
>>---
>>
>>Creation Timestamp: Recall that the combination of (source endpoint ID,
>>creation timestamp) is intended to uniquely identify a bundle. If an
>>implementation were to be able to generate bundles fast enough that the
>>source timestamp wouldn't tick between bundles, this would be a problem.
>>Possible solutions to this are:
>>
>>1. Say that the implementation is responsible for ensuring that the source
>>timestamp is monotonically increasing with each bundle sent out. It would be
>>understood that the source timestamp might then represent only 'approximate
>>time', since a (bundle agent/router) implementation might need to mess with
>>the low order bits. It would be important that implementations NOT corrupt
>>the sending timestamp so much as to affect the seconds, since this would
>>affect the bundle's lifespan.
>>
>>2. Change the definition of the creation timestamp in some way.
>>
>>---
>>
>>Time To Live: Each bundle carries a time to live specified in seconds. There
>>is concern that in some environments, bundles may need to time out on
>>sub-second timescales. A proposed solution to this is that for these
>>environments, bundle routers implement some other extension header (a
>>'quick-death' header) that carries the sub-second timeout value. The
>>alternative would be to change the units of the time to live field.
>>
>>---
>>
>>Source Routing Header: There may be utility to be able to source-route
>>bundles. What if the header for source routing had the following format:
>>
>>[Header Type (1B), Length (2B), # of entries (1B), current index (1B), list
>>of waypoints (DTN endpoint identifiers)]
>>
>>The '# of entries' identifies the number of entries in the waypoints list
>>
>>The 'current index' identifies the waypoint towards which the bundle is
>>currently being routed.
>>
>>Format for each waypoint:
>>
>>[length(1B), flags(1B), endpoint identifier]
>>
>>Flags would contain at least 1 bit that identifies the waypoint as
>>(loose/strict). Endpoint identifiers might be the administratinve endpoints
>>of bundle routers, or somehow otherwise identified as not being applications
>>to demux to.
>>
>> 
>>
>>==end==
>>
>> 
>>
>> 
>>
>> 
>>
>>    
>>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

Date: Fri, 18 Mar 2005 08:02:03 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

Scott,Keith L. wrote:
> The bundle protocol spec internet draft is nearly expired, which is an 
> excellent opportunity to make additions / clarifications. Here are a 
> number of changes I'd like to discuss. 
> 
> 1. Remove the 'payload class' field in the payload header. The payload 
> class is a way to tell a bundle daemon that a particular bundle is a 
> 'bundle system' message such as a custody acknowledgement, end-to-end 
> acknowledgement, etc. The concept of a (set of) bundle-level 
> 'administrative endpoints' for bundle routers has been proposed, where a 
> particular bundle router would have a (set of) endpoints whose purpose 
> is to handle these system-level messages. This would obviate the need 
> for the payload class byte.

On reflection, I don't think this works.  We've currently got two kinds of administrative payloads: custody transfer signals, which are always sent to administrative endpoints, and status reports, which may be sent to administrative endpoints but which are by default sent to the source application endpoint (which is the default "report-to").  When an application endpoint receives a bundle, it needs to know whether the bundle's payload is a status report or not; it can't tell by looking inside the payload, because we don't forbid applications from formatting payloads that might happen to have the same size and format as status reports.

However, I do like the idea of losing the payload class field if we can instead steal a flag bit from somewhere in the primary header to serve the same purpose.  The type of administrative payload (CT signal or status report) is already inside the payload where it belongs.

On a related topic: I believe we are going to need some sort of standard way to map destination endpoint ID (which is an application endpoint ID, i.e., it includes what I think was once termed "local stuff") to the endpoint ID of the bundle agent where that application endpoint is registered -- an administrative endpoint ID -- so that bundles can be routed to agents and then delivered to applications.  We currently do this by stripping off the end of the "admin part" everything after the last '/', but that's not formally defined anywhere.  Is that our final and best answer to this problem?

> 2. Change the 'next header type' field in each of the bundle headers to 
> be 'current header type'. It would identify the type of the current header.

We talked about this in Colorado Springs, I remember.  At the time, we felt we needed to do it in order to accommodate having the Bundle Authentication Header precede the primary header, but I think we've since decided that the latter is not necessary.  Does that remove the motivation for this change?  The two disadvantages of changing are (1) a significant impact on implementations and (2) the "current header type" approach makes it impossible to simply omit the payload header for a payload-free bundle (which is currently possible because you can always code "no more headers" as the "next header type").

> 3. Add a length field to all headers except the primary bundle header. 
> These length fields would immediately follow the header type fields and 
> be XX bytes in length. [QUESTION: 1 byte, 2 bytes, self-delimiting 
> integer, ...] Self-delimiting integers might be the way to go, but they 
> themselves are variable-length. The length field specifies the length of 
> the ENTIRE header, including the 'header type' byte. This will make it 
> easier to parse past headers that are either not needed for a particular 
> operation or not understood by the router.

Enabling bundle agents to deal with unrecognized header types is the really compelling advantage of this modification, but I think that just means that it's required in every "extension" header: the standard header types defined in the Bundling specification don't need it, because the length of each can already be determined one way or another.

I am concerned that our headers seem to keep expanding.  Header compression in the convergence layer is not an answer (I am pretty sure that it won't always be available), and if the header overhead on bundles gets out of hand there is no way we're going to be able to use DTN on space flight missions.

Non-standard, experimental, extension headers clearly should contain lengths and (as you propose below) maybe some standardized processing flags, but let's not require every bundling-compliant network carrying strictly operational data to move a lot of unnecessary excess baggage.

> 4. Make sure that the the dictionary header length field can hold 
> several full-size DTN tuple strings. The rationale for this is that each 
> individual string record can be up to 255 bytes in length; 1 byte here 
> would never be enough. [This will not be an issue if the answer to (3) 
> is either self-delimiting integer or 2 bytes; this is an issue if the 
> answer to 3 is 1 byte length fields].
> 
> I submit that we should consider adding a NOTE saying that 
> implementations MAY pad the dictionary header by specifying a length 
> value that is longer than the sum of the string records.

The system I proposed in my mail of a couple minutes ago would address this.

> 5. State explicitly that if an implementation receives a header with a 
> type that it does not understand, that it handles it as specified in the 
> header's flags field (described below). This requires that the 'top part 
> of' headers have a standard format [header type, length, flags], Header 
> type is 1 byte identifying the header. Length is as per (3), and flags 
> is a set of flags that says what should be done with the header. 
> Possible values for the flags could be: silently skip the header and 
> leave it in place, silently skip the header and remove it, drop the 
> bundle (and issue an error message), ... QUESTION: do we need the flags, 
> or just say that implementaitons that don't understand a particular 
> option just silently skip over it?

Again, this is fine as a structural mandate for all non-standard, experimental headers, but not for the standard headers (primary, dictionary, and payload, at minimum) defined in the Bundling specification.

> 5a. The combination of (3,5) allows experimenters to define new header 
> types (with dtnrg as the interim numbering authority?) and experiment 
> with them.

Sure.

> =====================================================
> 
> QUESTIONS (things that we may want but that I think are less 
> well-developed than the above). Discussion highly encouraged.
> 
> =====================================================
> 
> If we go to using a (current) header type, then we free up a byte in the 
> primary bundle header. Thoughts about what to do with that?

I'm not convinced that we should do this.

> ---
> 
> Creation Timestamp: Recall that the combination of (source endpoint ID, 
> creation timestamp) is intended to uniquely identify a bundle. If an 
> implementation were to be able to generate bundles fast enough that the 
> source timestamp wouldn't tick between bundles, this would be a problem. 
> Possible solutions to this are:
> 
> 1. Say that the implementation is responsible for ensuring that the 
> source timestamp is monotonically increasing with each bundle sent out. 
> It would be understood that the source timestamp might then represent 
> only 'approximate time', since a (bundle agent/router) implementation 
> might need to mess with the low order bits. It would be important that 
> implementations NOT corrupt the sending timestamp so much as to affect 
> the seconds, since this would affect the bundle's lifespan.
> 
> 2. Change the definition of the creation timestamp in some way.

I vote for (1).  The 'seconds' part of creation timestamp needs to be accurate at seconds granularity, the same granularity as lifespan; the fractional part can be anything so long as it's monotonically increasing, since nothing treats it as literal time anyway.

> ---
> 
> Time To Live: Each bundle carries a time to live specified in seconds. 
> There is concern that in some environments, bundles may need to time out 
> on sub-second timescales. A proposed solution to this is that for these 
> environments, bundle routers implement some other extension header (a 
> 'quick-death' header) that carries the sub-second timeout value. The 
> alternative would be to change the units of the time to live field.

I'm concerned that expressing lifespan at finer granularity than seconds would (a) exacerbate our clock synchronization problem and (b) make the header bigger [we'd need a fraction field as well as a seconds field].  Against those disadvantages, I haven't yet heard an argument that convinces me that there's a realistic countervailing advantage.  If sub-second lifetimes are needed, let's put them in an extension header.

> ---
> 
> Source Routing Header: There may be utility to be able to source-route 
> bundles. What if the header for source routing had the following format:
> 
> [Header Type (1B), Length (2B), # of entries (1B), current index (1B), 
> list of waypoints (DTN endpoint identifiers)]
> 
> The '# of entries' identifies the number of entries in the waypoints list
> 
> The 'current index' identifies the waypoint towards which the bundle is 
> currently being routed.
> 
> Format for each waypoint:
> 
> [length(1B), flags(1B), endpoint identifier]
> 
> Flags would contain at least 1 bit that identifies the waypoint as 
> (loose/strict). Endpoint identifiers might be the administratinve 
> endpoints of bundle routers, or somehow otherwise identified as not 
> being applications to demux to.

Sounds okay to me.

Scott

Date: Fri, 18 Mar 2005 08:00:43 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

Scott Burleigh wrote:
> Scott,Keith L. wrote:
> 
>> The bundle protocol spec internet draft is nearly expired, which is an 
>> excellent opportunity to make additions / clarifications. Here are a 
>> number of changes I'd like to discuss.
> 
> 
> I haven't yet had time to read these, but will do that as soon as I can; 
> meanwhile I wanted to post the notes I took from our meetings last week 
> plus a proposal for restructuring the bundle header to accommodate the 
> flat endpoint ID namespace (no region/admin tuple scheme) that I think 
> we tentatively agreed on.

This email didn't get posted automatically because it was too long -- I'd lazily written stuff in Word and converted to PDF and attached the files.  Here's what I was trying to send:

--------------------------------------------------------------
Meeting notes

We’re adding to the Bundling protocol a note that there can be additional “extension” headers, specified in other documents, that must conform to some well-defined set of structural rules (e.g., header type ID must be in some defined list, first byte of the header must be next-header type, etc.).

Source routing header is maybe one of these.

PSH hash must be computed on only those strings in the dictionary header that are referenced by the immutable fields of the primary bundle header: source, destination, report-to.

Identity-based cryptography still a possible solution to some security questions.
Change bundle creation timestamp to seconds.source_counter?  Change other timestamps to struct timeval (seconds.microseconds).

Use the extension headers [separately documented] for almost everything: most or all flavors of fragmentation (including erasure coding), bundle authentication, payload security, network management reporting (parasitic headers on return traffic), others.  What’s left in the core bundle protocol is Primary header, Dictionary header, Payload header.

Creation time: seconds must be a real time value in synchronized (to seconds) time stamp, in UNIX epoch.  The fractional part is merely required to identify the bundle uniquely; it can be a number issued by a time source (e.g., microseconds), an implementation-specific counter value, or an implementation-specific counter value added as an offset to a number issued by a time source.

Granularity of the lifespan must be less than or equal to the granularity of whatever portion of the creation time is issued by a time source.  It’s expressed in seconds.

Endpoint ID is just a single string that is nominally the concatenation of namespace identifiers and names within those indicated namespaces.  URI format; a concatenation of URIs.  Routing table has wildcarded strings matched to (a) other endpoint IDs and (b) convergence layer interfaces.

----------------------------------------------------------------
Bundle header proposal:

--Guidelines

Want a great deal of flexibility in endpoint ID expressions, which are ASCII character strings (some of which may be at least partly Unicoded).

Therefore need to support fairly long strings as endpoint IDs.

But want to keep bundle headers no longer than necessary.

For some environments, moreover, need bundle headers to be as short as possible.
Want to keep computational overhead low in header parsing, interpretation, and construction, for performance.

No formal “region” notion; no formal “tuple” notion.  Each bundle agent routes on however many leading bytes of the destination endpoint ID string are (implicitly or explicitly) topologically meaningful to it.  That is, the meaningful leading bytes of the endpoint ID essentially serve the same purpose as the “region”, but the “region”-like, topologically meaningful portion of the endpoint ID may be of different lengths at different points along the end-to-end route.

--An observation

In many cases two or more of the endpoint IDs in a single bundle’s concatenated header (source, destination, report-to, custodian) may be identical.  This enables us to do some of the same simple data compression we’re already doing:

* Use a dictionary header that is simply a variable-length array of characters, constructed by concatenating the unique endpoint ID strings characterizing the bundle.

* Any single substring within the dictionary header can be represented as an ordered pair (offset, length), here termed a "string reference": the referenced substring is the array of characters beginning at offset bytes from the start of the dictionary header’s character array and extending for the next length bytes.

* In the primary header, we can express each endpoint ID as a string reference.

--Specific proposal

Allow the concatenated character array in the dictionary header of a bundle to have a maximum length of 2048.

Given this constraint, any valid offset within the array can be expressed as an 11-bit integer ((256 * 8) - 1 = 2047), as can any length in the range 1 to 2048 (just add 1 to the 11-bit integer value).  So each string reference can be encoded as the concatenation of two arrays of 12 bits each (offset and length, with the first bit of each reserved for purposes explained below), a total size of 24 bits, i.e., 3 bytes.

Therefore each endpoint ID expression occupies 3 bytes, and all four endpoint IDs for a bundle can be encoded in 12 bytes of primary header – so long as the concatenation of all unique strings used as endpoint IDs has a total length that does not exceed 2048 ASCII characters.  [We’re currently using 4 bytes of primary header for this purpose; this proposal increases primary header length by 8.]  The maximum size of any single endpoint ID string is 512 bytes.

--Catalogued strings

Now, if the first bit of the offset in a given string reference is 1 rather than zero, then we interpret the concatenation of the remaining 11 bits of the offset and all 12 bits of the length as a 23-bit number, ranging from zero to 8,388,607.  This number can be used as an index value identifying a predefined (well-known) catalogued string; this enables a lengthy endpoint ID string to be encoded very economically in a bundle header.

In the extreme, all endpoint IDs may be catalogued strings and the dictionary header may be omitted altogether.  All addressing for the bundle can then be encoded in 12 bytes.

Catalogued strings would be especially useful for highly resource-constrained environments, such as deep space and perhaps some kinds of mobile tactical network.
Catalogued strings could all be assigned by a single central naming authority, or alternatively the first 11 bits of each catalogued string number could identify one of 2047 centrally assigned name spaces and the last 12 bits could identify one of the 4095 names assigned by the designated naming authority for that name space.

--Also, <none>

We also need a way of indicating the null endpoint ID, e.g., the current custodian for a non-custodial bundle needs to be expressed as <none> somehow.  We can use the first bit of the length in a string reference for this purpose: if it’s 1 rather than zero (and the first of the offset is not zero) then the string reference is interpreted as <none>.

So the general procedure for interpreting a given string reference would be:

If first bit of offset is 1:

	Use the remaining 23 bits of the concatenated offset/length as an integer to retrieve a catalogued string, return it.

Else (not a catalogued string):

	If the first bit of length is 1 
		Return <none>. 
	Else:
		Return the substring of the dictionary header's byte array starting at the indicated offset and continuing for 1 more than the indicated length.

--Routing

Given this representation system, routing can still be done entirely on the basis of endpoint ID string expressions, possibly wild-carded.  The ASCII string representation of the destination endpoint ID can always be retrieved from a catalogue and/or extracted from the dictionary header.  Then the reconstituted endpoint ID string can be used as the search argument for lookup in a routing table – or a source route can be parsed out of it, or whatever.

Note that routing is completely independent of endpoint ID representation; endpoint IDs may – but need not – have explicit topological significance.

Date: Thu, 17 Mar 2005 16:06:54 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] new dtn-security mailing list
Sender: [email-masked]

Hi all,

There is a new mailing list for discussing security in DTNs.

As with dtn-interest, posting is restricted to members (to reduce
spam), but the archives will be open.

If you would like to subscribe the web site is here:
http://mailman.dtnrg.org/mailman/listinfo/dtn-security

Melissa

Date: Thu, 17 Mar 2005 17:00:00 -0600
From: Jeff Allen <[email-masked]>
Reply-To: [email-masked]
To: "Scott,Keith L." <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

> If we need to (though I don't think we will), we could use another bit
> to allow 64-bit lengths.

I'd be willing to take that bet up with you, Michael. Remeber, no one
should ever need more than 640k of RAM...

I currently know database guys who regularly issue cp commands on
files larger than 4 gigabytes without really thinking about it.
(Except to call the sysadmin and complain when they end up logged into
a system that´s not doing long files right.) It seems likely in 20
years some of these DBAs will be cp'ing files to an unmanned
experiment on the moon that's on a DTN.

On another issue:

> > Time To Live: Each bundle carries a time to live specified in seconds. There
> > is concern that in some environments, bundles may need to time out on
> > sub-second timescales. A proposed solution to this is that for these
> > environments, bundle routers implement some other extension header (a
> > 'quick-death' header) that carries the sub-second timeout value. The
> > alternative would be to change the units of the time to live field.

How about leaving it as an exercise to implementors to create an
experimental "TTL scaling" header? It would work like TCP window
scaling, if I recall how that works right.

But what happens if a bundle with a TTL scaling header that specifies
"divide the bundle TTL by 1024" gets loose inside a DTN that does not
understand it? Then you've got a bundle stuck in there with a TTL much
higher than the sender asked for.

Perhaps you could add a flag somewhere that says, "if you don't
understand ALL of the headers in this bundle, you MUST drop it" to
protect against that case. Then in the spec for new experimental
headers that are dangerous if ignored (like TTL scale) it would say,
"when using the TTL scale header you MUST set the
drop-bundles-with-unknown-headers flag."

  -jeff

From: Rajesh Krishnan <[email-masked]>
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
To: [email-masked] (Michael Demmer)
Date: Thu, 17 Mar 2005 17:44:37 -0500 (EST)
Cc: [email-masked] (Scott Keith L.), [email-masked]
Reply-to: [email-masked]
Sender: [email-masked]

I like the proposal to use a smaller default length.  I would submit 
we consider 64-bit lengths seriously.

>4G bundles are not that unrealistic for DTN applications.  Gb/s rate
space links (that may not always be available) exist.  DVD images are 
already larger than 4G (and DTN may have applications in distributed 
video databases and video file sharing).  The scientific computing 
community (using Abilene and other high speed networks) frequently 
move large data sets, often at specific times when experiments 
are scheduled.  For example, see the VLBI/eVLBI applications at 
MIT Haystack Observatory  (http://www.haystack.mit.edu/)

(PAWS-like solutions can mean having to deal with rounding errors on 
fragmentation.)

-Rajesh

> In terms of the questions regarding the header length field and header
> flags interpretation, my preference would be to do the following.
> Suggestions and criticisms are certainly welcomed.
> 
> As Keith describes, all headers except the primary bundle header are
> preceded by a common top part. In terms of the length field, I'd like
> to advocate using two bytes by default. We could then use one bit from
> the flags to denote an optional 'length extension' that immediately
> follows the top part.
> 
> Thus a header with length <= 16K would be:
> 
> +----------------+----------------+----------------+----------------+ 
> |  Header Type   | Flags (ext=0)  |            length               |
> +----------------+----------------+----------------+----------------+ 
> 
> and header with length <= 4GB would be:
> 
> +----------------+----------------+----------------+----------------+ 
> |  Header Type   | Flags (ext=1)  |            length               
> +----------------+----------------+----------------+----------------+ 
>              length               |
> +----------------+----------------+ 
> 
> This has a couple properties that I like: First of all, it obviates
> the need for any additional formatting for the PayloadHeader, since as
> Keith points out, we will get rid of the payload class field, and the
> payload length is expressable in the above format. It also means that
> the default header top part fits in one word, and so most of the other
> headers will also be word-aligned on the wire. This addresses Keith's
> point #4 as well, as he mentioned.
> 
> If we need to (though I don't think we will), we could use another bit
> to allow 64-bit lengths.
> 
> As to the question of what to do with the flags, I would prefer the
> more expressible alternative that Keith proposed -- that there are at
> least three flag options for:
> 
>   1) forward the unknown header unmodified
>   2) skip and remove the unknown header
>   3) delete the bundle
> 
> That's all for now.
> 
> -mike
> 
> 
> > The bundle protocol spec internet draft is nearly expired, which is an
> > excellent opportunity to make additions / clarifications. Here are a number
> > of changes I'd like to discuss.
> > 
> >  
> > 
> > 1. Remove the 'payload class' field in the payload header. The payload class
> > is a way to tell a bundle daemon that a particular bundle is a 'bundle
> > system' message such as a custody acknowledgement, end-to-end
> > acknowledgement, etc. The concept of a (set of) bundle-level 'administrative
> > endpoints' for bundle routers has been proposed, where a particular bundle
> > router would have a (set of) endpoints whose purpose is to handle these
> > system-level messages. This would obviate the need for the payload class
> > byte.
> > 
> > 2. Change the 'next header type' field in each of the bundle headers to be
> > 'current header type'. It would identify the type of the current header.
> > 
> > 3. Add a length field to all headers except the primary bundle header. These
> > length fields would immediately follow the header type fields and be XX
> > bytes in length. [QUESTION: 1 byte, 2 bytes, self-delimiting integer, ...]
> > Self-delimiting integers might be the way to go, but they themselves are
> > variable-length. The length field specifies the length of the ENTIRE header,
> > including the 'header type' byte. This will make it easier to parse past
> > headers that are either not needed for a particular operation or not
> > understood by the router.
> > 
> > 4. Make sure that the the dictionary header length field can hold several
> > full-size DTN tuple strings. The rationale for this is that each individual
> > string record can be up to 255 bytes in length; 1 byte here would never be
> > enough. [This will not be an issue if the answer to (3) is either
> > self-delimiting integer or 2 bytes; this is an issue if the answer to 3 is 1
> > byte length fields].
> > 
> > I submit that we should consider adding a NOTE saying that implementations
> > MAY pad the dictionary header by specifying a length value that is longer
> > than the sum of the string records.
> > 
> > 5. State explicitly that if an implementation receives a header with a type
> > that it does not understand, that it handles it as specified in the header's
> > flags field (described below). This requires that the 'top part of' headers
> > have a standard format [header type, length, flags], Header type is 1 byte
> > identifying the header. Length is as per (3), and flags is a set of flags
> > that says what should be done with the header. Possible values for the flags
> > could be: silently skip the header and leave it in place, silently skip the
> > header and remove it, drop the bundle (and issue an error message), ...
> > QUESTION: do we need the flags, or just say that implementaitons that don't
> > understand a particular option just silently skip over it?
> > 
> > 5a. The combination of (3,5) allows experimenters to define new header types
> > (with dtnrg as the interim numbering authority?) and experiment with them.
> > 
> > =====================================================
> > 
> > QUESTIONS (things that we may want but that I think are less well-developed
> > than the above). Discussion highly encouraged.
> > 
> > =====================================================
> > 
> > If we go to using a (current) header type, then we free up a byte in the
> > primary bundle header. Thoughts about what to do with that?
> > 
> > ---
> > 
> > Creation Timestamp: Recall that the combination of (source endpoint ID,
> > creation timestamp) is intended to uniquely identify a bundle. If an
> > implementation were to be able to generate bundles fast enough that the
> > source timestamp wouldn't tick between bundles, this would be a problem.
> > Possible solutions to this are:
> > 
> > 1. Say that the implementation is responsible for ensuring that the source
> > timestamp is monotonically increasing with each bundle sent out. It would be
> > understood that the source timestamp might then represent only 'approximate
> > time', since a (bundle agent/router) implementation might need to mess with
> > the low order bits. It would be important that implementations NOT corrupt
> > the sending timestamp so much as to affect the seconds, since this would
> > affect the bundle's lifespan.
> > 
> > 2. Change the definition of the creation timestamp in some way.
> > 
> > ---
> > 
> > Time To Live: Each bundle carries a time to live specified in seconds. There
> > is concern that in some environments, bundles may need to time out on
> > sub-second timescales. A proposed solution to this is that for these
> > environments, bundle routers implement some other extension header (a
> > 'quick-death' header) that carries the sub-second timeout value. The
> > alternative would be to change the units of the time to live field.
> > 
> > ---
> > 
> > Source Routing Header: There may be utility to be able to source-route
> > bundles. What if the header for source routing had the following format:
> > 
> > [Header Type (1B), Length (2B), # of entries (1B), current index (1B), list
> > of waypoints (DTN endpoint identifiers)]
> > 
> > The '# of entries' identifies the number of entries in the waypoints list
> > 
> > The 'current index' identifies the waypoint towards which the bundle is
> > currently being routed.
> > 
> > Format for each waypoint:
> > 
> > [length(1B), flags(1B), endpoint identifier]
> > 
> > Flags would contain at least 1 bit that identifies the waypoint as
> > (loose/strict). Endpoint identifiers might be the administratinve endpoints
> > of bundle routers, or somehow otherwise identified as not being applications
> > to demux to.
> > 
> >  
> > 
> > ==end==
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Thu, 17 Mar 2005 12:38:19 -0800
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

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

Scott,Keith L. wrote:
> The bundle protocol spec internet draft is nearly expired, which is an 
> excellent opportunity to make additions / clarifications. Here are a 
> number of changes I'd like to discuss.

I haven't yet had time to read these, but will do that as soon as I can; meanwhile I wanted to post the notes I took from our meetings last week plus a proposal for restructuring the bundle header to accommodate the flat endpoint ID namespace (no region/admin tuple scheme) that I think we tentatively agreed on.

Scott

--------------010706000406080405070409
Content-Type: application/pdf;
 name="bundle header.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="bundle header.pdf"

--------------010706000406080405070409
Content-Type: application/pdf;
 name="dtnrg notes.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="dtnrg notes.pdf"

--------------010706000406080405070409--

Date: Thu, 17 Mar 2005 11:58:11 -0800
From: Michael Demmer <[email-masked]>
To: "Scott,Keith L." <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Mail-Followup-To: "Scott,Keith L." <[email-masked]>, [email-masked]
Sender: [email-masked]

In terms of the questions regarding the header length field and header
flags interpretation, my preference would be to do the following.
Suggestions and criticisms are certainly welcomed.

As Keith describes, all headers except the primary bundle header are
preceded by a common top part. In terms of the length field, I'd like
to advocate using two bytes by default. We could then use one bit from
the flags to denote an optional 'length extension' that immediately
follows the top part.

Thus a header with length <= 16K would be:

+----------------+----------------+----------------+----------------+ 
|  Header Type   | Flags (ext=0)  |            length               |
+----------------+----------------+----------------+----------------+ 

and header with length <= 4GB would be:

+----------------+----------------+----------------+----------------+ 
|  Header Type   | Flags (ext=1)  |            length               
+----------------+----------------+----------------+----------------+ 
             length               |
+----------------+----------------+ 

This has a couple properties that I like: First of all, it obviates
the need for any additional formatting for the PayloadHeader, since as
Keith points out, we will get rid of the payload class field, and the
payload length is expressable in the above format. It also means that
the default header top part fits in one word, and so most of the other
headers will also be word-aligned on the wire. This addresses Keith's
point #4 as well, as he mentioned.

If we need to (though I don't think we will), we could use another bit
to allow 64-bit lengths.

As to the question of what to do with the flags, I would prefer the
more expressible alternative that Keith proposed -- that there are at
least three flag options for:

  1) forward the unknown header unmodified
  2) skip and remove the unknown header
  3) delete the bundle

That's all for now.

-mike

> The bundle protocol spec internet draft is nearly expired, which is an
> excellent opportunity to make additions / clarifications. Here are a number
> of changes I'd like to discuss.
> 
>  
> 
> 1. Remove the 'payload class' field in the payload header. The payload class
> is a way to tell a bundle daemon that a particular bundle is a 'bundle
> system' message such as a custody acknowledgement, end-to-end
> acknowledgement, etc. The concept of a (set of) bundle-level 'administrative
> endpoints' for bundle routers has been proposed, where a particular bundle
> router would have a (set of) endpoints whose purpose is to handle these
> system-level messages. This would obviate the need for the payload class
> byte.
> 
> 2. Change the 'next header type' field in each of the bundle headers to be
> 'current header type'. It would identify the type of the current header.
> 
> 3. Add a length field to all headers except the primary bundle header. These
> length fields would immediately follow the header type fields and be XX
> bytes in length. [QUESTION: 1 byte, 2 bytes, self-delimiting integer, ...]
> Self-delimiting integers might be the way to go, but they themselves are
> variable-length. The length field specifies the length of the ENTIRE header,
> including the 'header type' byte. This will make it easier to parse past
> headers that are either not needed for a particular operation or not
> understood by the router.
> 
> 4. Make sure that the the dictionary header length field can hold several
> full-size DTN tuple strings. The rationale for this is that each individual
> string record can be up to 255 bytes in length; 1 byte here would never be
> enough. [This will not be an issue if the answer to (3) is either
> self-delimiting integer or 2 bytes; this is an issue if the answer to 3 is 1
> byte length fields].
> 
> I submit that we should consider adding a NOTE saying that implementations
> MAY pad the dictionary header by specifying a length value that is longer
> than the sum of the string records.
> 
> 5. State explicitly that if an implementation receives a header with a type
> that it does not understand, that it handles it as specified in the header's
> flags field (described below). This requires that the 'top part of' headers
> have a standard format [header type, length, flags], Header type is 1 byte
> identifying the header. Length is as per (3), and flags is a set of flags
> that says what should be done with the header. Possible values for the flags
> could be: silently skip the header and leave it in place, silently skip the
> header and remove it, drop the bundle (and issue an error message), ...
> QUESTION: do we need the flags, or just say that implementaitons that don't
> understand a particular option just silently skip over it?
> 
> 5a. The combination of (3,5) allows experimenters to define new header types
> (with dtnrg as the interim numbering authority?) and experiment with them.
> 
> =====================================================
> 
> QUESTIONS (things that we may want but that I think are less well-developed
> than the above). Discussion highly encouraged.
> 
> =====================================================
> 
> If we go to using a (current) header type, then we free up a byte in the
> primary bundle header. Thoughts about what to do with that?
> 
> ---
> 
> Creation Timestamp: Recall that the combination of (source endpoint ID,
> creation timestamp) is intended to uniquely identify a bundle. If an
> implementation were to be able to generate bundles fast enough that the
> source timestamp wouldn't tick between bundles, this would be a problem.
> Possible solutions to this are:
> 
> 1. Say that the implementation is responsible for ensuring that the source
> timestamp is monotonically increasing with each bundle sent out. It would be
> understood that the source timestamp might then represent only 'approximate
> time', since a (bundle agent/router) implementation might need to mess with
> the low order bits. It would be important that implementations NOT corrupt
> the sending timestamp so much as to affect the seconds, since this would
> affect the bundle's lifespan.
> 
> 2. Change the definition of the creation timestamp in some way.
> 
> ---
> 
> Time To Live: Each bundle carries a time to live specified in seconds. There
> is concern that in some environments, bundles may need to time out on
> sub-second timescales. A proposed solution to this is that for these
> environments, bundle routers implement some other extension header (a
> 'quick-death' header) that carries the sub-second timeout value. The
> alternative would be to change the units of the time to live field.
> 
> ---
> 
> Source Routing Header: There may be utility to be able to source-route
> bundles. What if the header for source routing had the following format:
> 
> [Header Type (1B), Length (2B), # of entries (1B), current index (1B), list
> of waypoints (DTN endpoint identifiers)]
> 
> The '# of entries' identifies the number of entries in the waypoints list
> 
> The 'current index' identifies the waypoint towards which the bundle is
> currently being routed.
> 
> Format for each waypoint:
> 
> [length(1B), flags(1B), endpoint identifier]
> 
> Flags would contain at least 1 bit that identifies the waypoint as
> (loose/strict). Endpoint identifiers might be the administratinve endpoints
> of bundle routers, or somehow otherwise identified as not being applications
> to demux to.
> 
>  
> 
> ==end==
> 
>  
> 
>  
> 
>  
> 

From: "Scott,Keith L." <[email-masked]>
To: <[email-masked]>
Date: Thu, 17 Mar 2005 13:21:28 -0500
Subject: [dtn-interest] Changes we might want to make to the next version of the bundle specification.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C52AF4.3A077040
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The bundle protocol spec internet draft is nearly expired, which is an
excellent opportunity to make additions / clarifications. Here are a number
of changes I'd like to discuss.

1. Remove the 'payload class' field in the payload header. The payload class
is a way to tell a bundle daemon that a particular bundle is a 'bundle
system' message such as a custody acknowledgement, end-to-end
acknowledgement, etc. The concept of a (set of) bundle-level 'administrative
endpoints' for bundle routers has been proposed, where a particular bundle
router would have a (set of) endpoints whose purpose is to handle these
system-level messages. This would obviate the need for the payload class
byte.

2. Change the 'next header type' field in each of the bundle headers to be
'current header type'. It would identify the type of the current header.

3. Add a length field to all headers except the primary bundle header. These
length fields would immediately follow the header type fields and be XX
bytes in length. [QUESTION: 1 byte, 2 bytes, self-delimiting integer, ...]
Self-delimiting integers might be the way to go, but they themselves are
variable-length. The length field specifies the length of the ENTIRE header,
including the 'header type' byte. This will make it easier to parse past
headers that are either not needed for a particular operation or not
understood by the router.

4. Make sure that the the dictionary header length field can hold several
full-size DTN tuple strings. The rationale for this is that each individual
string record can be up to 255 bytes in length; 1 byte here would never be
enough. [This will not be an issue if the answer to (3) is either
self-delimiting integer or 2 bytes; this is an issue if the answer to 3 is 1
byte length fields].

I submit that we should consider adding a NOTE saying that implementations
MAY pad the dictionary header by specifying a length value that is longer
than the sum of the string records.

5. State explicitly that if an implementation receives a header with a type
that it does not understand, that it handles it as specified in the header's
flags field (described below). This requires that the 'top part of' headers
have a standard format [header type, length, flags], Header type is 1 byte
identifying the header. Length is as per (3), and flags is a set of flags
that says what should be done with the header. Possible values for the flags
could be: silently skip the header and leave it in place, silently skip the
header and remove it, drop the bundle (and issue an error message), ...
QUESTION: do we need the flags, or just say that implementaitons that don't
understand a particular option just silently skip over it?

5a. The combination of (3,5) allows experimenters to define new header types
(with dtnrg as the interim numbering authority?) and experiment with them.

=====================================================

QUESTIONS (things that we may want but that I think are less well-developed
than the above). Discussion highly encouraged.

=====================================================

If we go to using a (current) header type, then we free up a byte in the
primary bundle header. Thoughts about what to do with that?

---

Creation Timestamp: Recall that the combination of (source endpoint ID,
creation timestamp) is intended to uniquely identify a bundle. If an
implementation were to be able to generate bundles fast enough that the
source timestamp wouldn't tick between bundles, this would be a problem.
Possible solutions to this are:

1. Say that the implementation is responsible for ensuring that the source
timestamp is monotonically increasing with each bundle sent out. It would be
understood that the source timestamp might then represent only 'approximate
time', since a (bundle agent/router) implementation might need to mess with
the low order bits. It would be important that implementations NOT corrupt
the sending timestamp so much as to affect the seconds, since this would
affect the bundle's lifespan.

2. Change the definition of the creation timestamp in some way.

---

Time To Live: Each bundle carries a time to live specified in seconds. There
is concern that in some environments, bundles may need to time out on
sub-second timescales. A proposed solution to this is that for these
environments, bundle routers implement some other extension header (a
'quick-death' header) that carries the sub-second timeout value. The
alternative would be to change the units of the time to live field.

---

Source Routing Header: There may be utility to be able to source-route
bundles. What if the header for source routing had the following format:

[Header Type (1B), Length (2B), # of entries (1B), current index (1B), list
of waypoints (DTN endpoint identifiers)]

The '# of entries' identifies the number of entries in the waypoints list

The 'current index' identifies the waypoint towards which the bundle is
currently being routed.

Format for each waypoint:

[length(1B), flags(1B), endpoint identifier]

Flags would contain at least 1 bit that identifies the waypoint as
(loose/strict). Endpoint identifiers might be the administratinve endpoints
of bundle routers, or somehow otherwise identified as not being applications
to demux to.

==end==

 

------=_NextPart_000_002B_01C52AF4.3A077040
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>The bundle protocol spec internet draft is nearly expired, which is =
an=20
excellent opportunity to make additions / clarifications. Here are a =
number of=20
changes I'd like to discuss.</P>
<P>&nbsp;</P>
<P>1. Remove the 'payload class' field in the payload header. The =
payload class=20
is a way to tell a bundle daemon that a particular bundle is a 'bundle =
system'=20
message such as a custody acknowledgement, end-to-end acknowledgement, =
etc. The=20
concept of a (set of) bundle-level 'administrative endpoints' for bundle =
routers=20
has been proposed, where a particular bundle router would have a (set =
of)=20
endpoints whose purpose is to handle these system-level messages. This =
would=20
obviate the need for the payload class byte.</P>
<P></P>
<P>2. Change the 'next header type' field in each of the bundle headers =
to be=20
'current header type'. It would identify the type of the current =
header.</P>
<P>3. Add a length field to all headers except the primary bundle =
header. These=20
length fields would immediately follow the header type fields and be XX =
bytes in=20
length. [QUESTION: 1 byte, 2 bytes, self-delimiting integer, ...]=20
Self-delimiting integers might be the way to go, but they themselves are =

variable-length. The length field specifies the length of the ENTIRE =
header,=20
including the 'header type' byte. This will make it easier to parse past =
headers=20
that are either not needed for a particular operation or not understood =
by the=20
router.</P>
<P>4. Make sure that the the dictionary header length field can hold =
several=20
full-size DTN tuple strings. The rationale for this is that each =
individual=20
string record can be up to 255 bytes in length; 1 byte here would never =
be=20
enough. [This will not be an issue if the answer to (3) is either=20
self-delimiting integer or 2 bytes; this is an issue if the answer to 3 =
is 1=20
byte length fields].</P>
<P>I submit that we should consider adding a NOTE saying that =
implementations=20
MAY pad the dictionary header by specifying a length value that is =
longer than=20
the sum of the string records.</P>
<P>5. State explicitly that if an implementation receives a header with =
a type=20
that it does not understand, that it handles it as specified in the =
header's=20
flags field (described below). This requires that the 'top part of' =
headers have=20
a standard format [header type, length, flags], Header type is 1 byte=20
identifying the header. Length is as per (3), and flags is a set of =
flags that=20
says what should be done with the header. Possible values for the flags =
could=20
be: silently skip the header and leave it in place, silently skip the =
header and=20
remove it, drop the bundle (and issue an error message), ... QUESTION: =
do we=20
need the flags, or just say that implementaitons that don't understand a =

particular option just silently skip over it?</P>
<P>5a. The combination of (3,5) allows experimenters to define new =
header types=20
(with dtnrg as the interim numbering authority?) and experiment with =
them.</P>
<P>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</P>
<P>QUESTIONS (things that we may want but that I think are less =
well-developed=20
than the above). Discussion highly encouraged.</P>
<P>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</P>
<P>If we go to using a (current) header type, then we free up a byte in =
the=20
primary bundle header. Thoughts about what to do with that?</P>
<P>---</P>
<P>Creation Timestamp: Recall that the combination of (source endpoint =
ID,=20
creation timestamp) is intended to uniquely identify a bundle. If an=20
implementation were to be able to generate bundles fast enough that the =
source=20
timestamp wouldn't tick between bundles, this would be a problem. =
Possible=20
solutions to this are:</P>
<P>1. Say that the implementation is responsible for ensuring that the =
source=20
timestamp is monotonically increasing with each bundle sent out. It =
would be=20
understood that the source timestamp might then represent only =
'approximate=20
time', since a (bundle agent/router) implementation might need to mess =
with the=20
low order bits. It would be important that implementations NOT corrupt =
the=20
sending timestamp so much as to affect the seconds, since this would =
affect the=20
bundle's lifespan.</P>
<P>2. Change the definition of the creation timestamp in some way.</P>
<P>---</P>
<P>Time To Live: Each bundle carries a time to live specified in =
seconds. There=20
is concern that in some environments, bundles may need to time out on =
sub-second=20
timescales. A proposed solution to this is that for these environments, =
bundle=20
routers implement some other extension header (a 'quick-death' header) =
that=20
carries the sub-second timeout value. The alternative would be to change =
the=20
units of the time to live field.</P>
<P>---</P>
<P>Source Routing Header: There may be utility to be able to =
source-route=20
bundles. What if the header for source routing had the following =
format:</P>
<P>[Header Type (1B), Length (2B), # of entries (1B), current index =
(1B), list=20
of waypoints (DTN endpoint identifiers)]</P>
<P>The '# of entries' identifies the number of entries in the waypoints =
list</P>
<P>The 'current index' identifies the waypoint towards which the bundle =
is=20
currently being routed.</P>
<P>Format for each waypoint:</P>
<P>[length(1B), flags(1B), endpoint identifier]</P>
<P>Flags would contain at least 1 bit that identifies the waypoint as=20
(loose/strict). Endpoint identifiers might be the administratinve =
endpoints of=20
bundle routers, or somehow otherwise identified as not being =
applications to=20
demux to.</P>
<P>&nbsp;</P>
<P>=3D=3Dend=3D=3D</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P></FONT></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_002B_01C52AF4.3A077040--

From: Rajesh Krishnan <[email-masked]>
To: [email-masked]
Date: Wed, 16 Mar 2005 18:06:03 -0500 (EST)
Reply-to: [email-masked]
Subject: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project team
Sender: [email-masked]

All,

We thank the DTNRG members for hosting a meeting with us (BBN SPINDLE
project) at Minneapolis last week.  We had a delightful discussion.  
Included below are some comments (from me and my colleagues on the BBN 
SPINDLE project) on:

  1. the DTN Architecture (expired) 
  2. the Bundle Protocol Specification (soon to expire)
  3. preliminary thoughts on ways in which our work may feed into the DTNRG

We welcome comments on our comments.  

Best Regards,
Rajesh

...............................................................................
Comments on DTN Architecture 
============================

* Scope: The comments in this section refer specifically to the text 
  contained in draft-irtf-dtnrg-arch-02.txt

* Overall: The following aspects have not received adequate treatment
  in the architecture:

  - Mobility
    o especially, node mobility between regions and region mobility

  - Management
    o ownership and administrative boundaries for nodes and regions
    o instrumentation of DTN nodes for observing and controlling remote
      network state
    o error conditions at a node such as a persistent store failure
    o declarative (external) specification and enforcement of policies

  - Disruptions occurring at short timescales (the focus is on tolerance 
    to delays at large timescales)

* The abstract defines the delay tolerant network as an "overlay that 
  exists above the transport layer."  It appears that there is nothing
  in the architecture that fundamentally requires a DTN to be overlaid
  over the transport layer of the underlying network.  

  On the other hand, there appear to be some _implicit_ service requirements 
  assumed for the underlying network.  These requirements may be typically 
  satisfied by the transport layer  in an IP network, but it is not clear 
  the same holds for other networks.  These assumptions must be made explicit 
  irrespective of which layer of the underlying network DTN is overlaid upon.  

  Since DTN is an overlay, the underlying network appears to the DTN to be 
  a (more capable) link layer rather than a transport layer, and DTN needs 
  to implement functionality (e.g. routing) typically associated with the 
  network layer.

  We suggest generalizing this statement to "overlay that exists above any 
  layer of an underlying network that provides the <enumerated> capabilities 
  (possibly through a convergence sublayer)".  

* In Section 3.1 it is not clear whether aggregation of bundles is allowed.

* Section 3.2, assumptions 1-3. Assumptions (1) and (2) are not generally
  valid for tactical military networks -- a large application area seeking
  this technology. Storage is neither plentiful nor well-distributed. 
  However, it is not clear that the *architecture* per se *needs* 
  assumption 1.  Within this architecture, one could build routing 
  mechanisms that perform coordinated, distributed storage. 

* Sec 3.2. Bulk/Normal/Expedited classes. Is the treatment on a per-next-hop 
  basis? Can one give a Bulk bundle destined for the south pole to a contact 
  headed south while the queue contains an Expedited bundle destined for the 
  north pole? we guess the answer is yes, but it is not entirely clear from 
  the text.

* In Section 3.3 it is not clear whether the transferrer or transferee 
  generates the custody transfer indication. Also if these indications
  are all sent to the report-to node, then how many reports per bundle
  does it receive?  Will this scale?  Can reports be aggregated or
  piggybacked opportunistically or not?

* In Section 3.3, for the expiration time and the curent time of day, 
  what is the reference?  Will GMT / Earth time be used in the IPN?

* Sec 3.4/3.5. Does the notion of a region include hierarchical nesting in a
  topologically significant way? That is, can the "A" in (R,A) turn contain an 
  (R1,A1) and so on? 

* In Section 3.5, the requirement that "any node not in R1 must treat A 
  as "opaque" (i.e. it cannot interpret A)" seems needlessly restrictive.  
  It seems sufficient to require that A not be modified outside R1.  To 
  support mobility efficiently (and avoid needless telescoping of routes), 
  it may become necessary to interpret A (e.g. location hints) outside R1.

  Furthermore, it can be argued that the "name invariance family" in the
  Bundle Protocol Specification is indeed an interpretation of A outside 
  R1.

* In Section 3.5 "Every node in a region R1 shall have the ability to 
  eventually deliver messages to every other node in R1 ..." needs to
  be qualified with a "barring a permanent network partition or permananent 
  destruction of nodes, and provided the expiration time of the bundle 
  exceeds the time the network is partitioned, and there is sufficient
  storage in the network."

* Sec. 3.5, assumption 3 ("every node in a region should be able to eventually
  deliver to every other node"). Not clear whether this assumption requires 
  that the "eventual delivery" be made with or without the use of data 
  hauling nodes (DTN  routers). If we cannot use DTN routers within the 
  region, then this seriously limits the applicability of this
  architecture to the tactical military environment. For instance, the region
  could be a brigade with HMMMVs, soldiers, UAVs etc. A brigade could be
  partitioned with UAV or helicopters doing the data hauling. In such a case
  we need a few DTN routers within the region. On the other hand, if 
  DTN routers can be used to heal such partitions within a region, it is 
  not clear how the addressing scheme will work.

* In Section 3.8 "graph" is used to mean "multi-graph".

* Section 3.8.1. Types of contacts. How is contact volatility managed?
  When you lose contact, you are not sure whether it is "still out there" or
  "gone". In other words, do you envisage the use of a link up/down protocol
  like in OSPF or MANETs to "maintain" contacts.  Is this function at the 
  bundle layer or in the convergence layer?

* Sec. 3.9, Reactive fragmenting. This implicitly assumes that the sender and
  receiver can communicate throughout the message exchange. What if the 
  link/subnet-path breaks after receiving part of the message? In this case 
  the sender cannot learn that only a portion of the message was received. 
  Actually, this is the likely case -- if X receives only part of a message
  from Y, it is probably because there was some disruption in the communication
  -- and this same disruption will likely be a barrier for the sender to
  "learn" anything at all about the outcome of its transmission.

* Section 3.9 what does it mean for DTN nodes to "share an edge"

* Section 3.10, can ACKs be aggregated or piggybacked opportunistically?

* Section 3.11, seems the use of seconds for expiration presupposes the
  use of DTN in high delay environments, and precludes applications to 
  high-speed optical networks (or computer interconnects), and other
  distributed applications, where custody transfers and data expiration 
  may indeed happen at faster timescales.

  Why should not DTN scale _down_ in delays and disconnections the same
  way it scales up?

* Section 3.12. Congestion control. We are not sure if congestion control 
  should be considered within this architecture. Presumably, DTN is deployed 
  in a network where only a (small?) subset of the nodes are DTN capable (DTN
  routers/nodes). Thus there may be plenty of other traffic that DTN has no
  control over. Congestion is a network-layer/MAC layer phenomenon and best
  controlled there. No matter what we do at the DTN layer, it will be of no
  avail if other applications/protocols using the underlying network blast 
  away to glory.

* Section 3.12. Flow control for solving the congestion control. This only
  works even partially if the receiver capacity is lower or equal to the 
  capacity of the intermediate nodes -- may not be a realistic assumption, 
  especially in a tactial military environment where the bundle may have 
  to go over multiple wireless hops.

* Section 3.13, The security architecture (based on checking at edges) may 
  be challenged by mobility, especially of the edges. What if the edges of 
  the network are continuously redefined due to mobility?

* Section 4.3 makes a critical point regarding state versus protocol
  behavior and the possibility of state being shared across protocols.
  A corollary of this sattement is the need to identify information
  models for sharing (and storing) routing, forwarding, and name
  resolution state. 

* Section 5, For disruption tolerance, the application structuring issues 
  must include cases where the DTN node where the application is registered
  is mobile or is otherwise soon to be disconnected (and needs to transfer 
  custody of the registration).

* Section 5, application needs to be better defined -- are they strictly 
  point-to-point or can aplication endpoints reside in a distributed 
  manner (anycast or multicast basis) in the delay tolerant network

* Section 6 should list mandatory requirements for the convergence layers
  in terms of what services they must provide to the bundle layer.

* DTN has some goals similar to X.400; the X.400 delivery service classes 
  are worth evaluating in this context (a citation of X.400 is appropriate 
  as relevant prior work)

* Consider the terminology "hold-and-forward" to distinguish from the 
  usage elsewhere of "store-and-forward" to mean "queue-and-forward"

* Consider the terminology "data hauling" to the case where mobility
  is exploited for delivery e.g. data mules, message ferries, ...

Comments on the Bundle Protocol Specification 
=============================================

* Scope: The comments in this section refer specifically to the text
  contained in draft-irtf-dtnrg-bundle-spec-02.txt

* This document is well written.  In particular, the format used to 
  describe the primitives and their semantics aids the understanding
  of the document.

* The term interface is never defined rigorously and is used in multiple
  contexts such as a software/service interface or a network interface.
  This should be done in the introduction.

* The endpoint ID terminology differs from what is used in the architecture.
  For example, the architecture indicates that a node must have at least one 
  MEI, but allows multiple MEIs per node; we think the MEI maps to the Agent 
  administration endpoint ID in the bundle protocol specification, which
  seems to suggest that there is exactly one agent administration endpoint ID.

* Does the endpoint ID apply to the node or the interface?   Appears
  to be the former but worth clarifying.

* Name Mobility: Is the communications endpoint ID allowed to move from 
  node to node?  If so, what state related to the registration (e.g. 
  bundles waiting to be delivered, the "delivery failure" action) MUST/
  SHOULD/MAY be migrated? 

  In other words, can nodes transfer custody of a "registration"?  (As an 
  analogy consider arguments for and against TCP session migration.)

  Treating the registration as an "active mailbox" object may be a useful
  metaphor here.

  This may be a larger issue here related to the relinquishment of name
  bindings by individual nodes.

* Can the CancelBundle.request (sometimes aliased to Cancel.request) only
  apply if the bundle is locally stored?  For example, upon a cancel request
  can a node launch a "k-hop trace and delete" on a pattern of bundles that 
  were sent earlier?  This will be useful to purge bundles/replicas with 
  large expiration times (that have either been delivered or canceled)?

* The hash carried by bundles in the security header can have other uses.
  For example, this hash can be used to populate say a Bloom filter on en 
  route nodes for traceback.

* What happens to any bundles that arrive between registration and start 
  delivery?   Does the default delivery action go into effect automatically
  upon registration?

  It may be useful to point out that there is a distinct poll mode (active 
  reception?) when passive reception is first introduced.

* What happens to bundles that arrive after a deregister.request?  We assume
  they MUST be discarded.

* MUST the SENDERROR.INDICATION always include the application data unit?

* For the administrative part of the endpoint ID, some rationale is required 
  regarding why 8-bit, 16-bit, and URIs are supported in particular?  Why is
  URI not sufficient?  Why not 32-bit or 48-bit?

* A generic user-defined experimental header mechanism (syntax and semantics
  for nodes not implementing that header) is needed in order to enable 
  experimentation.

* A source routing header extension will be useful.  

* Since the dictionary header only allows 16 strings, and since there can
  be only one header of each type, it appears that extension headers will 
  need their own dictionaries.  For example, consider a 17-hop source route.

* It appears that generating a unique ID based purely on the creation
  timestamp and endpointID may cause problems.  A node with concurrent 
  embedded processors may be able to generate more than one bundle per 
  clock tick.  Therefore, an additional sequence counter may be needed.

* It is desirable to use the same style in Section 4 as in Section 2 
  (i.e. explicitly call out primitives and desribe their semantics).

* When a bundle is discarded (in Section 4.2) due to authentication 
  failure, can the report to the adminsitrative endpoint contain a
  copy of the inauthentic bundle or not?  Since the bundle is otherwise 
  discarded and not processed further, this copy is potentially useful 
  for instrumenting various security mechanisms.

* There is a potential for denial-of-service attacks that make use
  of the report-to field. This is a problem in a DTN since the sender 
  can legitimately be disconnected and vanish.  Has the report-to 
  third party have any say in the matter?  For example, does the
  bundle carry any credentials from the report-to?

* In the bundle fragmentation section, it is assumed that the sending
  agent "knows" when a transmission is terminated before the entire payload 
  has been transmitted.  Is this (signaling of partial transmission) an 
  explicit requirement for a DTN convergence layer?

* Currently, the fragmentation information carried in the headers do not 
  provide for redundant encodings of the fragments -- i.e. to indicate 
  how the bundle was fragmented and erasure-coded.  Yet one may wish to
  apply these codes precisely when there is fragmentation.

  In the current architecture, erasure or digital fountain type encoding 
  must occur either below the convergence layer (which means the protection
  cannot cross multiple networks), or end to end at the application which
  means the application cannot selectively erasure-code only when there
  is fragmentation.

* In Table 5 there is no way to indicate that a bundle was received
  in error, but was or was not reconstructable (using the erasure 
  coding). Such a feedback will aid in adjusting the strength of the
  code.

Anticipated Requirements / Areas for Possible Draft Proposals  
=============================================================

* Experimental headers: Our SPINDLE project will use the bundle as the 
  means of message encapsulation, however, we will require the ability 
  to add and experiment with additional headers.  We request that a user
  definable experimental header mechanism be added to the bundle
  protocol specification.  In particular, we anticipate the need for 
  extension headers to:

  - support braid-spray routing
  - carry name resolution hints  
  - carry resource accounting tokens 
  - support management tasks such as bundle traceback, proactive 
    distributed purge of canceled or delivered bundles (as opposed 
    to waiting in storage until bundle expiration).
  - possibly others

* Interpretation of names: We expect we will require a modest change to 
  the DTNRG architecture to allow any region to interpret (but not modify) 
  the "opaque" A part of the {R,A} tuple that constitutes a DTNRG name.  
  Related modifiable information (e.g. resolution hints) may be carried in 
  a late binding header that we may specify.  We anticipate that the unique 
  part of our supername will map to the DTNRG name syntax.

* Region interpretation: We anticipate that the routing and late binding
  frameworks developed within the DARPA DTN program to support tactical 
  mobility may each interpret and use regions differently (e.g. what is 
  a region, who owns/administers a region, mobility of nodes across 
  regions, mobility of regions themselves, and sub-region partitioning).

* We anticipate the DTN program will propose new frameworks for bundle 
  routing (family of routing protocols) and delayed resolution of names.
  We anticipate we will generate specifications of information models for 
  storing and sharing topology, adjacency, reachability, and name resolution 
  across nodes and across algorithms.  

* To facilitate regular DTN-DTNRG interaction, a monthly teleconference
  between the DTN and DTNRG to address DTN-specific issues will be 
  beneficial.

...............................................................................

From: Darren Long <[email-masked]>
Subject: Re: [dtn-interest] Compiling DTN2 for Mac OS X
Date: Tue, 15 Mar 2005 12:34:12 +0000
To: [email-masked]
Sender: [email-masked]

I've found that building the libtclreadline.dylib shared library is not 
going to be trivial on Mac OS X, apparently, due to issues with the 
linker and libtool.  I did a make uninstall for tclreadline, and 
rebuilt DTN2.  Success... dtnd runs nicely now on my iBook.

Thanks for your help.

Darren

On 14 Mar 2005, at 08:05, Darren Long wrote:

> Sorry, I should have shown the next line from the console.  dtnd is 
> exiting to the shell after reporting:
>
> dyld: dtnd can't open library: /usr/lib/libtclreadline.dylib  (No such 
> file or directory, errno = 2)
>
> Darren
>
> On 14 Mar 2005, at 01:50, Michael Demmer wrote:
>
>>
>>> Thanks for that.  I've built everything now, but have a run-time
>>> problem when running dtnd.  It appears as though the install of
>>> tclreadline wasn't configured to create a dylib on the Mac.  This
>>> wasn't a problem on FC3.  How did you find your way round this one?
>>
>> To tell you the truth -- I never tried. tclreadline isn't necessary
>> (it just makes the console work a little nicer)
>>
>> Is it failing to start in the current state or does it give you the
>> line "can't load tclreadline... falling back to simple command loop"
>>
>> -m
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
> In theory, theory and practice are the same.  In practice, they are 
> not.
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
In theory, theory and practice are the same.  In practice, they are not.

Cc: [email-masked]
From: Darren Long <[email-masked]>
Subject: Re: [dtn-interest] Compiling DTN2 for Mac OS X
Date: Mon, 14 Mar 2005 08:05:10 +0000
To: Michael Demmer <[email-masked]>
Sender: [email-masked]

Sorry, I should have shown the next line from the console.  dtnd is 
exiting to the shell after reporting:

dyld: dtnd can't open library: /usr/lib/libtclreadline.dylib  (No such 
file or directory, errno = 2)

Darren

On 14 Mar 2005, at 01:50, Michael Demmer wrote:

>
>> Thanks for that.  I've built everything now, but have a run-time
>> problem when running dtnd.  It appears as though the install of
>> tclreadline wasn't configured to create a dylib on the Mac.  This
>> wasn't a problem on FC3.  How did you find your way round this one?
>
> To tell you the truth -- I never tried. tclreadline isn't necessary
> (it just makes the console work a little nicer)
>
> Is it failing to start in the current state or does it give you the
> line "can't load tclreadline... falling back to simple command loop"
>
> -m
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
In theory, theory and practice are the same.  In practice, they are not.

Date: Sun, 13 Mar 2005 17:50:52 -0800
From: Michael Demmer <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Compiling DTN2 for Mac OS X
Mail-Followup-To: Darren Long <[email-masked]>, [email-masked]
Sender: [email-masked]

> Thanks for that.  I've built everything now, but have a run-time
> problem when running dtnd.  It appears as though the install of
> tclreadline wasn't configured to create a dylib on the Mac.  This
> wasn't a problem on FC3.  How did you find your way round this one?

To tell you the truth -- I never tried. tclreadline isn't necessary
(it just makes the console work a little nicer)

Is it failing to start in the current state or does it give you the
line "can't load tclreadline... falling back to simple command loop"

-m

Cc: [email-masked]
From: Darren Long <[email-masked]>
Subject: Re: [dtn-interest] Compiling DTN2 for Mac OS X
Date: Mon, 14 Mar 2005 00:38:51 +0000
To: Michael Demmer <[email-masked]>
Sender: [email-masked]

Thanks for that.  I've built everything now, but have a run-time 
problem when running dtnd.  It appears as though the install of 
tclreadline wasn't configured to create a dylib on the Mac.  This 
wasn't a problem on FC3.  How did you find your way round this one?

[1110759337.442583 /dtnd info] Bundle Daemon Initializing...
[1110759337.444346 /dtnd info] random seed is 444331
[1110759337.497038 /dtnd info] parsing configuration file 
/etc/dtn.conf...
[1110759337.501413 /dtnd info] dtnd parsing configuration...
[1110759337.507759 /interface info] adding interface tcp 
host://0.0.0.0:5000/
[1110759337.509917 /interface info] adding interface udp 
host://0.0.0.0:6000/
[1110759337.511505 /dtnd info] dtnd configuration parsing complete
[1110759337.512635 /dtnserver warning] tidy option removing directory 
'/bin/rm -rf /var/dtn/bundles'
[1110759337.532830 /dtnserver warning] tidy option removing directory 
'/bin/rm -rf /var/dtn/db'
[1110759337.613254 /storage/berkeleydb info] database file 
'/var/dtn/db/DTN.db' validated
[1110759337.615009 /storage/berkeleydb info] initializing globals 
database table...
[1110759337.619916 /storage/berkeleydb info] initializing bundles 
database table...
[1110759337.626716 /storage/berkeleydb info] initializing registration 
database table...
dyld: dtnd can't open library: /usr/lib/libtclreadline.dylib  (No such 
file or directory, errno = 2)

Cheers,

Darren

On 13 Mar 2005, at 20:54, Michael Demmer wrote:

>
> The problem is that Apple includes in their gcc distribution some
> debugging suppor for the standard c++ library, including a header file
> /usr/include/gcc/darwin/3.3/c++/debug/debug.h.
>
> Because the Mac OS filesystem is case-insensitive, lines of the form
> #include <debug/debug.h> from the C++ installation accidentally pick
> up the file oasys/debug/Debug.h from my code.
>
> To fix this, I've added a check to the configure script that looks for
> the above situation, and included a shell script called
> fix-apple-debug-header.sh that goes through the c++ include files and
> changes the file named debug.h to apple-debug.h, along with the
> handful of #include references to it. I've run this on my OS X
> computer at home (actually what I'm currently typing on) and it works
> fine.
>
> If you update to the current tip of the CVS tree and then re-run
> configure, it should prompt you and then run the above script which
> should fix the problem.
>
> Let me know if there are any issues.
>
> -mike

Date: Sun, 13 Mar 2005 12:54:36 -0800
From: Michael Demmer <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Compiling DTN2 for Mac OS X
Mail-Followup-To: Darren Long <[email-masked]>, [email-masked]
Sender: [email-masked]

The problem is that Apple includes in their gcc distribution some
debugging suppor for the standard c++ library, including a header file
/usr/include/gcc/darwin/3.3/c++/debug/debug.h.

Because the Mac OS filesystem is case-insensitive, lines of the form
#include <debug/debug.h> from the C++ installation accidentally pick
up the file oasys/debug/Debug.h from my code.

To fix this, I've added a check to the configure script that looks for
the above situation, and included a shell script called
fix-apple-debug-header.sh that goes through the c++ include files and
changes the file named debug.h to apple-debug.h, along with the
handful of #include references to it. I've run this on my OS X
computer at home (actually what I'm currently typing on) and it works
fine.

If you update to the current tip of the CVS tree and then re-run
configure, it should prompt you and then run the above script which
should fix the problem.

Let me know if there are any issues.

-mike

> Hi, 
> 
> Does anyone have any tips for building the latest DTN2 code on Mac OS 
> X.  I'm running 10.3.8 with xCode 1.5 installed. 
> 
> I'm getting compilation errors like: 
> 
> /usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h: In function 
> `char*  
>    std::uninitialized_copy(const char*, const char*, char*)': 
> /usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h:127: error: ` 
>    __glibcxx_requires_valid_range' undeclared (first use this function) 
> 
> 
> and more relating to basic_string.h 
> 
> I've got DTN2 running OK on my Fedora Core 3 box today, and would like 
> to get it going on my iBook. 
> 
> Darren 
> 
> In theory, theory and practice are the same.  In practice, they are 
> not.
> 

Date: Sun, 13 Mar 2005 12:53:11 -0600
From: Melissa Ho <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] Slides from IETF Meeting are available
Sender: [email-masked]

Hi!

I've added the slides from last week's meeting in Minneapolis to the web 
site.
http://www.dtnrg.org/wiki/IETF62

As an extra bonus, you'll be able to see the animations from Mike's 
presentations!

I've also added a link to Sushant's java DTN simulator on the Code page
http://www.dtnrg.org/wiki/Code

Enjoy!

Melissa

To: [email-masked]
From: Darren Long <[email-masked]>
Date: Sun, 13 Mar 2005 14:46:00 +0000
Subject: [dtn-interest] Compiling DTN2 for Mac OS X
Sender: [email-masked]

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

Hi,

Does anyone have any tips for building the latest DTN2 code on Mac OS 
X.  I'm running 10.3.8 with xCode 1.5 installed.

I'm getting compilation errors like:

/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h: In function 
`char*
    std::uninitialized_copy(const char*, const char*, char*)':
/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h:127: error: `
    __glibcxx_requires_valid_range' undeclared (first use this function)

and more relating to basic_string.h

I've got DTN2 running OK on my Fedora Core 3 box today, and would like 
to get it going on my iBook.

Darren

In theory, theory and practice are the same.  In practice, they are not.
--Apple-Mail-1--726026039
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

Hi,

Does anyone have any tips for building the latest DTN2 code on Mac OS
X.  I'm running 10.3.8 with xCode 1.5 installed.

I'm getting compilation errors like:

/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h: In function
`char* 

   std::uninitialized_copy(const char*, const char*, char*)':

/usr/include/gcc/darwin/3.3/c++/bits/stl_uninitialized.h:127: error: `

   __glibcxx_requires_valid_range' undeclared (first use this function)

and more relating to basic_string.h

I've got DTN2 running OK on my Fedora Core 3 box today, and would like
to get it going on my iBook.

Darren

<smaller>In theory, theory and practice are the same.  In practice,
they are not.</smaller>
--Apple-Mail-1--726026039--

Date: Wed, 09 Mar 2005 07:44:30 -0800
From: Melissa Ho <[email-masked]>
To: Piero Cornice <[email-masked]>
CC: [email-masked]
Subject: Re: [dtn-interest] code not found :(
Sender: [email-masked]

Thanks for pointing this out! The file was misnamed on the server.  It's 
fixed now!

Melissa

Piero Cornice wrote:

>Hi, i tried to download the code of latest DTN release, but i only obtain 404-error.
>Is the link correct?
>Thanks,
>   piero
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

Date: Wed,  9 Mar 2005 10:29:55 +0100
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] code not found :(
Sender: [email-masked]

Hi, i tried to download the code of latest DTN release, but i only obtain 404-error.
Is the link correct?
Thanks,
   piero

Date: Tue, 08 Mar 2005 21:47:22 -0800
From: Scott Burleigh <[email-masked]>
CC: Jeffrey Elkner <[email-masked]>, DTN <[email-masked]>, Anna Chan <[email-masked]>, Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Kevin Cole <[email-masked]>, Paul Flint <[email-masked]>
Subject: Re: [dtn-interest] Re: dtn science project - the next step.
Sender: [email-masked]

Michael Demmer wrote:
> As I think Scott mentioned previously, one set of useful experiments
> would involve multiple hosts with disrupted connectivity between each
> host. In other words, take hosts A, B, C, and D, and then experiment
> with sending traffic from A -> B -> C -> D where you variously
> interrupt or introduce loss on the links between pairs of hosts.
> 
> We ran some experiments like these on emulab, with results here:
> http://www.cs.berkeley.edu/~demmer/papers/dtn-irb-tr-04-020.pdf.  You
> could probably take that style of setup and play around with different
> things like message sizes and intervals.
> 
> In addition, those experiments were run on a slightly older version of
> the code, so it would be interesting to see how your results would
> compare on the latest version. If I remember correctly, you're using
> the DTN2 source code. I'm planning on issuing a new release shortly
> (possibly later today) and am interested to know how the new version
> behaves. Of course, if you have any problems getting it to work, let
> me know and I can help out.
> 
> Good luck!
> 
> -m
> 
> 
> 
>>Hi Scott,
>>
>>Thanks again for all you have done to help Anna, Daniel, and Colin!
>>
>>Now that they have won the top prize at the regional science fair, they
>>have a month to get ready for the Virginia State Fair. Do you have any
>>suggestions on what they can do next?
>>
>>They have the infrastructure in place to test the DTN software.  They
>>can control through software the interruption of an Ethernet signal.  
>>
>>Are there any particular models of signal disruption that they should be
>>testing?  Can they go about running tests on a range of connection
>>models in some systematic way?
>>
>>It would be especially great if they could perform experiments that
>>would be directly useful to the project.

Hi, Jeffrey.  I think Mike's ideas are an excellent way to extend this work.  If you're interested in making life even a little more difficult for yourselves, here are a couple more possiblities that you might want to contemplate at some point.

1.	So far, I think what you've been measuring has been throughput in one direction, end-to-end.  For some kinds of applications, a query-response communication pattern is always going to be required even in delay-afflicted networks; here again, the "postal" communication model is a guide to what's possible and necessary (think of Roman emperors trying to govern Egypt and Armenia effectively over a nine-week round-trip time by sea and road).  Some day it will be interesting to study round-trip latency in more or less the same way you guys have been studying throughput.  I haven't thought much about exactly how to structure the experiments: maybe comparison with TCP still makes sense, or maybe the cases to examine are different types of query-response-based applications that have different levels of delay tolerance.

2.	Related to the first topic: one DTN conceptual hurdle that people sometimes find difficult is how to make retransmission-based reliability work.  In particular, ARQ schemes often rely on timer expirations (which are really implicit negative ACKs) to trigger retransmission in the absence of explicit negative ACKs (which may be lost due to link error or outage).  But the computation of effective timeout intervals is difficult when round-trip times are highly variable.  We do a lot of thought experiments on this stuff, but some actual physical experimental results -- looking at the effects on throughput and latency in DTN custody transfer as timeout interval is varied in an environment of frequently lapsed connectivity (the lapses being either predictable or random; both cases are important) -- might help us clarify the issues.

And if other ideas leap to mind I'll gladly pass them on.

Scott

Date: Tue, 8 Mar 2005 19:19:47 -0800
From: Michael Demmer <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [dtn-interest] DTN2 version 2.1.0 released
Sender: [email-masked]

I am pleased to announce the release of version 2.1.0 of of the DTN2
reference implementation.

This version contains many feature improvements and bug fixes and
should be overall much more functional and stable than the previous
release. 

See http://www.dtnrg.org/wiki/Code for download instructions and links
to documentation.

-mike

---

Release Notes for version 2.1.0 (March 2005)
--------------------------------------------

- Major restructuring of the configuration and build process to use
  autoconf to generate configure specifications

- Additional ports to solaris, cygwin, MacOS X, and FreeBSD, as well
  as linux on ARM (sharp zaurus) both cross-compiled and native.

- Major change to the BundleRouter interface to remove the "delayed
  effect" problems of the action list interface. Now all operations
  are immediately enacted by a BundleActions class.

- Simplify the syntax for the link and interface commands to no longer
  require a full bundle tuple, but instead just the admin portion.
  This avoids the confusion in that the region portion was always
  ignored.

- Reorganization of the test directories in both oasys and DTN2,
  including the introduction of a unit testing framework in oasys and
  the conversion of some tests to the new framework.

- Added framework for link-specific option parsing for the convergence
  layers.

- New version of the TCP convergence layer protocol, to be formally
  specified further in an internet draft. Addition of an idle time
  negotiation to close idle connections. Initial work on a feature for
  receiver-initiated connection to be used to traverse NAT routers.

- New version of the UDP convergence layer protocol that tightens up
  the protocoll and makes more sense divergent from the tcp one.

- Change the bundling protocol implementation to use NTP timestamps as
  mandated by the bundling protocol internet draft.

- Initial work on integrating the dtnsim simulation environment with
  the core of the daemon.

- Many other miscellaneous small changes and bug fixes.

Date: Tue, 8 Mar 2005 10:06:47 -0800
From: Michael Demmer <[email-masked]>
To: Jeffrey Elkner <[email-masked]>
Cc: Scott Burleigh <[email-masked]>, DTN <[email-masked]>, Anna Chan <[email-masked]>, Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Kevin Cole <[email-masked]>, Paul Flint <[email-masked]>
Subject: Re: [dtn-interest] Re: dtn science project - the next step.
Mail-Followup-To: Jeffrey Elkner <[email-masked]>, Scott Burleigh <[email-masked]>, DTN <[email-masked]>, Anna Chan <[email-masked]>, Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Kevin Cole <[email-masked]>, Paul Flint <[email-masked]>
Sender: [email-masked]

As I think Scott mentioned previously, one set of useful experiments
would involve multiple hosts with disrupted connectivity between each
host. In other words, take hosts A, B, C, and D, and then experiment
with sending traffic from A -> B -> C -> D where you variously
interrupt or introduce loss on the links between pairs of hosts.

We ran some experiments like these on emulab, with results here:
http://www.cs.berkeley.edu/~demmer/papers/dtn-irb-tr-04-020.pdf.  You
could probably take that style of setup and play around with different
things like message sizes and intervals.

In addition, those experiments were run on a slightly older version of
the code, so it would be interesting to see how your results would
compare on the latest version. If I remember correctly, you're using
the DTN2 source code. I'm planning on issuing a new release shortly
(possibly later today) and am interested to know how the new version
behaves. Of course, if you have any problems getting it to work, let
me know and I can help out.

Good luck!

-m

> Hi Scott,
> 
> Thanks again for all you have done to help Anna, Daniel, and Colin!
> 
> Now that they have won the top prize at the regional science fair, they
> have a month to get ready for the Virginia State Fair. Do you have any
> suggestions on what they can do next?
> 
> They have the infrastructure in place to test the DTN software.  They
> can control through software the interruption of an Ethernet signal.  
> 
> Are there any particular models of signal disruption that they should be
> testing?  Can they go about running tests on a range of connection
> models in some systematic way?
> 
> It would be especially great if they could perform experiments that
> would be directly useful to the project.
> 
> On Mon, 2005-03-07 at 10:34 -0800, Scott Burleigh wrote:
> > Anna Chan wrote:
> > > Hi,
> > > 
> > > Just wanted to thank you again for all your help on our DTN science
> > > project.  We won best project at the Regional Science fair last
> > > Saturday, and will be advancing to both the State Fair in April and
> > > the International Fair in May, so we're all extremely excited!
> > 
> > That is great news, Anna -- congratulations!  I was wondering just
> > this morning how you guys were doing with your project, and I am
> > really delighted to hear that it's getting the recognition it
> > deserves.
> > 
> > Good luck in April!
> > 
> > Scott
> 
> -- 
> Jeffrey Elkner <[email-masked]>
> Open Book Project <http://ibiblio.org/obp>
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: Jeffrey Elkner <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: DTN <[email-masked]>, Anna Chan <[email-masked]>, Colin Applegate <[email-masked]>, Daniel Caughran <[email-masked]>, Kevin Cole <[email-masked]>, Paul Flint <[email-masked]>
Date: Tue, 08 Mar 2005 09:50:50 -0500
Subject: [dtn-interest] Re: dtn science project - the next step.
Sender: [email-masked]

Hi Scott,

Thanks again for all you have done to help Anna, Daniel, and Colin!

Now that they have won the top prize at the regional science fair, they
have a month to get ready for the Virginia State Fair. Do you have any
suggestions on what they can do next?

They have the infrastructure in place to test the DTN software.  They
can control through software the interruption of an Ethernet signal.  

Are there any particular models of signal disruption that they should be
testing?  Can they go about running tests on a range of connection
models in some systematic way?

It would be especially great if they could perform experiments that
would be directly useful to the project.

On Mon, 2005-03-07 at 10:34 -0800, Scott Burleigh wrote:
> Anna Chan wrote:
> > Hi,
> > 
> > Just wanted to thank you again for all your help on our DTN science
> > project.  We won best project at the Regional Science fair last
> > Saturday, and will be advancing to both the State Fair in April and
> > the International Fair in May, so we're all extremely excited!
> 
> That is great news, Anna -- congratulations!  I was wondering just
> this morning how you guys were doing with your project, and I am
> really delighted to hear that it's getting the recognition it
> deserves.
> 
> Good luck in April!
> 
> Scott

-- 
Jeffrey Elkner <[email-masked]>
Open Book Project <http://ibiblio.org/obp>

Date: Mon, 7 Mar 2005 17:54:39 -0500 (EST)
From: <[email-masked]>
To: Anna Chan <[email-masked]>
Cc: Daniel Caughran <[email-masked]>, Daniel Caughran <[email-masked]>, [email-masked], [email-masked], Scott Burleigh <[email-masked]>, Jeffrey Elkner <[email-masked]>, [email-masked]
Subject: [dtn-interest] Re: dtn science project
Sender: [email-masked]

Dear Anna,

As everyone knows, success has many fathers while failure is an orphan.

Anna, Colin, and Dan are a success and have brought great honor to
Arlington County, Yorktown High School, Business Education and the
assorted computer weenies whose giant shoulders (and fairly large
stomachs) were gladly deployed for you all to stand upon.

The lesson to learn here is to take advantage of these shoulders as you
move on to greater success.  Being the soul-less marketing weasel that you
all know me to be.  I believe that it is time to start finding
sponsorship.  I would suggest that NASA or some of their contractors
might have real interest in this project due to the practical
application it might have in space exploration. 

Further, I feel that we should include in our thanks Mr. Vincent
Cerf, whose presentation at the school had a lot to do with this
projects gestation.

Anyway, thats what I think.  The point here is Congratulations kiddos, I
knew you could do it, even if Colin and Dan look silly wearing ties, you
all did very good.

Kindest Regards,

Paul Flint

/***************************************************************
* To contact me try:                                           *
*       Paul Flint                        VOX  202 537 0480    *
*       EMAIL [email-masked]             HOME 703 524 1657    *
*                    WEB http://www.flint.com                  *
***************************************************************/
    To speed delivery please send plain text not HTML mail. 

On Mon, 7 Mar 2005, Anna Chan wrote:

> Hi,
> 
> Just wanted to thank you again for all your help on our DTN science
> project.  We won best project at the Regional Science fair last
> Saturday, and will be advancing to both the State Fair in April and
> the International Fair in May, so we're all extremely excited!
> 
> To expand upon or existing project, we plan on modeling different
> situations with the framework that we currently have - possibly
> simulate how DTN would respond to a mathematical model of weather
> conditions, or satellite communication to collect more practical data.
>  We could also add more computers to the network (as Scott suggested).
>  If anyone has any feedback or suggestions, please let us know! 
> Thanks!
> 
> Sincerely,
> 
> Anna
> 

Date: Mon, 7 Mar 2005 11:34:27 -0500
From: Anna Chan <[email-masked]>
Reply-To: Anna Chan <[email-masked]>
To: [email-masked], Scott Burleigh <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] dtn science project
Sender: [email-masked]

Hi,

Just wanted to thank you again for all your help on our DTN science
project.  We won best project at the Regional Science fair last
Saturday, and will be advancing to both the State Fair in April and
the International Fair in May, so we're all extremely excited!

To expand upon or existing project, we plan on modeling different
situations with the framework that we currently have - possibly
simulate how DTN would respond to a mathematical model of weather
conditions, or satellite communication to collect more practical data.
 We could also add more computers to the network (as Scott suggested).
 If anyone has any feedback or suggestions, please let us know! 
Thanks!

Sincerely,

Anna

Date: Mon, 07 Mar 2005 11:04:24 -0500
From: Howard Weiss <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [Fwd: New ground transportation option in Minneapolis]
Sender: [email-masked]

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

For anyone attending the DTNRG meeting, the light rail service from the 
Airport drops you off 3 blocks from the Residence Inn (Nicollet Mall 
stop).  The station and the hotel are also connected via the skyway so 
you don't even need to go outdoors.

Howie Weiss

-------- Original Message --------
Subject: 	New ground transportation option in Minneapolis
Date: 	Wed, 02 Mar 2005 11:26:33 -0500
From: 	Ólafur Guðmundsson <[email-masked]>
To: 	[email-masked]

The good news:
Last December Minneapolis started a Light Rail Service between
downtown and Mall of America with a stop at the airport.
The ride costs $1.25 each way and the trains seem to be running
every 10 minutes during the weekend and more frequently during the week.

The bad news:
The closest stop (at 5'th St. and Nicollet Mall) is about 5 blocks
from the Hilton Towers hotel.

See their web site at: http://www.metrocouncil.org/transportation/lrt/lrt.htm
For reference here is a map of the area with hotels displayed:
http://maps.yahoo.com/maps_result?csz=Minneapolis%2C+MN+55401&state=MN&uzip=55401&ds=n&name=&desc=&ed=eDu5QOp_0TqPE5XyOwuXhj7v0u6_hAG_dCpBTLWcizNbVmNzOivh_UwnQdbqL.Dju4BOoCEMHXSq_vhMhlplUHCg98GvDdA8CmaAn.uEQH2dav1oFo7QOjhrEdQ-&zoomin=yes&BFKey=ho&resize=s&trf=0&mag=2

It is possible to use the skyway from this station to the hotel,
but you may want a map of the skyway system:
http://www.minneapolis.org/gettingaround/content/pdf/Skyway.pdf

	Olafur

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

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

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Helvetica, Arial, sans-serif">For anyone
attending the DTNRG meeting, the light rail service from the Airport
drops you off 3 blocks from the Residence Inn (Nicollet Mall stop).&nbsp;
The station and the hotel are also connected via the skyway so you
don't even need to go outdoors.<br>
<br>
Howie Weiss<br>
</font></font><br>
-------- Original Message --------
<table border="0" cellpadding="0" cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>New ground transportation option in Minneapolis</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Wed, 02 Mar 2005 11:26:33 -0500</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>&Oacute;lafur Gu&eth;mundsson <a class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>The good news:
Last December Minneapolis started a Light Rail Service between
downtown and Mall of America with a stop at the airport.
The ride costs $1.25 each way and the trains seem to be running
every 10 minutes during the weekend and more frequently during the week.

The bad news:
The closest stop (at 5'th St. and Nicollet Mall) is about 5 blocks
from the Hilton Towers hotel.

See their web site at: <a class="moz-txt-link-freetext" href="http://www.metrocouncil.org/transportation/lrt/lrt.htm">http://www.metrocouncil.org/transportation/lrt/lrt.htm</a>
For reference here is a map of the area with hotels displayed:
<a class="moz-txt-link-freetext" href="http://maps.yahoo.com/maps_result?csz=Minneapolis%2C+MN+55401&state=MN&uzip=55401&ds=n&name=&desc=&ed=eDu5QOp_0TqPE5XyOwuXhj7v0u6_hAG_dCpBTLWcizNbVmNzOivh_UwnQdbqL.Dju4BOoCEMHXSq_vhMhlplUHCg98GvDdA8CmaAn.uEQH2dav1oFo7QOjhrEdQ-&zoomin=yes&BFKey=ho&resize=s&trf=0&mag=2">http://maps.yahoo.com/maps_result?csz=Minneapolis%2C+MN+55401&amp;state=MN&amp;uzip=55401&amp;ds=n&amp;name=&amp;desc=&amp;ed=eDu5QOp_0TqPE5XyOwuXhj7v0u6_hAG_dCpBTLWcizNbVmNzOivh_UwnQdbqL.Dju4BOoCEMHXSq_vhMhlplUHCg98GvDdA8CmaAn.uEQH2dav1oFo7QOjhrEdQ-&amp;zoomin=yes&amp;BFKey=ho&amp;resize=s&amp;trf=0&amp;mag=2</a>

It is possible to use the skyway from this station to the hotel,
but you may want a map of the skyway system:
<a class="moz-txt-link-freetext" href="http://www.minneapolis.org/gettingaround/content/pdf/Skyway.pdf">http://www.minneapolis.org/gettingaround/content/pdf/Skyway.pdf</a>

	Olafur

_______________________________________________
Ietf mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/ietf">https://www1.ietf.org/mailman/listinfo/ietf</a>
</pre>
<br>
<pre class="moz-signature" cols="72">-- 
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
410.872.1515 x201
410.872.8079 (fax)

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

--------------030200020700090100060709--

Date: Mon, 7 Mar 2005 04:43:07 -0800
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] Fwd: DTN2 Cross-Compilation Documentation
Sender: [email-masked]

Link to ongoing documentation of cross-compiling DTN2 for the zaurus
from Mike Liang (U Waterloo) below.

Melissa

---------- Forwarded message ----------
From: Mike Liang <[email-masked]>
Date: Fri, 4 Mar 2005 00:07:53 -0500
Subject: DTN2 Cross-Compilation Documentation
To: Melissa Ho <[email-masked]>
Cc: Srinivasan Keshav <[email-masked]>

Hi Melissa,

I just posted my DTN2 Cross-Compilation journal on Mindstream document
Wiki. You can find
it here (http://www.mindstream.watsmore.net/wiki/index.php?title=Mindstream_on_a_PDA).
If
there is any problem with the document, please don't hesitate to let me know.

Thank you

Mike