Subject: [dtn-interest] Eric Wolf
From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>
Date: Thu, 26 Apr 2007 15:46:25 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

I see that Eric Wolf died recently. From the description in his obituary
I'm sure that some on this list must have known him at DARPA, BBN or
Mitre so I've included a link.

Regards.....Peter

<http://www.washingtonpost.com/wp-dyn/content/article/2007/04/19/
AR2007041902656.html>

Eric Wolf, 85, an electrical engineer whose pioneering work with
computers helped usher in the Internet, died April 18 in Rockville. The
longtime Falls Church resident was also a widely recognized authority on
the history of cartography.

Mr. Wolf's initial work with computers, beginning in the early 1950s,
involved tracking military airplanes; his technical challenge was to
develop the coordinate system used to locate their position. The program
he helped design, called Semi-Automatic Ground Environment, was meant to
defend against attacks by manned bombers from the Soviet Union.

He was manager of Washington operations for the computer engineering
firm Bolt Beranek and Newman Inc. when he helped develop the predecessor
to the Internet. Known as the Advanced Research Projects Agency Network,
or ARPANET, its initial purpose was to allow defense researchers at four
academic institutions across the country to communicate with each other
quickly at a time when computers weren't linked up.

<... continues>

Content-class: urn:content-classes:message
Date: Fri, 20 Apr 2007 16:16:37 -0400
From: "Symington, Susan F." <[email-masked]>
To: "dtn interest" <[email-masked]>
Subject: [dtn-interest] Custodial multicast draft
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C78388.CD3F5EFE
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C78388.CD3F5EFE"

------_=_NextPart_002_01C78388.CD3F5EFE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is an updated version of the DTN Custodial Multicast
Extensions.
The draft-symington-dtnrg-bundle-multicast-custodial-01 version of this
draft expired yesterday.
=20
I would like to submit the attached draft as a version 00 dtnrg
submission if possible, instead of as version 02 of a 'symington'
submission.
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_002_01C78388.CD3F5EFE
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.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D830211320-20042007>Attached is an=20
updated version of the DTN Custodial Multicast =
Extensions.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D830211320-20042007>The=20
draft-symington-dtnrg-bundle-multicast-custodial-01 version of this =
draft=20
expired yesterday.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D830211320-20042007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D830211320-20042007>I =
would like to=20
submit the attached draft as a version 00 dtnrg submission if possible, =
instead=20
of as version 02 of a 'symington' submission.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D830211320-20042007></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D830211320-20042007>-susan</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C78388.CD3F5EFE--

------_=_NextPart_001_01C78388.CD3F5EFE
Content-Type: text/plain;
	name="draft-symington-dtnrg-bundle-multicast-custodial-02.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-symington-dtnrg-bundle-multicast-custodial-02.txt
Content-Disposition: attachment;
	filename="draft-symington-dtnrg-bundle-multicast-custodial-02.txt"

------_=_NextPart_001_01C78388.CD3F5EFE--

From: "Peter Lovell" <[email-masked]>
To: "dtn interest" <[email-masked]>
Date: Fri, 20 Apr 2007 12:27:22 -0400
Subject: [dtn-interest] bundle security protocol draft -03
Sender: [email-masked]

--==_20070420162722.880734176-1_==
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Here's an updated draft for Bundle Security Protocol, with very minor
text amendments since the one a few days ago (minor corrections from
Susan and Keith).

Those of you who also subscribe to dtn-dev have seen extensive
discussion over the last couple of days regarding combinations of
fragmentation and confidentiality ciphersuites. Those discussions are
ongoing however we need this draft so I'm sending it in its current
state, without any amendments to address the current issues.

It's clear that changes will be needed so I'll probably make another
update on a short cycle.

In order to make things work in the near term, I will be suggesting the
following changes:-

1. confidentiality ciphersuites will work on complete bundles and will
not attempt to apply themselves directly to a fragment-bundle

2. if confidentiality is requested on a fragment-bundle, that will first
be encapsulated bundle-in-bundle and confidentiality applied to the
resulting new bundle

3. the first CB (the one which contains the parameters etc for the
payload) will have the "must replicate in every fragment" bit set to 1.
This is presently disallowed by this BSP spec, and we'll have to change
that. The reason is that the presence of this block must serve as an
indicator that the payload is ciphertext and not plaintext, even if the
bundle is fragmented after encryption.

For your convenience, I've attached rfcdiff of this version against
version -02 (modified to ignore the "header" vs "block" change of wording).

Regards.....Peter
--==_20070420162722.880734176-1_==
Content-Type: multipart/mixed; boundary="==_20070420162722.880734176-2_=="

--==_20070420162722.880734176-2_==
Content-Type: text/plain; name="draft-irtf-dtnrg-bundle-security-03.txt";
 x-mac-type="00000000"; x-mac-creator="00000000"
Content-Disposition: attachment
Content-Transfer-Encoding: base64

--==_20070420162722.880734176-2_==
Content-Type: text/html;
 name="draft-irtf-dtnrg-bundle-security-03-from-2x.diff.html";
 x-mac-type="00000000"; x-mac-creator="00000000"
Content-Disposition: attachment
Content-Transfer-Encoding: base64

--==_20070420162722.880734176-2_==--
--==_20070420162722.880734176-1_==--

Date: Thu, 19 Apr 2007 21:42:18 +0200
From: Dirk Kutscher <[email-masked]>
Organization: TZI, =?ISO-8859-1?Q?Universit=E4t_Bremen?=
To: [email-masked]
Subject: [dtn-interest] DTN convergence layer for uni-directional transport
Sender: [email-masked]

Hi,

we have written up a specification of a convergence layer for 
uni-directional transport (Uni-DTN), based on FLUTE (RFC 3926).

Intended applications areas are challenged links without feedback 
channel, multicast/broadcast distribution etc. Broadcast distribution is 
actually a good fit to DTN concepts -- as distribution schemes such as 
carousel-distribution requires some form of delay-tolerance anyway.

Also, the Mbone is apparently an interesting challenged network to which 
we would like to apply Uni-DTN.

We would be interested to receive comments and suggestions!

The draft:
http://www.ietf.org/internet-drafts/draft-kutscher-dtnrg-uni-clayer-00.txt

The Uni-DTN web page:
https://prj.tzi.org/cgi-bin/trac.cgi/wiki/Uni-DTN

More information (on implemenations, application scenarios) will be 
published there soon.

Cheers,

Dirk

Date: Wed, 18 Apr 2007 19:03:16 -0300
To: [email-masked]
From: Mauromargalho <[email-masked]>
Reply-To: Mauromargalho <[email-masked]>
Subject: [dtn-interest] Patch DTN NS-2
Sender: [email-masked]

Hi, 

Someone know where can I obtain the DTN patch to Network Simulator 2?

Thanks,

Mauro.

________________________________________________
Message sent using Webmail ALEPA 1.2.0

Content-class: urn:content-classes:message
Date: Wed, 18 Apr 2007 14:58:06 -0400
From: "Symington, Susan F." <[email-masked]>
To: "dtn interest" <[email-masked]>
Subject: [dtn-interest] Retransmission Block ID update
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C781EB.7F946C0A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C781EB.7F946C0A"

------_=_NextPart_002_01C781EB.7F946C0A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is a revision of the DTN Retransmission Block ID that I would
like to submit. I incorporated revisions that Kevin Fall, Peter Lovell,
and others had suggested to the now-expired Retransmission Block draft
known as draft-symington-dtnrg-bundle-retrans-block-00.
=20
I would like to send in the attached draft as a dtnrg submission:
draft-irtf-dtnrg-bundle-retrans-block-00.
=20
This draft also incorporates the recent modifications that were made to
the canonical bundle block format, thanks to Peter Lovell.
=20
-susan
=20
=20
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

------_=_NextPart_002_01C781EB.7F946C0A
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.3059" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D023294718-18042007><FONT face=3DCourier>Attached is a =
revision of=20
the DTN Retransmission Block ID that I would like to submit. I =
incorporated=20
revisions that Kevin Fall, Peter Lovell, and others had suggested to the =

now-expired Retransmission Block draft known as=20
draft-symington-dtnrg-bundle-retrans-block-00.</FONT></SPAN></DIV>
<DIV><SPAN class=3D023294718-18042007><FONT=20
face=3DCourier></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D023294718-18042007><FONT face=3DCourier>I would like =
to send in=20
the attached draft as a dtnrg submission:=20
draft-irtf-dtnrg-bundle-retrans-block-00.</FONT></SPAN></DIV>
<DIV><SPAN class=3D023294718-18042007><FONT=20
face=3DCourier></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D023294718-18042007><FONT face=3DCourier>This draft =
also=20
incorporates the recent modifications that were made to the canonical =
bundle=20
block format, thanks to Peter Lovell.</FONT></SPAN></DIV>
<DIV><SPAN class=3D023294718-18042007><FONT=20
face=3DCourier></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D023294718-18042007><FONT=20
face=3DCourier>-susan</FONT></SPAN></DIV>
<DIV><SPAN class=3D023294718-18042007><FONT=20
face=3DCourier></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D023294718-18042007><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_002_01C781EB.7F946C0A--

------_=_NextPart_001_01C781EB.7F946C0A
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-retrans-block-00-final.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-retrans-block-00-final.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-retrans-block-00-final.txt"

------_=_NextPart_001_01C781EB.7F946C0A--

Date: Mon, 16 Apr 2007 10:18:03 -0700
From: "Steve King" <[email-masked]>
To: "dtn interest" <[email-masked]>
Subject: [dtn-interest] a question about DTN routing
Sender: [email-masked]

Hello,

I have one question:   Assume the following:  the network is
connected, for example, 95% of time.   about 5% of the time the
network may be disconnected.    in this case,  when the time is
connected, I could use one of the MANET routing protocols,  while when
the network is disconnected, I have to use BP (for example) to forward
bundles.     it this a viable approach?
or what is an overall,  reasonable routing protocol in this case?
will it be scalable?   any pointers?

thanks

-S

Date: Fri, 13 Apr 2007 15:22:42 -0400
From: Richard Hansen <[email-masked]>
To: Jeff Wilson <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Running PRoPHET on a simple network
Sender: [email-masked]

Jeff Wilson wrote:
> To change the Prophet defaults, use the "prophet" configuration 
> command.  For example, I tune the hello_interval down from its default 
> of 25.5s to 2s:
> 
> "prophet hello_interval=20"

Ah, thanks for that pointer.  I wasn't aware of the "hello_interval" 
setting.  I should have looked in servlib/cmd/ProphetCommand.cc (the 
"help prophet" command doesn't mention that particular setting).

> 
> Most of the other prophet commands are this style:
> 
> "prophet set max_forward 9"
> 
> Yep, you got it; your calculations are straight out of the March 2006 
> PRoPHET I-D.  Epsilon is the minimum predictability before dropping a 
> route, so we agree on that one too.  You have an error in one 
> assumption, though, and that is that there is a distinct 
> hello_interval parameter, separate from the age_period parameter.
> 
> In this particular implementation, as soon as two nodes configure 
> their link to one another, DTN generates a ContactUpEvent and Prophet 
> gets started on the peering session.  As soon as the peering session 
> completes its first round, the predictability (using defaults) 
> initializes to 0.75.  The peering session will exchange protocol 
> messages no faster than two per hello_interval.

I'm sorry, I still don't understanding PRoPHET very well -- how is 
"hello_interval" related to "age_period"?  At what point does a node 
update its delivery predictabilities?

> 
> If you don't change the default value, hello_interval is 25.5 seconds.  
> (To see all the defaults, look in servlib/routing/Prophet.h and 
> servlib/routing/ProphetLists.h)  Between protocol exchanges, the 
> peering session idles for (hello_dead * hello_interval / 2) before 
> starting up again.
> 
> Have you had a chance to review these wiki articles about using 
> DTN/Prophet?
> 
> http://www.dtnrg.org/wiki/ProphetRouter
> http://www.dtnrg.org/wiki/NeighborDiscovery
> 
> Please let me know whether changing hello_interval makes a difference.

Thank you very much for the pointers and the help.  I've been playing 
around with values, but haven't gone very far because I'm getting some 
segfaults, assertion failures, and spinlock warnings, usually before I 
have the opportunity to send a bundle.  Is it possible that some of 
these will be fixed in the wave of patches you mentioned earlier?  If 
so, would it be best to wait before playing with PRoPHET some more?

Thank you!

-Richard

> 
>    Regards,
>    Jeff
> 
> 
> On 4/12/07, Richard Hansen <[email-masked]> wrote:
>> Thank you for your reply.
>>
>> Jeff Wilson wrote:
>>> Hi Richard,
>>>
>>> What version of DTN are you using?  CVS, or some numbered release?
>>
>> I apologize for not providing enough information.  I'm using DTN (and 
>> PRoPHET) from CVS.  The dtn.confs for the three nodes are attached.  I'm 
>> using the default values for all of PRoPHET's settings:
>>
>> encounter = 0.75
>> beta = 0.25
>> gamma = 0.99
>> kappa = 100
>> hello_dead = 20
>> max_forward = 5
>> min_forward = 3
>> age_period = 1800
>> relay_node = true
>> internet_gateway = false
>> epsilon = 0.0039
>> queue_policy = (got a "binding does not exist" message when checking)
>> fwd_strategy = (got a "binding does not exist" message when checking)
>> max_usage = (got a "binding does not exist" message when checking)
>>
>> So if I understand PRoPHET correctly, the initial predictabilities for 
>> the direct links are:
>>
>>    P(a,b) = P(a,b)_old + (1 - P(a,b)_old) * encounter
>>    P(a,b) = 0          + (1 - 0         ) * 0.75
>>    P(a,b) = 0.75
>>
>> and for the indirect links:
>>
>>    P(a,c) = P(a,c)_old + (1 - P(a,c)_old) * P(a,b) * P(b,c) * beta
>>    P(a,c) = 0          + (1 - 0         ) * 0.75   * 0.75   * 0.25
>>    P(a,c) = 0.1406
>>
>> Over time, the predictabilities are calculated as follows (assuming the 
>> links stay up):
>>
>>    Time      Predictabilities
>> ====================================================================
>>     0-1800   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.7500, P(a,c)=P(c,a)=0.1406
>> 1800-3600   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9375, P(a,c)=P(c,a)=0.3295
>> 3600-5400   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9844, P(a,c)=P(c,a)=0.4919
>> 5400-7200   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9961, P(a,c)=P(c,a)=0.6179
>> 7200-9000   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9990, P(a,c)=P(c,a)=0.7133
>>     and so on...
>>
>> I'm wondering if my assumptions leading to the above calculations are 
>> correct...  Could the transitive predictabilities be shifted down one 
>> time slot (and be equal to 0 during the first time slot)?  If so, that 
>> would account for the behavior I'm seeing, and I would have to wait for 
>> 1800 seconds until the bundles are forwarded.  If my above calculations 
>> are correct, all of the predictabilities are greater than epsilon, so I 
>> would expect it to forward.  Or is this not what epsilon means?
>>
>> I will try increasing beta and encounter and reducing age_period to see 
>> if I can get it to work.
>>
>> Thanks,
>> Richard
>>
>>>
>>> The bug you are describing sounds like a bug with the earlier 
>>> DTN/Prophet releases... the Prophet I-D allows for an exception to the 
>>> peering protocol so that directly connected nodes can deliver bundles 
>>> destined to one another, apart from the results of the Prophet 
>>> protocol.  It sounds like the direct-connect exception is working.  
>>> For some reason, the full peering isn't working.
>>>
>>> The Prophet router in the current CVS has quite a few bug fixes since 
>>> the last DTN release.  Another wave of patches is coming out soon.
>>>
>>> Hope that helps ...
>>>
>>>        Regards,
>>>        Jeff
>>>        <[email-masked]>
>>>
>>> On 4/11/07, Richard Hansen <[email-masked]> wrote:
>>>> Does anyone have any experience running PRoPHET on more than two nodes?
>>>>
>>>> I'm trying to get PRoPHET to run on a simple network:  a--b--c.  Bundles 
>>>> are only forwarded if the destination is a neighboring node.  So, if a 
>>>> bundle is sourced at node "a" and destined to node "b", "a" will forward 
>>>> the bundle to "b".  If a bundle is sourced at node "a" and destined to 
>>>> node "c", the bundle will never leave node "a".  Does anyone know why?
>>>>
>>>> Thanks,
>>>> Richard Hansen
>>>> BBN Technologies
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>>
>>
>>
>> #
>> # dtn.conf
>> #
>> # Default configuration file for Internet-connected DTN nodes. The
>> # daemon uses a tcl interpreter to parse this file, thus any standard
>> # tcl commands are valid, and all settings are get/set using a single
>> # 'set' functions as: <module> set <var> <val?>
>> #
>>
>> log /dtnd info "dtnd parsing configuration..."
>>
>> ########################################
>> #
>> # Daemon Console Configuration
>> #
>> ########################################
>>
>> #
>> # console set stdio [ true | false ]
>> #
>> # If set to false, disable the interactive console on stdin/stdout.
>> # The default is set to true (unless the dtnd process is run as a
>> # daemon).
>> #
>> # console set stdio false
>>
>> #
>> # console set addr <port>
>> # console set port <port>
>> #
>> # Settings for the socket based console protocol.
>> # (this interprets user commands)
>> #
>> console set addr 127.0.0.1
>> console set port 6059
>>
>> #
>> # console set prompt <prompt>
>> #
>> # Set the prompt string.  Helps if running multiple dtnd's
>> #
>> set shorthostname [lindex [split [info hostname] .] 0]
>> console set prompt "$shorthostname dtn% "
>>
>> ########################################
>> #
>> # Storage Configuration
>> #
>> ########################################
>>
>> #
>> # storage set type [ berkeleydb | postgres | mysql ]
>> #
>> # Set the storage system to be used
>> #
>> storage set type berkeleydb
>>
>> #
>> # storage set payloaddir <dir>
>> #
>> # Set the directory to be used for bundle payload files
>> #
>> storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles
>>
>> #
>> # storage set dbname <db>
>> #
>> # Set the database name (appended with .db as the filename in berkeley
>> # db, used as-is for SQL variants
>> #
>> storage set dbname     DTN
>>
>> #
>> # storage set dbdir    <dir>
>> #
>> #
>> # When using berkeley db, set the directory to be used for the
>> # database files and the name of the files and error log.
>> #
>> storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db
>>
>> storage set tidy true
>> storage set tidy_wait 0
>> storage set init_db
>>
>> ########################################
>> #
>> # Routing configuration
>> #
>> ########################################
>>
>> #
>> # Set the algorithm used for dtn routing.
>> #
>> # route set type [static | flood | neighborhood | linkstate | external]
>> #
>> route set type prophet
>>
>> #
>> # route local_eid <eid>
>> #
>> # Set the local administrative id of this node. The default just uses
>> # the internet hostname plus the appended string ".dtn" to make it
>> # clear that the hostname isn't really used for DNS lookups.
>> #
>> route local_eid "dtn://a.dtn"
>>
>> #
>> # External router specific options
>> #
>> #route set server_port 9010
>> #route set hello_interval 30
>> #route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"
>>
>> ########################################
>> #
>> # TCP convergence layer configuration
>> #
>> ########################################
>>
>> #
>> # interface add [name] [CL]
>> #
>> # Add an input interface to listen on addr:port for incoming bundles
>> # from other tcp / udp convergence layers
>> #
>> # if not specified, localhost:5000 is used by default
>> #
>> interface add tcp0 tcp local_port=13010
>> interface add udp0 udp local_port=13010
>>
>> #
>> # link add <name> <nexthop> <type> <clayer> <args...>
>> #
>> # Add a link to a peer node
>> # (for now using the tcp or udp convergence layers)
>> #
>> # examples:
>> #       link add tcplink host:port ONDEMAND tcp
>> #       link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp
>>
>> link add b b:43009 ONDEMAND tcp remote_eid=dtn://b.dtn
>>
>> #
>> # route add <dest> <link|peer>
>> #
>> # Add a route to the given bundle endpoint id pattern <dest> using the
>> # specified link name or peer endpoint.
>> #
>> # e.g. route add dtn://host.domain/* tcp0
>>
>>
>> ########################################
>> #
>> # Parameter Tuning
>> #
>> ########################################
>>
>> #
>> # Set the size threshold for the daemon so any bundles smaller than this
>> # size maintain a shadow copy in memory to minimize disk accesses.
>> #
>> # param set payload_mem_threshold 16384
>>
>> #
>> # Test option to keep all bundle files in the filesystem, even after the
>> # bundle is no longer present at the daemon.
>> #
>> # param set payload_test_no_remove true
>>
>> #
>> # Set the size for which the tcp convergence layer sends partial 
>> reception
>> # acknowledgements. Used with reactive fragmentation
>> #
>> # param set tcpcl_partial_ack_len 4096
>>
>> #
>> # Set if bundles are automatically deleted after transmission
>> #
>> # param set early_deletion true
>>
>> ########################################
>> #
>> # API
>> #
>> ########################################
>>
>> api set local_port 15010
>>
>> # (others exist but are not fully represented here)
>>
>> log /dtnd info "dtnd configuration parsing complete"
>>
>> ## emacs settings to use tcl-mode by default
>> ## Local Variables: ***
>> ## mode:tcl ***
>> ## End: ***
>>
>> #
>> # dtn.conf
>> #
>> # Default configuration file for Internet-connected DTN nodes. The
>> # daemon uses a tcl interpreter to parse this file, thus any standard
>> # tcl commands are valid, and all settings are get/set using a single
>> # 'set' functions as: <module> set <var> <val?>
>> #
>>
>> log /dtnd info "dtnd parsing configuration..."
>>
>> ########################################
>> #
>> # Daemon Console Configuration
>> #
>> ########################################
>>
>> #
>> # console set stdio [ true | false ]
>> #
>> # If set to false, disable the interactive console on stdin/stdout.
>> # The default is set to true (unless the dtnd process is run as a
>> # daemon).
>> #
>> # console set stdio false
>>
>> #
>> # console set addr <port>
>> # console set port <port>
>> #
>> # Settings for the socket based console protocol.
>> # (this interprets user commands)
>> #
>> console set addr 127.0.0.1
>> console set port 36058
>>
>> #
>> # console set prompt <prompt>
>> #
>> # Set the prompt string.  Helps if running multiple dtnd's
>> #
>> set shorthostname [lindex [split [info hostname] .] 0]
>> console set prompt "$shorthostname dtn% "
>>
>> ########################################
>> #
>> # Storage Configuration
>> #
>> ########################################
>>
>> #
>> # storage set type [ berkeleydb | postgres | mysql ]
>> #
>> # Set the storage system to be used
>> #
>> storage set type berkeleydb
>>
>> #
>> # storage set payloaddir <dir>
>> #
>> # Set the directory to be used for bundle payload files
>> #
>> storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles
>>
>> #
>> # storage set dbname <db>
>> #
>> # Set the database name (appended with .db as the filename in berkeley
>> # db, used as-is for SQL variants
>> #
>> storage set dbname     DTN
>>
>> #
>> # storage set dbdir    <dir>
>> #
>> #
>> # When using berkeley db, set the directory to be used for the
>> # database files and the name of the files and error log.
>> #
>> storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db
>>
>> storage set tidy true
>> storage set tidy_wait 0
>> storage set init_db
>>
>> ########################################
>> #
>> # Routing configuration
>> #
>> ########################################
>>
>> #
>> # Set the algorithm used for dtn routing.
>> #
>> # route set type [static | flood | neighborhood | linkstate | external]
>> #
>> route set type prophet
>>
>> #
>> # route local_eid <eid>
>> #
>> # Set the local administrative id of this node. The default just uses
>> # the internet hostname plus the appended string ".dtn" to make it
>> # clear that the hostname isn't really used for DNS lookups.
>> #
>> route local_eid "dtn://b.dtn"
>>
>> #
>> # External router specific options
>> #
>> #route set server_port 39009
>> #route set hello_interval 30
>> #route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"
>>
>> ########################################
>> #
>> # TCP convergence layer configuration
>> #
>> ########################################
>>
>> #
>> # interface add [name] [CL]
>> #
>> # Add an input interface to listen on addr:port for incoming bundles
>> # from other tcp / udp convergence layers
>> #
>> # if not specified, localhost:5000 is used by default
>> #
>> interface add tcp0 tcp local_port=43009
>> interface add udp0 udp local_port=43009
>>
>> #
>> # link add <name> <nexthop> <type> <clayer> <args...>
>> #
>> # Add a link to a peer node
>> # (for now using the tcp or udp convergence layers)
>> #
>> # examples:
>> #       link add tcplink host:port ONDEMAND tcp
>> #       link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp
>>
>> link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
>> link add b b:13009 ONDEMAND tcp remote_eid=dtn://b.dtn
>>
>> #
>> # route add <dest> <link|peer>
>> #
>> # Add a route to the given bundle endpoint id pattern <dest> using the
>> # specified link name or peer endpoint.
>> #
>> # e.g. route add dtn://host.domain/* tcp0
>>
>>
>> ########################################
>> #
>> # Parameter Tuning
>> #
>> ########################################
>>
>> #
>> # Set the size threshold for the daemon so any bundles smaller than this
>> # size maintain a shadow copy in memory to minimize disk accesses.
>> #
>> # param set payload_mem_threshold 16384
>>
>> #
>> # Test option to keep all bundle files in the filesystem, even after the
>> # bundle is no longer present at the daemon.
>> #
>> # param set payload_test_no_remove true
>>
>> #
>> # Set the size for which the tcp convergence layer sends partial 
>> reception
>> # acknowledgements. Used with reactive fragmentation
>> #
>> # param set tcpcl_partial_ack_len 4096
>>
>> #
>> # Set if bundles are automatically deleted after transmission
>> #
>> # param set early_deletion true
>>
>> ########################################
>> #
>> # API
>> #
>> ########################################
>>
>> api set local_port 45009
>>
>> # (others exist but are not fully represented here)
>>
>> log /dtnd info "dtnd configuration parsing complete"
>>
>> ## emacs settings to use tcl-mode by default
>> ## Local Variables: ***
>> ## mode:tcl ***
>> ## End: ***
>>
>> #
>> # dtn.conf
>> #
>> # Default configuration file for Internet-connected DTN nodes. The
>> # daemon uses a tcl interpreter to parse this file, thus any standard
>> # tcl commands are valid, and all settings are get/set using a single
>> # 'set' functions as: <module> set <var> <val?>
>> #
>>
>> log /dtnd info "dtnd parsing configuration..."
>>
>> ########################################
>> #
>> # Daemon Console Configuration
>> #
>> ########################################
>>
>> #
>> # console set stdio [ true | false ]
>> #
>> # If set to false, disable the interactive console on stdin/stdout.
>> # The default is set to true (unless the dtnd process is run as a
>> # daemon).
>> #
>> # console set stdio false
>>
>> #
>> # console set addr <port>
>> # console set port <port>
>> #
>> # Settings for the socket based console protocol.
>> # (this interprets user commands)
>> #
>> console set addr 127.0.0.1
>> console set port 6058
>>
>> #
>> # console set prompt <prompt>
>> #
>> # Set the prompt string.  Helps if running multiple dtnd's
>> #
>> set shorthostname [lindex [split [info hostname] .] 0]
>> console set prompt "$shorthostname dtn% "
>>
>> ########################################
>> #
>> # Storage Configuration
>> #
>> ########################################
>>
>> #
>> # storage set type [ berkeleydb | postgres | mysql ]
>> #
>> # Set the storage system to be used
>> #
>> storage set type berkeleydb
>>
>> #
>> # storage set payloaddir <dir>
>> #
>> # Set the directory to be used for bundle payload files
>> #
>> storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles
>>
>> #
>> # storage set dbname <db>
>> #
>> # Set the database name (appended with .db as the filename in berkeley
>> # db, used as-is for SQL variants
>> #
>> storage set dbname     DTN
>>
>> #
>> # storage set dbdir    <dir>
>> #
>> #
>> # When using berkeley db, set the directory to be used for the
>> # database files and the name of the files and error log.
>> #
>> storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db
>>
>> storage set tidy true
>> storage set tidy_wait 0
>> storage set init_db
>>
>> ########################################
>> #
>> # Routing configuration
>> #
>> ########################################
>>
>> #
>> # Set the algorithm used for dtn routing.
>> #
>> # route set type [static | flood | neighborhood | linkstate | external]
>> #
>> route set type prophet
>>
>> #
>> # route local_eid <eid>
>> #
>> # Set the local administrative id of this node. The default just uses
>> # the internet hostname plus the appended string ".dtn" to make it
>> # clear that the hostname isn't really used for DNS lookups.
>> #
>> route local_eid "dtn://c.dtn"
>>
>> #
>> # External router specific options
>> #
>> #route set server_port 9009
>> #route set hello_interval 30
>> #route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"
>>
>> ########################################
>> #
>> # TCP convergence layer configuration
>> #
>> ########################################
>>
>> #
>> # interface add [name] [CL]
>> #
>> # Add an input interface to listen on addr:port for incoming bundles
>> # from other tcp / udp convergence layers
>> #
>> # if not specified, localhost:5000 is used by default
>> #
>> interface add tcp0 tcp local_port=13009
>> interface add udp0 udp local_port=13009
>>
>> #
>> # link add <name> <nexthop> <type> <clayer> <args...>
>> #
>> # Add a link to a peer node
>> # (for now using the tcp or udp convergence layers)
>> #
>> # examples:
>> #       link add tcplink host:port ONDEMAND tcp
>> #       link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp
>>
>> link add b b:43009 ONDEMAND tcp remote_eid=dtn://b.dtn
>>
>> #
>> # route add <dest> <link|peer>
>> #
>> # Add a route to the given bundle endpoint id pattern <dest> using the
>> # specified link name or peer endpoint.
>> #
>> # e.g. route add dtn://host.domain/* tcp0
>>
>>
>> ########################################
>> #
>> # Parameter Tuning
>> #
>> ########################################
>>
>> #
>> # Set the size threshold for the daemon so any bundles smaller than this
>> # size maintain a shadow copy in memory to minimize disk accesses.
>> #
>> # param set payload_mem_threshold 16384
>>
>> #
>> # Test option to keep all bundle files in the filesystem, even after the
>> # bundle is no longer present at the daemon.
>> #
>> # param set payload_test_no_remove true
>>
>> #
>> # Set the size for which the tcp convergence layer sends partial 
>> reception
>> # acknowledgements. Used with reactive fragmentation
>> #
>> # param set tcpcl_partial_ack_len 4096
>>
>> #
>> # Set if bundles are automatically deleted after transmission
>> #
>> # param set early_deletion true
>>
>> ########################################
>> #
>> # API
>> #
>> ########################################
>>
>> api set local_port 15009
>>
>> # (others exist but are not fully represented here)
>>
>> log /dtnd info "dtnd configuration parsing complete"
>>
>> ## emacs settings to use tcl-mode by default
>> ## Local Variables: ***
>> ## mode:tcl ***
>> ## End: ***

Date: Fri, 13 Apr 2007 15:21:45 -0400
From: Richard Hansen <[email-masked]>
To: Atsufumi Moriyama <[email-masked]>
CC: Jeff Wilson <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Running PRoPHET on a simple network
Sender: [email-masked]

Atsufumi Moriyama wrote:
> Hello, this is my first post to this mailing list....
> 
> I don't know the implementation and configuration of DTN well, 
> but from the symmetricity, I wonder if you intend to write
> 
>> link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
>> link add c c:13009 ONDEMAND tcp remote_eid=dtn://c.dtn
> 
> instead of
> 
>> link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
>> link add b b:13009 ONDEMAND tcp remote_eid=dtn://b.dtn
> 
> in the file "b-dtn.conf" ??

Whoops, that's definitely a typo, but it's a typo only in the .conf 
files I sent to the list.  The .conf files I'm actually using have 
different host names than "a", "b", and "c" -- I changed them to 
sanitize the files.  Looks like I made a mistake when changing the real 
host names I use to the fake ones.  I double-checked the files I'm using 
and they are correct.

> 
> Just for your reference,... and sorry for my poor English....

Thanks for catching that!

-Richard

> 
> ----
> Atsufumi Moriyama @ NICT Kyushu Research Center, Japan.
> 
> 
> Richard Hansen wrote:
>> Thank you for your reply.
>>
>> Jeff Wilson wrote:
>>> Hi Richard,
>>>
>>> What version of DTN are you using?  CVS, or some numbered release?
>>
>> I apologize for not providing enough information.  I'm using DTN (and 
>> PRoPHET) from CVS.  The dtn.confs for the three nodes are attached.  
>> I'm using the default values for all of PRoPHET's settings:
>>
>> encounter = 0.75
>> beta = 0.25
>> gamma = 0.99
>> kappa = 100
>> hello_dead = 20
>> max_forward = 5
>> min_forward = 3
>> age_period = 1800
>> relay_node = true
>> internet_gateway = false
>> epsilon = 0.0039
>> queue_policy = (got a "binding does not exist" message when checking)
>> fwd_strategy = (got a "binding does not exist" message when checking)
>> max_usage = (got a "binding does not exist" message when checking)
>>
>> So if I understand PRoPHET correctly, the initial predictabilities for 
>> the direct links are:
>>
>>   P(a,b) = P(a,b)_old + (1 - P(a,b)_old) * encounter
>>   P(a,b) = 0          + (1 - 0         ) * 0.75
>>   P(a,b) = 0.75
>>
>> and for the indirect links:
>>
>>   P(a,c) = P(a,c)_old + (1 - P(a,c)_old) * P(a,b) * P(b,c) * beta
>>   P(a,c) = 0          + (1 - 0         ) * 0.75   * 0.75   * 0.25
>>   P(a,c) = 0.1406
>>
>> Over time, the predictabilities are calculated as follows (assuming 
>> the links stay up):
>>
>>   Time      Predictabilities
>> ====================================================================
>>    0-1800   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.7500, P(a,c)=P(c,a)=0.1406
>> 1800-3600   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9375, P(a,c)=P(c,a)=0.3295
>> 3600-5400   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9844, P(a,c)=P(c,a)=0.4919
>> 5400-7200   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9961, P(a,c)=P(c,a)=0.6179
>> 7200-9000   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9990, P(a,c)=P(c,a)=0.7133
>>    and so on...
>>
>> I'm wondering if my assumptions leading to the above calculations are 
>> correct...  Could the transitive predictabilities be shifted down one 
>> time slot (and be equal to 0 during the first time slot)?  If so, that 
>> would account for the behavior I'm seeing, and I would have to wait 
>> for 1800 seconds until the bundles are forwarded.  If my above 
>> calculations are correct, all of the predictabilities are greater than 
>> epsilon, so I would expect it to forward.  Or is this not what epsilon 
>> means?
>>
>> I will try increasing beta and encounter and reducing age_period to 
>> see if I can get it to work.
>>
>> Thanks,
>> Richard
>>
>>>
>>> The bug you are describing sounds like a bug with the earlier 
>>> DTN/Prophet releases... the Prophet I-D allows for an exception to 
>>> the peering protocol so that directly connected nodes can deliver 
>>> bundles destined to one another, apart from the results of the 
>>> Prophet protocol.  It sounds like the direct-connect exception is 
>>> working.  For some reason, the full peering isn't working.
>>>
>>> The Prophet router in the current CVS has quite a few bug fixes since 
>>> the last DTN release.  Another wave of patches is coming out soon.
>>>
>>> Hope that helps ...
>>>
>>>        Regards,
>>>        Jeff
>>>        <[email-masked]>
>>>
>>> On 4/11/07, Richard Hansen <[email-masked]> wrote:
>>>> Does anyone have any experience running PRoPHET on more than two nodes?
>>>>
>>>> I'm trying to get PRoPHET to run on a simple network:  a--b--c.  
>>>> Bundles are only forwarded if the destination is a neighboring 
>>>> node.  So, if a bundle is sourced at node "a" and destined to node 
>>>> "b", "a" will forward the bundle to "b".  If a bundle is sourced at 
>>>> node "a" and destined to node "c", the bundle will never leave node 
>>>> "a".  Does anyone know why?
>>>>
>>>> Thanks,
>>>> Richard Hansen
>>>> BBN Technologies
>>>> _______________________________________________
>>>> dtn-interest mailing list
>>>> [email-masked]
>>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Fri, 13 Apr 2007 09:32:25 +0900
From: Atsufumi Moriyama <[email-masked]>
To: Richard Hansen <[email-masked]>
CC: Jeff Wilson <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Running PRoPHET on a simple network
Sender: [email-masked]

Hello, this is my first post to this mailing list....

I don't know the implementation and configuration of DTN well,
but from the symmetricity, I wonder if you intend to write

 > link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
 > link add c c:13009 ONDEMAND tcp remote_eid=dtn://c.dtn

instead of

 > link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
 > link add b b:13009 ONDEMAND tcp remote_eid=dtn://b.dtn

in the file "b-dtn.conf" ??

Just for your reference,... and sorry for my poor English....

----
Atsufumi Moriyama @ NICT Kyushu Research Center, Japan.

Richard Hansen wrote:
> Thank you for your reply.
> 
> Jeff Wilson wrote:
>> Hi Richard,
>>
>> What version of DTN are you using?  CVS, or some numbered release?
> 
> I apologize for not providing enough information.  I'm using DTN (and 
> PRoPHET) from CVS.  The dtn.confs for the three nodes are attached.  I'm 
> using the default values for all of PRoPHET's settings:
> 
> encounter = 0.75
> beta = 0.25
> gamma = 0.99
> kappa = 100
> hello_dead = 20
> max_forward = 5
> min_forward = 3
> age_period = 1800
> relay_node = true
> internet_gateway = false
> epsilon = 0.0039
> queue_policy = (got a "binding does not exist" message when checking)
> fwd_strategy = (got a "binding does not exist" message when checking)
> max_usage = (got a "binding does not exist" message when checking)
> 
> So if I understand PRoPHET correctly, the initial predictabilities for 
> the direct links are:
> 
>   P(a,b) = P(a,b)_old + (1 - P(a,b)_old) * encounter
>   P(a,b) = 0          + (1 - 0         ) * 0.75
>   P(a,b) = 0.75
> 
> and for the indirect links:
> 
>   P(a,c) = P(a,c)_old + (1 - P(a,c)_old) * P(a,b) * P(b,c) * beta
>   P(a,c) = 0          + (1 - 0         ) * 0.75   * 0.75   * 0.25
>   P(a,c) = 0.1406
> 
> Over time, the predictabilities are calculated as follows (assuming the 
> links stay up):
> 
>   Time      Predictabilities
> ====================================================================
>    0-1800   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.7500, P(a,c)=P(c,a)=0.1406
> 1800-3600   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9375, P(a,c)=P(c,a)=0.3295
> 3600-5400   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9844, P(a,c)=P(c,a)=0.4919
> 5400-7200   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9961, P(a,c)=P(c,a)=0.6179
> 7200-9000   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9990, P(a,c)=P(c,a)=0.7133
>    and so on...
> 
> I'm wondering if my assumptions leading to the above calculations are 
> correct...  Could the transitive predictabilities be shifted down one 
> time slot (and be equal to 0 during the first time slot)?  If so, that 
> would account for the behavior I'm seeing, and I would have to wait for 
> 1800 seconds until the bundles are forwarded.  If my above calculations 
> are correct, all of the predictabilities are greater than epsilon, so I 
> would expect it to forward.  Or is this not what epsilon means?
> 
> I will try increasing beta and encounter and reducing age_period to see 
> if I can get it to work.
> 
> Thanks,
> Richard
> 
>>
>> The bug you are describing sounds like a bug with the earlier 
>> DTN/Prophet releases... the Prophet I-D allows for an exception to the 
>> peering protocol so that directly connected nodes can deliver bundles 
>> destined to one another, apart from the results of the Prophet 
>> protocol.  It sounds like the direct-connect exception is working.  
>> For some reason, the full peering isn't working.
>>
>> The Prophet router in the current CVS has quite a few bug fixes since 
>> the last DTN release.  Another wave of patches is coming out soon.
>>
>> Hope that helps ...
>>
>>        Regards,
>>        Jeff
>>        <[email-masked]>
>>
>> On 4/11/07, Richard Hansen <[email-masked]> wrote:
>>> Does anyone have any experience running PRoPHET on more than two nodes?
>>>
>>> I'm trying to get PRoPHET to run on a simple network:  a--b--c.  
>>> Bundles are only forwarded if the destination is a neighboring node.  
>>> So, if a bundle is sourced at node "a" and destined to node "b", "a" 
>>> will forward the bundle to "b".  If a bundle is sourced at node "a" 
>>> and destined to node "c", the bundle will never leave node "a".  Does 
>>> anyone know why?
>>>
>>> Thanks,
>>> Richard Hansen
>>> BBN Technologies
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>>
> 

Date: Thu, 12 Apr 2007 19:29:21 +0100
To: "David Moran" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: RE: [dtn-interest] Re: the fecund Mozart (was T-shirt contest)
Cc: dtn interest <[email-masked]>
Sender: [email-masked]

Seems like the theme music to DTN is Mozart's Eine kleine Nachtmusik. (Its Romanze is used in the movie 'Alien')

L.

"I should reach the frontier in about 6 weeks. With a little luck, the network will pick me up. This is Ripley, last survivor of the Nostromo, signing off."

From: "David Moran" <[email-masked]>
To: "'Marshall Eubanks'" <[email-masked]>, "'Kevin Fall'" <[email-masked]>
Cc: "'Lloyd Wood'" <[email-masked]>, "'dtn interest'" <[email-masked]>
Subject: RE: [dtn-interest] Re: the fecund Mozart (was T-shirt contest)
Date: Thu, 12 Apr 2007 14:14:00 -0400
Sender: [email-masked]

I do not know about Mozart's reply and its documentation and sources ---
nothing from Peter Shaffer is to be trusted, least of all the boob depiction
of the composer --- but Joseph's comment was and is famous 

( Grove; http://w3.rz-berlin.mpg.de/cmp/mozart.html ),

and typically misunderstood, somewhat anyway, as it was a common observation
that the man's genius was a flooding spigot:

\\\ The famous complaint of Emperor Joseph II about The Marriage of Figaro
-- "too many notes, Mozart" -- is generally perceived to be a gaffe by a
blockhead. In fact, Joseph was echoing what nearly everybody, including his
admirers, said about Mozart: he was so imaginative that he couldn't turn it
off, and that made his music at times intense, even demonic. Hence Mozart's
bad, or cautionary, reviews: "too strongly spiced"; "impenetrable
labyrinths"; "bizarre flights of the soul"; "overloaded and overstuffed."

( Jan Swafford at
http://arts.guardian.co.uk/fridayreview/story/0,12102,1230395,00.html )

David Moran
Senior technical writer
Network Technologies Business Unit
BBN Technologies
10 Moulton St.
Cambridge, Mass. 02138
o: 617 873-5919

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall Eubanks
Sent: Thursday, April 12, 2007 2:00 PM
To: Kevin Fall
Cc: Lloyd Wood; dtn interest
Subject: Re: [dtn-interest] Re: T-shirt contest

On Apr 12, 2007, at 11:47 AM, Kevin Fall wrote:

> ah, yes!  That is the one...  I had thought Salieri said that  
> bit.    Oh well, it *has* been 20+ years...
>
> - K
>

In the movie the Director of the Opera, Count Orsini-Rosenberg, first  
said it in the Emperor's
presence in reference to Idomeneo
"a tiresome piece... too many notes"

And the Emperor picked up on it and riffed on it at the premier of  
the Abduction.

However, wherever he got the idea, both the Emperor Joseph II  
statement and Mozart's cheeky reply actually happened and
are in the historical record.

Regards
Marshall Eubanks

> On Apr 11, 2007, at 4:21 PM@Apr 11, 2007, Lloyd Wood wrote:
>
>> At Wednesday 11/04/2007 15:55 -0700, Kevin Fall wrote:
>>> Heh.  We could combine that picture with:
>>>
>>> Salieri:  Too Many Notes
>>
>>  From the script of _Amadeus_:
>>
>> Emperor Joseph II: My dear young man, don't take it too hard. Your  
>> work is ingenious. It's quality work. And there are simply too  
>> many notes, that's all. Just cut a few and it will be perfect.
>> Mozart: Which few did you have in mind, Majesty?
>>

Cc: Lloyd Wood <[email-masked]>, dtn interest <[email-masked]>
From: Marshall Eubanks <[email-masked]>
Subject: Re: [dtn-interest] Re: T-shirt contest
Date: Thu, 12 Apr 2007 13:59:51 -0400
To: Kevin Fall <[email-masked]>
Sender: [email-masked]

On Apr 12, 2007, at 11:47 AM, Kevin Fall wrote:

> ah, yes!  That is the one...  I had thought Salieri said that  
> bit.    Oh well, it *has* been 20+ years...
>
> - K
>

In the movie the Director of the Opera, Count Orsini-Rosenberg, first  
said it in the Emperor's
presence in reference to Idomeneo
"a tiresome piece... too many notes"

And the Emperor picked up on it and riffed on it at the premier of  
the Abduction.

However, wherever he got the idea, both the Emperor Joseph II  
statement and Mozart's cheeky reply actually happened and
are in the historical record.

Regards
Marshall Eubanks

> On Apr 11, 2007, at 4:21 PM@Apr 11, 2007, Lloyd Wood wrote:
>
>> At Wednesday 11/04/2007 15:55 -0700, Kevin Fall wrote:
>>> Heh.  We could combine that picture with:
>>>
>>> Salieri:  Too Many Notes
>>
>>  From the script of _Amadeus_:
>>
>> Emperor Joseph II: My dear young man, don't take it too hard. Your  
>> work is ingenious. It's quality work. And there are simply too  
>> many notes, that's all. Just cut a few and it will be perfect.
>> Mozart: Which few did you have in mind, Majesty?
>>
>>
>>> RFC-Editor:  Too Many Authors
>>>
>>> - K
>>>
>>>
>>> On Apr 11, 2007, at 3:46 PM@Apr 11, 2007, Adrian J. Hooke wrote:
>>>
>>>> At 02:23 PM 4/11/2007, Stephen Farrell wrote:
>>>>> Ok, then, a competition - post your t-shirt logo design here
>>>>
>>>> In honor of the large number of authors, perhaps a reproduction  
>>>> of David Octavius Hill's painting? --
>>>>
>>>> http://special.lib.gla.ac.uk/hillandadamson/dis.html
>>>>
>>>> ///a
>> _______________________________________________
>> 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

Cc: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] Re: T-shirt contest
Date: Thu, 12 Apr 2007 08:47:49 -0700
To: Lloyd Wood <[email-masked]>
Sender: [email-masked]

ah, yes!  That is the one...  I had thought Salieri said that bit.     
Oh well, it *has* been 20+ years...

- K

On Apr 11, 2007, at 4:21 PM@Apr 11, 2007, Lloyd Wood wrote:

> At Wednesday 11/04/2007 15:55 -0700, Kevin Fall wrote:
>> Heh.  We could combine that picture with:
>>
>> Salieri:  Too Many Notes
>
>  From the script of _Amadeus_:
>
> Emperor Joseph II: My dear young man, don't take it too hard. Your  
> work is ingenious. It's quality work. And there are simply too many  
> notes, that's all. Just cut a few and it will be perfect.
> Mozart: Which few did you have in mind, Majesty?
>
>
>> RFC-Editor:  Too Many Authors
>>
>> - K
>>
>>
>> On Apr 11, 2007, at 3:46 PM@Apr 11, 2007, Adrian J. Hooke wrote:
>>
>>> At 02:23 PM 4/11/2007, Stephen Farrell wrote:
>>>> Ok, then, a competition - post your t-shirt logo design here
>>>
>>> In honor of the large number of authors, perhaps a reproduction  
>>> of David Octavius Hill's painting? --
>>>
>>> http://special.lib.gla.ac.uk/hillandadamson/dis.html
>>>
>>> ///a
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Thu, 12 Apr 2007 11:33:12 -0400
From: Richard Hansen <[email-masked]>
To: Jeff Wilson <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] Running PRoPHET on a simple network
Sender: [email-masked]

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

Thank you for your reply.

Jeff Wilson wrote:
> Hi Richard,
> 
> What version of DTN are you using?  CVS, or some numbered release?

I apologize for not providing enough information.  I'm using DTN (and 
PRoPHET) from CVS.  The dtn.confs for the three nodes are attached.  I'm 
using the default values for all of PRoPHET's settings:

encounter = 0.75
beta = 0.25
gamma = 0.99
kappa = 100
hello_dead = 20
max_forward = 5
min_forward = 3
age_period = 1800
relay_node = true
internet_gateway = false
epsilon = 0.0039
queue_policy = (got a "binding does not exist" message when checking)
fwd_strategy = (got a "binding does not exist" message when checking)
max_usage = (got a "binding does not exist" message when checking)

So if I understand PRoPHET correctly, the initial predictabilities for 
the direct links are:

   P(a,b) = P(a,b)_old + (1 - P(a,b)_old) * encounter
   P(a,b) = 0          + (1 - 0         ) * 0.75
   P(a,b) = 0.75

and for the indirect links:

   P(a,c) = P(a,c)_old + (1 - P(a,c)_old) * P(a,b) * P(b,c) * beta
   P(a,c) = 0          + (1 - 0         ) * 0.75   * 0.75   * 0.25
   P(a,c) = 0.1406

Over time, the predictabilities are calculated as follows (assuming the 
links stay up):

   Time      Predictabilities
====================================================================
    0-1800   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.7500, P(a,c)=P(c,a)=0.1406
1800-3600   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9375, P(a,c)=P(c,a)=0.3295
3600-5400   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9844, P(a,c)=P(c,a)=0.4919
5400-7200   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9961, P(a,c)=P(c,a)=0.6179
7200-9000   P(a,b)=P(b,a)=P(b,c)=P(c,b)=0.9990, P(a,c)=P(c,a)=0.7133
    and so on...

I'm wondering if my assumptions leading to the above calculations are 
correct...  Could the transitive predictabilities be shifted down one 
time slot (and be equal to 0 during the first time slot)?  If so, that 
would account for the behavior I'm seeing, and I would have to wait for 
1800 seconds until the bundles are forwarded.  If my above calculations 
are correct, all of the predictabilities are greater than epsilon, so I 
would expect it to forward.  Or is this not what epsilon means?

I will try increasing beta and encounter and reducing age_period to see 
if I can get it to work.

Thanks,
Richard

> 
> The bug you are describing sounds like a bug with the earlier 
> DTN/Prophet releases... the Prophet I-D allows for an exception to the 
> peering protocol so that directly connected nodes can deliver bundles 
> destined to one another, apart from the results of the Prophet 
> protocol.  It sounds like the direct-connect exception is working.  
> For some reason, the full peering isn't working.
> 
> The Prophet router in the current CVS has quite a few bug fixes since 
> the last DTN release.  Another wave of patches is coming out soon.
> 
> Hope that helps ...
> 
>        Regards,
>        Jeff
>        <[email-masked]>
> 
> On 4/11/07, Richard Hansen <[email-masked]> wrote:
>> Does anyone have any experience running PRoPHET on more than two nodes?
>>
>> I'm trying to get PRoPHET to run on a simple network:  a--b--c.  Bundles 
>> are only forwarded if the destination is a neighboring node.  So, if a 
>> bundle is sourced at node "a" and destined to node "b", "a" will forward 
>> the bundle to "b".  If a bundle is sourced at node "a" and destined to 
>> node "c", the bundle will never leave node "a".  Does anyone know why?
>>
>> Thanks,
>> Richard Hansen
>> BBN Technologies
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>

--------------080800070702080905020400
Content-Type: text/plain;
 name="a-dtn.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="a-dtn.conf"

#
# dtn.conf
#
# Default configuration file for Internet-connected DTN nodes. The
# daemon uses a tcl interpreter to parse this file, thus any standard
# tcl commands are valid, and all settings are get/set using a single
# 'set' functions as: <module> set <var> <val?>
#

log /dtnd info "dtnd parsing configuration..."

########################################
#
# Daemon Console Configuration
#
########################################

#
# console set stdio [ true | false ]
#
# If set to false, disable the interactive console on stdin/stdout.
# The default is set to true (unless the dtnd process is run as a
# daemon).
#
# console set stdio false

#
# console set addr <port>
# console set port <port>
#
# Settings for the socket based console protocol.
# (this interprets user commands)
#
console set addr 127.0.0.1
console set port 6059

#
# console set prompt <prompt>
#
# Set the prompt string.  Helps if running multiple dtnd's
#
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "

########################################
#
# Storage Configuration
#
########################################

#
# storage set type [ berkeleydb | postgres | mysql ]
#
# Set the storage system to be used
#
storage set type berkeleydb

#
# storage set payloaddir <dir>
#
# Set the directory to be used for bundle payload files
#
storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles

#
# storage set dbname <db>
#
# Set the database name (appended with .db as the filename in berkeley
# db, used as-is for SQL variants
#
storage set dbname     DTN

#
# storage set dbdir    <dir>
#
#
# When using berkeley db, set the directory to be used for the
# database files and the name of the files and error log.
#
storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db

storage set tidy true
storage set tidy_wait 0
storage set init_db

########################################
#
# Routing configuration
#
########################################

#
# Set the algorithm used for dtn routing.
#
# route set type [static | flood | neighborhood | linkstate | external]
#
route set type prophet

#
# route local_eid <eid>
#
# Set the local administrative id of this node. The default just uses
# the internet hostname plus the appended string ".dtn" to make it
# clear that the hostname isn't really used for DNS lookups.
#
route local_eid "dtn://a.dtn"

#
# External router specific options
#
#route set server_port 9010
#route set hello_interval 30
#route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"

########################################
#
# TCP convergence layer configuration
#
########################################

#
# interface add [name] [CL]
#
# Add an input interface to listen on addr:port for incoming bundles
# from other tcp / udp convergence layers
#
# if not specified, localhost:5000 is used by default
#
interface add tcp0 tcp local_port=13010
interface add udp0 udp local_port=13010

#
# link add <name> <nexthop> <type> <clayer> <args...>
#
# Add a link to a peer node
# (for now using the tcp or udp convergence layers)
#
# examples:
# 	link add tcplink host:port ONDEMAND tcp
# 	link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp

link add b b:43009 ONDEMAND tcp remote_eid=dtn://b.dtn

#
# route add <dest> <link|peer>
#
# Add a route to the given bundle endpoint id pattern <dest> using the
# specified link name or peer endpoint.
#
# e.g. route add dtn://host.domain/* tcp0

########################################
#
# Parameter Tuning
#
########################################

#
# Set the size threshold for the daemon so any bundles smaller than this
# size maintain a shadow copy in memory to minimize disk accesses. 
#
# param set payload_mem_threshold 16384

#
# Test option to keep all bundle files in the filesystem, even after the
# bundle is no longer present at the daemon.
#
# param set payload_test_no_remove true

#
# Set the size for which the tcp convergence layer sends partial reception
# acknowledgements. Used with reactive fragmentation
#
# param set tcpcl_partial_ack_len 4096

#
# Set if bundles are automatically deleted after transmission
#
# param set early_deletion true

########################################
#
# API 
#
########################################

api set local_port 15010

# (others exist but are not fully represented here)

log /dtnd info "dtnd configuration parsing complete"

## emacs settings to use tcl-mode by default
## Local Variables: ***
## mode:tcl ***
## End: ***

--------------080800070702080905020400
Content-Type: text/plain;
 name="b-dtn.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="b-dtn.conf"

#
# dtn.conf
#
# Default configuration file for Internet-connected DTN nodes. The
# daemon uses a tcl interpreter to parse this file, thus any standard
# tcl commands are valid, and all settings are get/set using a single
# 'set' functions as: <module> set <var> <val?>
#

log /dtnd info "dtnd parsing configuration..."

########################################
#
# Daemon Console Configuration
#
########################################

#
# console set stdio [ true | false ]
#
# If set to false, disable the interactive console on stdin/stdout.
# The default is set to true (unless the dtnd process is run as a
# daemon).
#
# console set stdio false

#
# console set addr <port>
# console set port <port>
#
# Settings for the socket based console protocol.
# (this interprets user commands)
#
console set addr 127.0.0.1
console set port 36058

#
# console set prompt <prompt>
#
# Set the prompt string.  Helps if running multiple dtnd's
#
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "

########################################
#
# Storage Configuration
#
########################################

#
# storage set type [ berkeleydb | postgres | mysql ]
#
# Set the storage system to be used
#
storage set type berkeleydb

#
# storage set payloaddir <dir>
#
# Set the directory to be used for bundle payload files
#
storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles

#
# storage set dbname <db>
#
# Set the database name (appended with .db as the filename in berkeley
# db, used as-is for SQL variants
#
storage set dbname     DTN

#
# storage set dbdir    <dir>
#
#
# When using berkeley db, set the directory to be used for the
# database files and the name of the files and error log.
#
storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db

storage set tidy true
storage set tidy_wait 0
storage set init_db

########################################
#
# Routing configuration
#
########################################

#
# Set the algorithm used for dtn routing.
#
# route set type [static | flood | neighborhood | linkstate | external]
#
route set type prophet

#
# route local_eid <eid>
#
# Set the local administrative id of this node. The default just uses
# the internet hostname plus the appended string ".dtn" to make it
# clear that the hostname isn't really used for DNS lookups.
#
route local_eid "dtn://b.dtn"

#
# External router specific options
#
#route set server_port 39009
#route set hello_interval 30
#route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"

########################################
#
# TCP convergence layer configuration
#
########################################

#
# interface add [name] [CL]
#
# Add an input interface to listen on addr:port for incoming bundles
# from other tcp / udp convergence layers
#
# if not specified, localhost:5000 is used by default
#
interface add tcp0 tcp local_port=43009
interface add udp0 udp local_port=43009

#
# link add <name> <nexthop> <type> <clayer> <args...>
#
# Add a link to a peer node
# (for now using the tcp or udp convergence layers)
#
# examples:
# 	link add tcplink host:port ONDEMAND tcp
# 	link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp

link add a a:13010 ONDEMAND tcp remote_eid=dtn://a.dtn
link add b b:13009 ONDEMAND tcp remote_eid=dtn://b.dtn

#
# route add <dest> <link|peer>
#
# Add a route to the given bundle endpoint id pattern <dest> using the
# specified link name or peer endpoint.
#
# e.g. route add dtn://host.domain/* tcp0

########################################
#
# Parameter Tuning
#
########################################

#
# Set the size threshold for the daemon so any bundles smaller than this
# size maintain a shadow copy in memory to minimize disk accesses. 
#
# param set payload_mem_threshold 16384

#
# Test option to keep all bundle files in the filesystem, even after the
# bundle is no longer present at the daemon.
#
# param set payload_test_no_remove true

#
# Set the size for which the tcp convergence layer sends partial reception
# acknowledgements. Used with reactive fragmentation
#
# param set tcpcl_partial_ack_len 4096

#
# Set if bundles are automatically deleted after transmission
#
# param set early_deletion true

########################################
#
# API 
#
########################################

api set local_port 45009

# (others exist but are not fully represented here)

log /dtnd info "dtnd configuration parsing complete"

## emacs settings to use tcl-mode by default
## Local Variables: ***
## mode:tcl ***
## End: ***

--------------080800070702080905020400
Content-Type: text/plain;
 name="c-dtn.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="c-dtn.conf"

#
# dtn.conf
#
# Default configuration file for Internet-connected DTN nodes. The
# daemon uses a tcl interpreter to parse this file, thus any standard
# tcl commands are valid, and all settings are get/set using a single
# 'set' functions as: <module> set <var> <val?>
#

log /dtnd info "dtnd parsing configuration..."

########################################
#
# Daemon Console Configuration
#
########################################

#
# console set stdio [ true | false ]
#
# If set to false, disable the interactive console on stdin/stdout.
# The default is set to true (unless the dtnd process is run as a
# daemon).
#
# console set stdio false

#
# console set addr <port>
# console set port <port>
#
# Settings for the socket based console protocol.
# (this interprets user commands)
#
console set addr 127.0.0.1
console set port 6058

#
# console set prompt <prompt>
#
# Set the prompt string.  Helps if running multiple dtnd's
#
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "

########################################
#
# Storage Configuration
#
########################################

#
# storage set type [ berkeleydb | postgres | mysql ]
#
# Set the storage system to be used
#
storage set type berkeleydb

#
# storage set payloaddir <dir>
#
# Set the directory to be used for bundle payload files
#
storage set payloaddir /home/rhansen/dtn2/cvs/install/dtnd/bundles

#
# storage set dbname <db>
#
# Set the database name (appended with .db as the filename in berkeley
# db, used as-is for SQL variants
#
storage set dbname     DTN

#
# storage set dbdir    <dir>
#
#
# When using berkeley db, set the directory to be used for the
# database files and the name of the files and error log.
#
storage set dbdir      /home/rhansen/dtn2/cvs/install/dtnd/db

storage set tidy true
storage set tidy_wait 0
storage set init_db

########################################
#
# Routing configuration
#
########################################

#
# Set the algorithm used for dtn routing.
#
# route set type [static | flood | neighborhood | linkstate | external]
#
route set type prophet

#
# route local_eid <eid>
#
# Set the local administrative id of this node. The default just uses
# the internet hostname plus the appended string ".dtn" to make it
# clear that the hostname isn't really used for DNS lookups.
#
route local_eid "dtn://c.dtn"

#
# External router specific options
#
#route set server_port 9009
#route set hello_interval 30
#route set schema "/home/rhansen/dtn2/cvs/install/etc/dtn/router.xsd"

########################################
#
# TCP convergence layer configuration
#
########################################

#
# interface add [name] [CL]
#
# Add an input interface to listen on addr:port for incoming bundles
# from other tcp / udp convergence layers
#
# if not specified, localhost:5000 is used by default
#
interface add tcp0 tcp local_port=13009
interface add udp0 udp local_port=13009

#
# link add <name> <nexthop> <type> <clayer> <args...>
#
# Add a link to a peer node
# (for now using the tcp or udp convergence layers)
#
# examples:
# 	link add tcplink host:port ONDEMAND tcp
# 	link add LINK1 dtn.dtnrg.org:5000 ONDEMAND tcp

link add b b:43009 ONDEMAND tcp remote_eid=dtn://b.dtn

#
# route add <dest> <link|peer>
#
# Add a route to the given bundle endpoint id pattern <dest> using the
# specified link name or peer endpoint.
#
# e.g. route add dtn://host.domain/* tcp0

########################################
#
# Parameter Tuning
#
########################################

#
# Set the size threshold for the daemon so any bundles smaller than this
# size maintain a shadow copy in memory to minimize disk accesses. 
#
# param set payload_mem_threshold 16384

#
# Test option to keep all bundle files in the filesystem, even after the
# bundle is no longer present at the daemon.
#
# param set payload_test_no_remove true

#
# Set the size for which the tcp convergence layer sends partial reception
# acknowledgements. Used with reactive fragmentation
#
# param set tcpcl_partial_ack_len 4096

#
# Set if bundles are automatically deleted after transmission
#
# param set early_deletion true

########################################
#
# API 
#
########################################

api set local_port 15009

# (others exist but are not fully represented here)

log /dtnd info "dtnd configuration parsing complete"

## emacs settings to use tcl-mode by default
## Local Variables: ***
## mode:tcl ***
## End: ***

--------------080800070702080905020400--

Date: Thu, 12 Apr 2007 16:20:28 +0100
To: "David Moran" <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: RE: [dtn-interest] Dublin meeting T-shirt contest
Cc: dtn interest <[email-masked]>
Sender: [email-masked]

--=====================_8264656==_
Content-Type: text/plain; charset="us-ascii"

At Thursday 12/04/2007 10:15 -0400, David Moran wrote:
>Mr Wood,
>
>This seems to me to be quite nicely designed. 
>
>Might I suggest keeping the traditional compound adjective hyphen in 'delay
>tolerant' (= delay-tolerant)?

That's fine by me -- more use of hyphenating adjectival terms is needed in general RFCs imo. (it's even missing from the top of http://www.dtnrg.org/wiki, where you'd lower-case the T).

Powerpoint's tracking of the hyphen was particularly horrible, so I wound up overlaying it by hand; easier than the blocking out needed to get the y in delay to also act as the tittle on the i. I think the tracking of the words (now in Helvetica, with the @ in Arial Black bold/italic, vertical spacing adjusted) could be much better overall if it was slightly tighter or if Powerpoint supported kerning - but I don't have Illustrator or similar available. (Viewing the pdf is preferable to using OpenOffice.)

Revised version attached as ppt and pdf.

cheers,

L.

>David Moran
>Senior technical writer
>Network Technologies Business Unit
>BBN Technologies
>10 Moulton St.
>Cambridge, Mass. 02138
>o: 617 873-5919
>c: 617 584-6330
>h: 781-259-9343
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Lloyd Wood
>Sent: Wednesday, April 11, 2007 6:15 PM
>To: Stephen Farrell
>Cc: dtn interest
>Subject: [dtn-interest] Dublin meeting T-shirt contest
>
>At Wednesday 11/04/2007 22:23 +0100, Stephen Farrell wrote:
>
>>Ok, then, a competition - post your t-shirt logo design here
>>before May 10 and I'll arrange to get some made for the Dublin
>>meeting. (I guess 2 colour only unless someone wants to chip
>>in with some dosh. I've no idea how we'll pick if we get a
>>few acceptable designs, but we'll think of something.)
>
>Proposed design attached in ppt and pdf formats.
>
>L.
>
><http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 

--=====================_8264656==_
Content-Type: application/octet-stream; name="wood-dtn-workshop-shirt-design-2.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wood-dtn-workshop-shirt-design-2.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAADQAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////FgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAD+/////v///w8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+/////v//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///+////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_8264656==_
Content-Type: application/octet-stream; name="wood-dtn-workshop-shirt-design-2.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wood-dtn-workshop-shirt-design-2.pdf"

--=====================_8264656==_--

Date: Thu, 12 Apr 2007 00:21:57 +0100
To: Kevin Fall <[email-masked]>
From: Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Re: T-shirt contest
Cc: dtn interest <[email-masked]>
Sender: [email-masked]

At Wednesday 11/04/2007 15:55 -0700, Kevin Fall wrote:
>Heh.  We could combine that picture with:
>
>Salieri:  Too Many Notes

 From the script of _Amadeus_:

Emperor Joseph II: My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect.
Mozart: Which few did you have in mind, Majesty? 

>RFC-Editor:  Too Many Authors
>
>- K
>
>
>On Apr 11, 2007, at 3:46 PM@Apr 11, 2007, Adrian J. Hooke wrote:
>
>>At 02:23 PM 4/11/2007, Stephen Farrell wrote:
>>>Ok, then, a competition - post your t-shirt logo design here
>>
>>In honor of the large number of authors, perhaps a reproduction of David Octavius Hill's painting? --
>>
>>http://special.lib.gla.ac.uk/hillandadamson/dis.html
>>
>>///a

To: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Wed, 11 Apr 2007 16:20:36 -0700
Subject: [dtn-interest] IEEE JSAC Journal Issue on DTN
Sender: [email-masked]

Please see the following CFP for the upcoming JSAC issue on DTN:

http://www.jsac.ucsd.edu/Calls/Delayanddisruption.pdf

- K

Here is a text (not pretty) version....

CALL FOR PAPERS
IEEE Journal on Selected Areas in Communications
DELAY AND DISRUPTION TOLERANT WIRELESS COMMUNICATION

Modern computer communication has been developed for providing  
continuous end-to-end connectivity. There are,
however, communication services that are tolerant to disruptions and  
delay and do not require or cannot be given
continuous connectivity. It is time to consider the unconnected network.

This issue is dedicated to communication over wireless networks with  
intermittent connectivity due to planned or
unexpected disruptions that may result in long delays for the  
communicating parties. Communication disruptions occur
both in infrastructure and ad-hoc wireless networks. In both cases,  
it is possible that mobile nodes cooperatively
forward data for one another through their own movements. The  
mobility patterns of nodes affect thereby both the
speed and reliability of data forwarding. Intermittent communication  
occurs also in sensor networks due to, e.g.,
energy-saving sleep cycles, and in deep-space communication and  
meteor-burst communication. The communication
services that may use such intermittent and high-delay connections  
are characterized by a low degree of interactivity,
e.g., broadcasting, messaging, and data collection. Opportunistic  
strategies for caching and communicating may
improve the performance in terms of reduced delay and improved  
probability of delivery.

This issue of J-SAC is dedicated to technologies, systems designs and  
analyses that contribute to the development and
understanding of delay and disruption tolerant wireless communication  
systems.

Original contributions, previously unpublished and not currently  
under review, are solicited in relevant areas including
(but not limited to) the following.
• Data encoding for partial and unordered
delivery
• User studies of delay and disruption tolerances
• Opportunistic caching and pre-fetching for
concealment of service disruptions
• Mobility measurements, modeling and
performance analysis
• Uni-, any-, and multicast routing protocols
• Congestion, flow and error control, per-hop
and multi-hop solutions
• Security, privacy, authenticity and traceability
of communication
• Energy saving strategies and power
management
• Applications to personal communication,
sensor networks, road-traffic systems and
industrial communication

Prospective authors should follow the IEEE J-SAC manuscript format  
described in the Information for Authors under
http://www.jsac.ucsd.edu/. All papers should be submitted through CRP  
in PDF format, according to the following
timetable:
Submission deadline:             June 1, 2007
Acceptance Notification:         November 1, 2007
Final Manuscript due:     January 10, 2008
Publication:                     2nd quarter 2008

Guest editors:

Kevin Almeroth    Kevin Fall    Gunnar Karlsson
Dep. of Computer Science   2150 Shattuck Avenue    School of  
Electrical Eng.
University of California   Intel Research Berkeley  KTH, Royal Ins.  
of Tech.
Santa Barbara, CA, USA   Berkeley, CA, USA   Stockholm, Sweden
[email-masked]  [email-masked]   [email-masked]

Martin May    Roy Yates
TIK     WINLAB
ETH Zurich     Rutgers University
Zurich, Switzerland    Piscataway, NJ, USA
[email-masked]    [email-masked]

Date: Wed, 11 Apr 2007 18:56:23 -0400
From: Richard Hansen <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] Running PRoPHET on a simple network
Sender: [email-masked]

Does anyone have any experience running PRoPHET on more than two nodes?

I'm trying to get PRoPHET to run on a simple network:  a--b--c.  Bundles 
are only forwarded if the destination is a neighboring node.  So, if a 
bundle is sourced at node "a" and destined to node "b", "a" will forward 
the bundle to "b".  If a bundle is sourced at node "a" and destined to 
node "c", the bundle will never leave node "a".  Does anyone know why?

Thanks,
Richard Hansen
BBN Technologies

Cc: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Subject: Re: [dtn-interest] Re: T-shirt contest
Date: Wed, 11 Apr 2007 15:55:59 -0700
To: "Adrian J. Hooke" <[email-masked]>
Sender: [email-masked]

--Apple-Mail-3-456463747
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Heh.  We could combine that picture with:

Salieri:  Too Many Notes
RFC-Editor:  Too Many Authors

- K

On Apr 11, 2007, at 3:46 PM@Apr 11, 2007, Adrian J. Hooke wrote:

> At 02:23 PM 4/11/2007, Stephen Farrell wrote:
>> Ok, then, a competition - post your t-shirt logo design here
>
> In honor of the large number of authors, perhaps a reproduction of  
> David Octavius Hill's painting? --
>
> http://special.lib.gla.ac.uk/hillandadamson/dis.html
>
> ///a
>

--Apple-Mail-3-456463747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><DIV>Heh.=A0 We could combine =
that picture with:</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Salieri:=A0 Too Many =
Notes</DIV><DIV>RFC-Editor:=A0 Too Many Authors</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>- K</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><BR><DIV><DIV>On Apr 11, 2007, =
at 3:46 PM@Apr 11, 2007, Adrian J. Hooke wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"> <FONT =
color=3D"#0000FF">At 02:23 PM 4/11/2007, Stephen Farrell wrote:<BR> =
</FONT><BLOCKQUOTE type=3D"cite" class=3D"cite" cite=3D""><FONT =
color=3D"#0000FF">Ok, then, a competition - post your t-shirt logo =
design here</FONT></BLOCKQUOTE><BR> In honor of the large number of =
authors, perhaps a reproduction of David Octavius Hill's painting? =
--<BR><BR> <A =
href=3D"http://special.lib.gla.ac.uk/hillandadamson/dis.html" =
eudora=3D"autourl"> =
http://special.lib.gla.ac.uk/hillandadamson/dis.html</A><BR><BR> =
///a<BR>  <BR> </BLOCKQUOTE></DIV><BR></BODY></HTML>=

--Apple-Mail-3-456463747--

Date: Wed, 11 Apr 2007 15:46:49 -0700
To: dtn interest <[email-masked]>
From: "Adrian J. Hooke" <[email-masked]>
Subject: [dtn-interest] Re: T-shirt contest
Sender: [email-masked]

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

At 02:23 PM 4/11/2007, Stephen Farrell wrote:
>Ok, then, a competition - post your t-shirt logo design here

In honor of the large number of authors, perhaps a reproduction of David 
Octavius Hill's painting? --

http://special.lib.gla.ac.uk/hillandadamson/dis.html

///a

--=====================_645911441==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<font color="#0000FF">At 02:23 PM 4/11/2007, Stephen Farrell wrote:<br>
<blockquote type=cite class=cite cite="">Ok, then, a competition - post
your t-shirt logo design here</font></blockquote><br>
In honor of the large number of authors, perhaps a reproduction of David
Octavius Hill's painting? --<br><br>
<a href="http://special.lib.gla.ac.uk/hillandadamson/dis.html" eudora="autourl">
http://special.lib.gla.ac.uk/hillandadamson/dis.html</a><br><br>
///a<br>
</body>
<br>
</html>

--=====================_645911441==.ALT--

Date: Wed, 11 Apr 2007 23:14:42 +0100
To: Stephen Farrell <[email-masked]>
From: Lloyd Wood <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: [dtn-interest] Dublin meeting T-shirt contest
Sender: [email-masked]

--=====================_459131328==_
Content-Type: text/plain; charset="us-ascii"

At Wednesday 11/04/2007 22:23 +0100, Stephen Farrell wrote:

>Ok, then, a competition - post your t-shirt logo design here
>before May 10 and I'll arrange to get some made for the Dublin
>meeting. (I guess 2 colour only unless someone wants to chip
>in with some dosh. I've no idea how we'll pick if we get a
>few acceptable designs, but we'll think of something.)

Proposed design attached in ppt and pdf formats.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]> 
--=====================_459131328==_
Content-Type: application/octet-stream; name="wood-dtn-workshop-shirt-design.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wood-dtn-workshop-shirt-design.pdf"

--=====================_459131328==_
Content-Type: application/octet-stream; name="wood-dtn-workshop-shirt-design.ppt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wood-dtn-workshop-shirt-design.ppt"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA
EAAADQAAAAEAAAD+////AAAAAAAAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////9
////FgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAD+/////v///w8A
AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+/////v//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--=====================_459131328==_--

From: Durga Prasad Pandey <[email-masked]>
Subject: Re: [dtn-interest] RFC 4838 Published!
Date: Wed, 11 Apr 2007 17:49:54 -0400
To: [email-masked]
Sender: [email-masked]

Random try, see front and back :D

http://customink.com/cink/r.jsp?E=dpsmiles%40yahoo.com&F=dtn

The catchline could be[again random ideas, some/all pretty bad ;) ]:
Delay the Tolerance
we tolerate all your delays
delaying network tolerance since 1999
Delay? No problem! We tolerate it :)
your networking delays are tolerated

On Apr 11, 2007, at 5:23 PM, Stephen Farrell wrote:

>
> Well done all.
>
> Ok, then, a competition - post your t-shirt logo design here
> before May 10 and I'll arrange to get some made for the Dublin
> meeting. (I guess 2 colour only unless someone wants to chip
> in with some dosh. I've no idea how we'll pick if we get a
> few acceptable designs, but we'll think of something.)
>
> S.
>
> Kevin Fall wrote:
>>     In case you haven't seen already, today RFC 4838 was published:
>>     Delay-Tolerant Networking Architecture
>>     (ftp://ftp.rfc-editor.org/in-notes/rfc4838.txt)
>> I would like to thank everybody who participated in this for  
>> seeing it though to the end!
>> We definitely need some mugs or t-shirts or something...
>> cheers,
>> - Kevin
>> _______________________________________________
>> 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

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] RFC 4838 Published!
Date: Wed, 11 Apr 2007 17:45:43 -0400
Sender: [email-masked]

Yay! Woo-hoo! Great news

On Wed, Apr 11, 2007, Stephen Farrell <[email-masked]> wrote:

>
>Well done all.
>
>Ok, then, a competition - post your t-shirt logo design here
>before May 10 and I'll arrange to get some made for the Dublin
>meeting. (I guess 2 colour only unless someone wants to chip
>in with some dosh. I've no idea how we'll pick if we get a
>few acceptable designs, but we'll think of something.)
>
>S.
>
>Kevin Fall wrote:
>>     
>> 
>> In case you haven't seen already, today RFC 4838 was published:
>> 
>>     Delay-Tolerant Networking Architecture
>> 
>>     (ftp://ftp.rfc-editor.org/in-notes/rfc4838.txt)
>> 
>> I would like to thank everybody who participated in this for seeing it 
>> though to the end!
>> 
>> We definitely need some mugs or t-shirts or something...
>> 
>> cheers,
>> - Kevin
>> _______________________________________________
>> 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: Wed, 11 Apr 2007 22:23:41 +0100
From: Stephen Farrell <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] RFC 4838 Published!
Sender: [email-masked]

Well done all.

Ok, then, a competition - post your t-shirt logo design here
before May 10 and I'll arrange to get some made for the Dublin
meeting. (I guess 2 colour only unless someone wants to chip
in with some dosh. I've no idea how we'll pick if we get a
few acceptable designs, but we'll think of something.)

S.

Kevin Fall wrote:
>     
> 
> In case you haven't seen already, today RFC 4838 was published:
> 
>     Delay-Tolerant Networking Architecture
> 
>     (ftp://ftp.rfc-editor.org/in-notes/rfc4838.txt)
> 
> I would like to thank everybody who participated in this for seeing it 
> though to the end!
> 
> We definitely need some mugs or t-shirts or something...
> 
> cheers,
> - Kevin
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

To: dtn interest <[email-masked]>
From: Kevin Fall <[email-masked]>
Date: Wed, 11 Apr 2007 13:41:42 -0700
Subject: [dtn-interest] RFC 4838 Published!
Sender: [email-masked]

In case you haven't seen already, today RFC 4838 was published:

	Delay-Tolerant Networking Architecture

	(ftp://ftp.rfc-editor.org/in-notes/rfc4838.txt)

I would like to thank everybody who participated in this for seeing  
it though to the end!

We definitely need some mugs or t-shirts or something...

cheers,
- Kevin

Date: Fri, 06 Apr 2007 14:37:57 -0400
From: Nick Goffee <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] dicsussion draft for dtn-interest
Sender: [email-masked]

BBN +1, with the 6-week rollback timer suggested by Jim Snyder.

Regards,
--Nick

Stephen Farrell wrote:
> 
> Ok, so to be sure that we all want to do this, can you
> send a message under this thread in the next week saying:
> 
> +1 I like this, do it
> -1 I don't want to do that
> 
> If (as I suspect) we do want to include the change (all the
> implementers seem to anyway as far as we know), then Keith
> will issue a revised I-D at the end of the next week
> containing the change.
> 
> S.
> 
> PS: This is being a bit formal for an IRTF RG, but since
> we're 1/2 way through the IRSG review for this I think its
> worth doing this way.
> 
> Peter Lovell wrote:
>> Sending for review on wider dtn-interest list ...
>>
>>
>> On Fri, Mar 30, 2007, Stephen Farrell <[email-masked]> wrote:
>>
>>> My summary from the call just now:-
>>>
>>> 1. We seem to have consensus to make Pete's change
>>> 2. Pete to send details of the change to dtn-interest saying its
>>>    planned to be in the next BP spec
>>> 3. Me to start a 1-week timer on that so's everyone has a chance
>>>    to see it
>>> 4. Everyone to say (on dtn-interest) that they like the change
>>> 5. Keith to issue a new BP-spec at the end of the week (so long
>>>    as no-one convinces us otherwise on the list)
>>> 6. Pete to issue the security spec referring to #5
>>> 7. Me to bribe^H^H^H^H^Htalk to the IRSG reviewers about the
>>>    change:-)
>>> 8. No more changes.
>>>
>>> S.
>>
>> Following up on Stephen's meeting summary, here's a "mini I-D"
>> describing the proposal. It has been revised slightly from an earlier
>> one some of you have seen, reflecting a requested change in field
>> ordering (optional field moved before "length"), clarification that the
>> references are pairs of SDNVs, and a textual change in the way bit
>> numbering is described.
>>
>> I think this is the right solution and will allow extension to
>> effectively use the bundle dictionary but with minimal impact elsewhere.
>> A few significant points:-
>>
>> - it's optional for extensions. They don't have to use it
>> - the new BP-spec will describe protocol version 5, so all core
>> implementations will have to change anyhow (there's no interoperability
>> between versions 4 and 5 because of changes in the primary block)
>>
>> I had planned to issue the new draft of Bundle Security Protocol after
>> the meeting but will delay that until the comment period is finished
>> next week. If anyone would like a copy I can send the almost-final
>> version (pending BP-spec) off-list.
>>
>> Regards.....Peter
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

-- 
Nicholas C. Goffee
Internetwork Research Department
BBN Technologies, Cambridge MA
Phone: (617) 873-2438

Date: Thu, 05 Apr 2007 10:50:23 -0400
From: Christopher Small <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] NSDI birds-of-a-feather session, Wednesday 11-April, Cambridge MA
Sender: [email-masked]

I haven't gotten many affirmative responses for the DTN BoF at NSDI next week. 
Please let me know if you plan to attend so I can be sure to order enough beer 
and pretzels. And let me know if you'd like to talk, so I can organize a schedule.

- Chris
-- 
Dr. Christopher Small                         617.873.6261 (vox)
Networking Research        x(){ x|x& };x      617.873.6091 (fax)
BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138

Date: Wed, 04 Apr 2007 23:05:56 +0200
From: Muneeb Ali <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [ACM NSDR'07] Deadline Extended
Sender: [email-masked]

Folks -

  The deadline for ACM NSDR'07 (with SIGCOMM'07) has been extended to 
Fri April 13, 2007 23:59 EDT http://nsdr.dritte.org.

  Do consider submitting your latest greatest works, DTNs are an 
important part of the workshop scope. We are looking forward to having a 
successful event - the first of its kind with SIGCOMM.

Cheers,

Muneeb Ali | http://ali.dritte.org

Date: Mon, 02 Apr 2007 16:35:52 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] Dublin meeting logistics/agenda
Sender: [email-masked]

Couple of updates to that [1]. PPT sessions are getting a bit more
numerous so if we need more slideware bits, we'll probably start to
trim the timings (maybe we ought do that for the 2nd day anyway?)

Also if you want wireless at the meeting, send me your MAC address
(before May 10th please). [2]

Cheers,
S.

[1] http://down.dsg.cs.tcd.ie/misc/DubAgenda.html
[2] http://down.dsg.cs.tcd.ie/misc/DubAgenda.html#Wireless

Stephen Farrell wrote:
> 
> I've put those at [1] and linked from the wiki [2].
> Let me know what's wrong/missing...
> 
> Cheers,
> Stephen.
> 
> [1] http://down.dsg.cs.tcd.ie/misc/DubAgenda.html
> [2] http://www.dtnrg.org/
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Mon, 02 Apr 2007 07:54:53 -0700
From: Scott Burleigh <[email-masked]>
To: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2): [dtn-dev] discussion draft
Sender: [email-masked]

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

Wesley Eddy wrote:
> On Fri, Mar 30, 2007 at 02:18:24PM -0700, Scott Burleigh wrote:
>   
>> [Practically speaking, your 9-byte limit is fine.  Technically, though, 
>> the limit in the BP spec means "any number that can be encoded in 64 
>> bits", and in order to encode a 64-bit integer in an SDNV I think you 
>> actually need 10 bytes.  You can put up to 7 significant bits in each 
>> octet, which means you can get a 63-bit integer into (63 / 7) = 9 
>> octets, but for a 64-bit integer you need the low-order bit of one 
>> additional octet.]
>>     
> Ah, right, thanks for the correction; it's the old SDNV-8/16 scheme
> where 9 bytes gets you exactly 64 value bits.  I guess code that only
> supports 9-byte encodings doesn't have to be as careful when parsing,
> but code that supports 10-byte encodings have to do a little extra
> checking to make sure the value is in-bounds.
>
> I guess the point I wanted to make was not related to the specific
> length, but rather that we just have to be very careful with language
> because making statements about "64-bit SDNVs", when we really mean
> "64-bit SDNV values" could lead to mis-communication and difficult to
> find interop problems.  I think the docs are alright with regards to
> this, but we should also be precise about this in emails, papers, and
> other communication since implementations often draw on a lot more (or
> less) than just the specs alone ...
>   
You're right, Wes, it's easy to lapse into a verbal shorthand that 
introduces ambiguity.  We do need to be careful when we use these terms.
> 64-bit values are right in the area where new-style SDNVs start to get
> less efficient, but this has been discussed a few times here and is
> summed up pretty well in the table in:
> http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt
>   
Yes, this was the (small) downside to moving from the old SDNV-8/16 
scheme to what we're using now.  There are cases that are less 
bit-efficient, but that has seemed a reasonable price to pay for the new 
system's simplicity and flexibility.

Scott

--------------080603080007020209040105
Content-Type: text/html; charset=ISO-8859-1
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">
Wesley Eddy wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">On Fri, Mar 30, 2007 at 02:18:24PM -0700, Scott Burleigh wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">[Practically speaking, your 9-byte limit is fine.  Technically, though, 
the limit in the BP spec means "any number that can be encoded in 64 
bits", and in order to encode a 64-bit integer in an SDNV I think you 
actually need 10 bytes.  You can put up to 7 significant bits in each 
octet, which means you can get a 63-bit integer into (63 / 7) = 9 
octets, but for a 64-bit integer you need the low-order bit of one 
additional octet.]
    </pre>
  </blockquote>
  <pre wrap=""><!---->Ah, right, thanks for the correction; it's the old SDNV-8/16 scheme
where 9 bytes gets you exactly 64 value bits.  I guess code that only
supports 9-byte encodings doesn't have to be as careful when parsing,
but code that supports 10-byte encodings have to do a little extra
checking to make sure the value is in-bounds.

I guess the point I wanted to make was not related to the specific
length, but rather that we just have to be very careful with language
because making statements about "64-bit SDNVs", when we really mean
"64-bit SDNV values" could lead to mis-communication and difficult to
find interop problems.  I think the docs are alright with regards to
this, but we should also be precise about this in emails, papers, and
other communication since implementations often draw on a lot more (or
less) than just the specs alone ...
  </pre>
</blockquote>
You're right, Wes, it's easy to lapse into a verbal shorthand that
introduces ambiguity.&nbsp; We do need to be careful when we use these terms.<br>
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">
64-bit values are right in the area where new-style SDNVs start to get
less efficient, but this has been discussed a few times here and is
summed up pretty well in the table in:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt">http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt</a>
  </pre>
</blockquote>
Yes, this was the (small) downside to moving from the old SDNV-8/16
scheme to what we're using now.&nbsp; There are cases that are less
bit-efficient, but that has seemed a reasonable price to pay for the
new system's simplicity and flexibility.<br>
<br>
Scott<br>
</body>
</html>

--------------080603080007020209040105--

Date: Sat, 31 Mar 2007 12:43:26 -0400
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: dtn interest <[email-masked]>
Subject: Re: [dtn-interest] Re(2): [dtn-dev] discussion draft
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, Mar 30, 2007 at 02:18:24PM -0700, Scott Burleigh wrote:
> 
> [Practically speaking, your 9-byte limit is fine.  Technically, though, 
> the limit in the BP spec means "any number that can be encoded in 64 
> bits", and in order to encode a 64-bit integer in an SDNV I think you 
> actually need 10 bytes.  You can put up to 7 significant bits in each 
> octet, which means you can get a 63-bit integer into (63 / 7) = 9 
> octets, but for a 64-bit integer you need the low-order bit of one 
> additional octet.]
> 

Ah, right, thanks for the correction; it's the old SDNV-8/16 scheme
where 9 bytes gets you exactly 64 value bits.  I guess code that only
supports 9-byte encodings doesn't have to be as careful when parsing,
but code that supports 10-byte encodings have to do a little extra
checking to make sure the value is in-bounds.

I guess the point I wanted to make was not related to the specific
length, but rather that we just have to be very careful with language
because making statements about "64-bit SDNVs", when we really mean
"64-bit SDNV values" could lead to mis-communication and difficult to
find interop problems.  I think the docs are alright with regards to
this, but we should also be precise about this in emails, papers, and
other communication since implementations often draw on a lot more (or
less) than just the specs alone ...

64-bit values are right in the area where new-style SDNVs start to get
less efficient, but this has been discussed a few times here and is
summed up pretty well in the table in:
http://www.ietf.org/internet-drafts/draft-eddy-dtn-sdnv-02.txt

-- 
Wesley M. Eddy
Verizon Federal Network Systems