Subject: [dtn-interest] FW: [core] Desired Transport properties
From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 31 Mar 2010 23:35:38 +0100
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

A relevant mail on the IETF core mailing list, showing an understanding of errors and the costs of not
detecting errors in poorly checked transports.

And the point about headers with fragments is also germane.

Very interesting.

L.

http://sat-net.com/L.Wood/
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Douglas Otis [[email-masked]]
Sent: 31 March 2010 01:16
To: [email-masked]
Subject: [core] Desired Transport properties

The suggestion made at the WG meeting in Anaheim was to use a UDP
overlay having SCTP constructs.  This approach would allow efficient
transfers of various types, where not all features of SCTP would need to
be supported.  Such an SCTP-lite over UDP might omit implicit
associations and multi-homing and still offer many important advantages:

1) Good error detection with the CRC32c algorithm supported by 1 and
10Gb/sec NICs, and modern math coprocessors.  This algorithm is suitable
for use with jumbo frames and supports extremely high volume centralized
services.  When supplementary error detection is appended to objects
contained within poorly checked transports, partial object reception
prior to the checking of enclosed objects imposes complex and expensive
recovery processes, where entire objects will then likely need to be
retransmitted by the application.

In the past, some providers ignored possible errors just to avoid
complex recoveries.  Determining the rarity of these cases proved
difficult, when reporting and logging were also squelched to avoid
equally vexing support issues.  For a transport designed to control
power sub-systems, error detection and recovery is extremely important.
Only when good error detection is directly supported by the transport,
will data integrity and protocol simplicity be assured.

Error detection schemes used by either UDP or TCP fail in as much as 2%
of bus specific bit errors that might be caused by weak drivers or bus
timing skew. With many systems dropping bus parity to reduce cost, bus
specific bit errors remain common, and are likely to have a similar
modulo to that of UDP and TCP checksums.

2) Data Framing (headers included with every packet) greatly assists
data handling.  Reassembly and placement is facilitated by having
headers within the packet that identify the data elements.  Offsets can
be included to facilitate direct placement, even when packets are
received out-of-order.  Low bandwidth mesh network configurations should
not be expected to retain packet ordering.

Past efforts aimed at efficiently implementing RDMA over TCP failed
largely due to the complexities imposed by a lack of data framing, good
error detection, with the subsequent buffering and complex handling this
imposed.  Although direct placement is normally used in many low level
devices, byte stream transports add significant complexities that
prohibit economical use of this resource friendly mode of operation.

3) Minimized retry is achieved by providing explicit acknowledgment of
data objects, in conjunction with selective reliability modes.  For
example, when data is multi-cast in an unreliable fashion, specific
data-element identifiers then permit data recovery over a different path
when desired.

4) Short messages can be bundled to improve throughput and to reduce
packet rates.

5) APIs have been developed which can be adopted to an SCTP-lite
transport.  This API offers a means to map existing TCP or UDP sockets
APIs while also supporting access to new features.  Existing TCP
applications can migrate to this API while having few (if any) changes.
This would ensure that having only UDP support will not impact use of
higher level protocols, such as HTTP.

See http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-22

6) Improved data throughput.  The congestion algorithm used by SCTP, in
conjunction with its explicit acknowledgment, offers a more efficient
use of both low and high bandwidth networks.

7) Anti-spoofing, and DoS resistance has been achieved by the initial
exchange of "cookie" tokens.  These tokens offer spoofing resistance,
and safely establish connections (associations) in fewer exchanges than
what is typically otherwise achieved.

8) Existing procedures and structures to establish secure associations.

Evolution of extensions might include:

9) Implicit Associations and non-blocking socket operations.  These
modes of operation allow servers greater scalability by avoiding
overhead related to establishing a connection.

10) Multi-homing by the transport takes reliability to the next level by
offering rapid fail-over that is router independent.

-Doug

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

Date: Tue, 30 Mar 2010 14:25:15 +0200
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: Workshop proposals IEEE MASS 2010

[We apologize in advance if you receive multiple copies of this message]

-----------------------------------------------------------------------
		         IEEE MASS 2010
          7th IEEE International Conference on Mobile Ad-hoc
                          and Sensor Systems
                     https://mass2010.soe.ucsc.edu/

               November 8-12, 2010 - San Francisco, CA, USA

Co-sponsored by the IEEE Computer Society Technical Commitee on
Distributed Processing and IEEE Computer Society Technical Commitee on
Simulation

-------------------------------------------------------------------------
            ****  Workshop Proposals Deadline:  April 9, 2010  ****
-------------------------------------------------------------------------

IEEE MASS 2010 will be the seventh annual conference on the rapidly
expanding area of multi-hop wireless computing and sensor networking,
and will provide an exciting platform for discussing research vision
of a digitally networked wireless environment.

The MASS Organizing Committee invites proposals for one-day workshops
affiliated with the conference. The workshops will be held prior to, or
after, the main conference.

The purpose of these workshops is to provide a platform for presenting
novel ideas and more specific research areas in a less formal and possibly
more focused way than at the conference itself.  Please visit
http://www.cs.cityu.edu.hk/mass09/workshops.shtml to view information
on workshops held last year at MASS 2009.

Workshops Proposals are solicited in all areas and topics pertaining
to ad-hoc wireless and sensor networking research and applications.

All papers included in the MASS 2010 workshops will appear in the MASS
2010 Proceedings published by IEEE.  We expect all selected workshops
to adhere to a common paper submission and reviewing schedule outlined
below:

Workshop proposals deadline: 	April 9, 2010
Proposals notification: 	April 16, 2010
Manuscripts due: 		June 18, 2010
Acceptance notification: 	August 13, 2010
Camera-ready submission:        September 3, 2010

------------------------------------------------------------------------
Proposal Submission Guidelines:
------------------------------------------------------------------------
Each workshop proposal must include:

1. The name of the workshop
2. The names, addresses, and a short bio (up to 200 words) of the
organizers  (maximum up to three)
3. A brief description (up to 1 page) of the technical issues that the
workshop will address, and the reasons why the workshop is of interest
this time
4. The names of potential participants, such as program committee members
5. Planned format of the workshop, such as number of refereed papers,
keynotes, panels etc.
6. If appropriate, a description of past versions of the workshop,
including:
number of submitted and accepted papers, number of attendees
7. A description of the publicity plan
8. A call for papers
9. The workshop website address

Workshop proposals should be submitted, no later than March 31, 2010
by e-mail (in PDF format) with "MASS 2010 Workshop Proposal" in the
subject, to BOTH MASS 2010 Workshop Co-chairs:

Cédric Westphal       DoCoMo Labs USA
[email-masked]

Christine Pépin 	    DoCoMo Labs USA
[email-masked]

Content-class: urn:content-classes:message
Date: Mon, 29 Mar 2010 10:18:22 -0400
From: "Cole, Robert G Dr CIV USA" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] FW: [manet] REPORT-MIB = WG Document? (UNCLASSIFIED)

Classification: UNCLASSIFIED
Caveats: NONE

Just a note.  This is the MIB I referred to during the meeting last
week.  It provides a front-end to co-resident mibs for the purpose of
generating off-line performance monitoring reports while off-loading the
network from chatty SNMP polls (typical of most snmp perf-monitoring
applications.)  This may be useful for applications running over DTNs.

Thanks,
Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: Thursday, March 25, 2010 2:41 PM
To: MANET IETF
Subject: [AKO Warning - Message fails DKIM verification] [manet]
REPORT-MIB = WG Document?

During the MANET meeting Tuesday we discussed making REPORT-MIB
(http://tools.ietf.org/id/draft-cole-manet-report-mib-02.txt) a WG
document.

I would like to solicit comments on this document and making it a WG
document. Please respond to me and/or the MANET list.

Thanks.
Ian Chakeres
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet
Classification: UNCLASSIFIED
Caveats: NONE

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
To: Hans Kruse <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 25 Mar 2010 17:30:29 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Local/Remote Network Management

--_000_3A5AA67A8B120B48825BFFCF5443856194883990B5NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Likewise, for DTN2, we use SNMP OIDs in addition we currently us SNMP local=
ly (on the machine) as the management application simply because we wanted =
to get something up a running quickly without having to spend resources on =
this aspect of the problem.  Bundles are used to move data from the "remote=
" node to the server/proxy.

Slides for both OU/ION and GRC/DTN2 approaches are on the DTNRG wiki.

http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting

--Will

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
DTN Lab 216-433-2981
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic
From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of Hans Kruse
Sent: Thursday, March 25, 2010 5:21 PM
To: [email-masked]
Subject: [dtn-interest] Local/Remote Network Management

I followed the discussion via audio this morning, and would like to add som=
e (hopefully) clarifying thoughts.  These discussions get complicated becau=
se we re-use Internet protocol terminology, often without the intent to re-=
use all of the actual protocol.

In the case of DING, we re-use the concepts of SNMP OIDs to describe manage=
d objects (including all the nice tools to write and verify MIB structures)=
, but we do not re-use the SNMP protocol. Values of managed objects are ret=
rieved via bundles (no use of SNMP at the managed device - no polling), and=
 the data populates a database in the station we call a gateway.   If you w=
rite a management application that allows you to view and manipulate the da=
ta (graphing, etc.) on that station, you now have an IP-free DTN management=
 implementation.  We have not written such an app, but it would not be too =
hard to do so.

In the case of DING, we explicitly deal with the use case where management =
is done away from the gateway/database station, and we do indeed use SNMP t=
o link the management station and the gateway; we are exploring how much of=
f-the-shelf SNMP management application code we can re-use in this fashion.=
   That is obviously a "remote" management scenario, but there are many oth=
ers possible.

If you are "local" to the managed machine (on the same wire), but the manag=
ed device only speaks bundle protocol, you use the same data retrieval (DIN=
G) and a management application that can work from the DING populated datab=
ase.    Again, the protocol is neutral about how you retrieve the data once=
 it arrives at the gateway.

Hans Kruse, Professor

J. Warren McClure School of Information and Telecommunication Systems

Adjunct Associate Professor of Electrical Engineering and Computer Science

292 Lindley Hall, Ohio University, Athens, OH, 45701

740-593-4891 voice, 740-593-4889 fax

--_000_3A5AA67A8B120B48825BFFCF5443856194883990B5NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Likewise, for DTN2, we use SNMP OIDs in addition we currentl=
y us
SNMP locally (on the machine) as the management application simply because =
we
wanted to get something up a running quickly without having to spend resour=
ces
on this aspect of the problem.&nbsp; Bundles are used to move data from the=
 &#8220;remote&#8221;
node to the server/proxy.&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Slides for both OU/ION and GRC/DTN2 approaches are on the DT=
NRG wiki.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><a href=3D"http://www.dtnrg.org/wiki/DtnBone/JanNetManMeetin=
g">http://www.dtnrg.org/wiki/DtnBone/JanNetManMeeting</a><o:p></o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>--Will<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt;color:#1F497D'>*******=
***********************<br>
William D. Ivancic<br>
Phone 216-433-3494<br>
Fax 216-433-8705<br>
Networking Lab 216-433-2620<br>
DTN Lab 216-433-2981<br>
Mobile 440-503-4892<br>
<a href=3D"http://roland.grc.nasa.gov/~ivancic"><span style=3D'color:blue'>=
http://roland.grc.nasa.gov/~ivancic</span></a></span><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
><o:p></o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> dtn-interest-=
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>Hans
Kruse<br>
<b>Sent:</b> Thursday, March 25, 2010 5:21 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] Local/Remote Network Management<o:p></o:p></=
span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I followed the discussion via audio this morning, and =
would
like to add some (hopefully) clarifying thoughts. &nbsp;These discussions g=
et
complicated because we re-use Internet protocol terminology, often without =
the
intent to re-use all of the actual protocol.<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>In the case of DING, we re-use the concepts of SNMP OI=
Ds to
describe managed objects (including all the nice tools to write and verify =
MIB
structures), but we do not re-use the SNMP protocol. Values of managed obje=
cts
are retrieved via bundles (no use of SNMP at the managed device - no pollin=
g),
and the data populates a database in the station we call a gateway. &nbsp; =
If
you write a management application that allows you to view and manipulate t=
he
data (graphing, etc.) on that station, you now have an IP-free DTN manageme=
nt
implementation. &nbsp;We have not written such an app, but it would not be =
too
hard to do so.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>In the case of DING, we explicitly deal with the use c=
ase
where management is done away from the gateway/database station, and we do
indeed use SNMP to link the management station and the gateway; we are
exploring how much off-the-shelf SNMP management application code we can re=
-use
in this fashion. &nbsp; That is obviously a &quot;remote&quot; management
scenario, but there are many others possible.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>If you are &quot;local&quot; to the managed machine (o=
n the
same wire), but the managed device only speaks bundle protocol, you use the
same data retrieval (DING) and a management application that can work from =
the
DING populated database. &nbsp;&nbsp;&nbsp;Again, the protocol is neutral a=
bout
how you retrieve the data once it arrives at the gateway.<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<div>

<div>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>Hans Kruse, Professor<o:p=
></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>J. Warren McClure School =
of
Information and Telecommunication Systems<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>Adjunct Associate Profess=
or
of Electrical Engineering and Computer Science<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>292 Lindley Hall, Ohio
University, Athens, OH, 45701<o:p></o:p></span></p>

<p style=3D'margin:0in;margin-bottom:.0001pt'><span style=3D'font-size:9.0p=
t;
font-family:"Helvetica","sans-serif";color:black'>740-593-4891 voice,
740-593-4889 fax<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span style=3D'font-size:9.0pt;font-family:"Helvetica"=
,"sans-serif";
color:black'><br>
<br>
</span><o:p></o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_3A5AA67A8B120B48825BFFCF5443856194883990B5NDJSSCC03ndcn_--

From: Hans Kruse <[email-masked]>
To: [email-masked]
Date: Thu, 25 Mar 2010 17:20:59 -0400
Subject: [dtn-interest] Local/Remote Network Management

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

I followed the discussion via audio this morning, and would like to  
add some (hopefully) clarifying thoughts.  These discussions get  
complicated because we re-use Internet protocol terminology, often  
without the intent to re-use all of the actual protocol.

In the case of DING, we re-use the concepts of SNMP OIDs to describe  
managed objects (including all the nice tools to write and verify MIB  
structures), but we do not re-use the SNMP protocol. Values of managed  
objects are retrieved via bundles (no use of SNMP at the managed  
device - no polling), and the data populates a database in the station  
we call a gateway.   If you write a management application that allows  
you to view and manipulate the data (graphing, etc.) on that station,  
you now have an IP-free DTN management implementation.  We have not  
written such an app, but it would not be too hard to do so.

In the case of DING, we explicitly deal with the use case where  
management is done away from the gateway/database station, and we do  
indeed use SNMP to link the management station and the gateway; we are  
exploring how much off-the-shelf SNMP management application code we  
can re-use in this fashion.   That is obviously a "remote" management  
scenario, but there are many others possible.

If you are "local" to the managed machine (on the same wire), but the  
managed device only speaks bundle protocol, you use the same data  
retrieval (DING) and a management application that can work from the  
DING populated database.    Again, the protocol is neutral about how  
you retrieve the data once it arrives at the gateway.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-12--812916167
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">I followed the discussion via =
audio this morning, and would like to add some (hopefully) clarifying =
thoughts. &nbsp;These discussions get complicated because we re-use =
Internet protocol terminology, often without the intent to re-use all of =
the actual protocol.<div><br></div><div>In the case of DING, we re-use =
the concepts of SNMP OIDs to describe managed objects (including all the =
nice tools to write and verify MIB structures), but we do not re-use the =
SNMP protocol. Values of managed objects are retrieved via bundles (no =
use of SNMP at the managed device - no polling), and the data populates =
a database in the station we call a gateway. &nbsp; If you write a =
management application that allows you to view and manipulate the data =
(graphing, etc.) on that station, you now have an IP-free DTN management =
implementation. &nbsp;We have not written such an app, but it would not =
be too hard to do so.</div><div><br></div><div>In the case of DING, we =
explicitly deal with the use case where management is done away from the =
gateway/database station, and we do indeed use SNMP to link the =
management station and the gateway; we are exploring how much =
off-the-shelf SNMP management application code we can re-use in this =
fashion. &nbsp; That is obviously a "remote" management scenario, but =
there are many others possible.</div><div><br></div><div>If you are =
"local" to the managed machine (on the same wire), but the managed =
device only speaks bundle protocol, you use the same data retrieval =
(DING) and a management application that can work from the DING =
populated database. &nbsp;&nbsp;&nbsp;Again, the protocol is neutral =
about how you retrieve the data once it arrives at the =
gateway.</div><div><br></div><div><br></div><div><div> <span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Hans Kruse, Professor</font></p><p style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">J. Warren McClure School of Information and =
Telecommunication Systems</font></p><p style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">Adjunct Associate Professor of Electrical Engineering and =
Computer Science</font></p><p style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">292 Lindley Hall, Ohio University, Athens, OH, =
45701</font></p><p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</font></p></div><br =
class=3D"Apple-interchange-newline"></span> =
</div><br></div></body></html>=

--Apple-Mail-12--812916167--

Date: Thu, 25 Mar 2010 20:26:29 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] RFC 5226, specification required, and experts

On 03/25/2010 06:15 PM, Elwyn Davies wrote:
> Marc Blanchet wrote:
>> Andrew Sullivan a écrit :
>>   
>>> To follow up on what I said in the room today, I think that we need to
>>> use Specification Required even though it causes us to need a
>>> Designated Expert.

Right. I mis-remembered during the earlier part of the meeting.
I guess we can do whatever we did for LTP, which I think ask
the IESG to agree that the RG chairs were the designated experts.
(But I can't find mail on that right now;-)

S.

Date: Thu, 25 Mar 2010 18:15:07 +0000
From: Elwyn Davies <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] RFC 5226, specification required, and experts
Reply-To: [email-masked]

Marc Blanchet wrote:
> Andrew Sullivan a écrit :
>   
>> To follow up on what I said in the room today, I think that we need to
>> use Specification Required even though it causes us to need a
>> Designated Expert.
>>
>> Even though the RG is not part of the IETF and doesn't "talk to" the
>> IESG, there's no reason we can't ask the IESG to appoint an Expert --
>> Experts don't have to be associated with a WG (because they can be
>> used for maintaining a registry even if there's no associated WG).
>> Nicely, the IESG can appoint several experts that make a panel, which
>> can result in having more than one person say things are ready.  The
>> Chairs can also be appointed Experts.  (The reasons to do this will be
>> clear in a moment.)
>>     
>
> to my knowledge, IESG will usually nominate experts that the wg would be 
> happy to... So the rg proposed Experts (such as authors or chairs) shall 
> be ok.
>
> I agree that even if expert is required for Specification Required, we 
> shall include "Specification Required" in our set.
>
> Marc.
>   
Hopefully for an experimental protocol one would get a 'light touch' expert!

I would prefer spec reqd for most things as I said originally if we can
live with the expert.. the only one wehere I have a query is the bundle
processing flags - I am inclined to go RFC required as it affects the
primary block.

Regards,
Elwyn
>   
>> Here's the actual text from 5226:
>>
>> Specification Required - Values and their meanings must be
>>             documented in a permanent and readily available public
>>             specification, in sufficient detail so that interoperability
>>             between independent implementations is possible.  When used,
>>             Specification Required also implies use of a Designated
>>             Expert, who will review the public specification and
>>             evaluate whether it is sufficiently clear to allow
>>             interoperable implementations.  The intention behind
>>             "permanent and readily available" is that a document can
>>             reasonably be expected to be findable and retrievable long
>>             after IANA assignment of the requested value.  Publication
>>             of an RFC is an ideal means of achieving this requirement,
>>             but Specification Required is intended to also cover the
>>             case of a document published outside of the RFC path.  For
>>             RFC publication, the normal RFC review process is expected
>>             to provide the necessary review for interoperability, though
>>             the Designated Expert may be a particularly well-qualified
>>             person to perform such a review.
>>
>> The reason I'm opposed to RFC Required as the criterion is because
>> that would require us to maintain a parallel RFC from any other SDO in
>> case someone wanted a code point.  Having the "same" specification
>> maintained by two different groups is a good way to impede
>> interoperability.  But note in the text above that if you have an RFC,
>> the RFC review is presumed to be sufficient, which means that the
>> expert can just stamp it.  So, if the Chairs are appointed Experts,
>> they can just declare their approval as part of the end of the
>> document cycle.
>>
>> Best,
>>
>> A
>>
>>     
>
>
>   

Date: Thu, 25 Mar 2010 11:00:53 -0700
From: Marc Blanchet <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] RFC 5226, specification required, and experts

Andrew Sullivan a écrit :
> To follow up on what I said in the room today, I think that we need to
> use Specification Required even though it causes us to need a
> Designated Expert.
> 
> Even though the RG is not part of the IETF and doesn't "talk to" the
> IESG, there's no reason we can't ask the IESG to appoint an Expert --
> Experts don't have to be associated with a WG (because they can be
> used for maintaining a registry even if there's no associated WG).
> Nicely, the IESG can appoint several experts that make a panel, which
> can result in having more than one person say things are ready.  The
> Chairs can also be appointed Experts.  (The reasons to do this will be
> clear in a moment.)

to my knowledge, IESG will usually nominate experts that the wg would be 
happy to... So the rg proposed Experts (such as authors or chairs) shall 
be ok.

I agree that even if expert is required for Specification Required, we 
shall include "Specification Required" in our set.

Marc.

> 
> Here's the actual text from 5226:
> 
> Specification Required - Values and their meanings must be
>             documented in a permanent and readily available public
>             specification, in sufficient detail so that interoperability
>             between independent implementations is possible.  When used,
>             Specification Required also implies use of a Designated
>             Expert, who will review the public specification and
>             evaluate whether it is sufficiently clear to allow
>             interoperable implementations.  The intention behind
>             "permanent and readily available" is that a document can
>             reasonably be expected to be findable and retrievable long
>             after IANA assignment of the requested value.  Publication
>             of an RFC is an ideal means of achieving this requirement,
>             but Specification Required is intended to also cover the
>             case of a document published outside of the RFC path.  For
>             RFC publication, the normal RFC review process is expected
>             to provide the necessary review for interoperability, though
>             the Designated Expert may be a particularly well-qualified
>             person to perform such a review.
> 
> The reason I'm opposed to RFC Required as the criterion is because
> that would require us to maintain a parallel RFC from any other SDO in
> case someone wanted a code point.  Having the "same" specification
> maintained by two different groups is a good way to impede
> interoperability.  But note in the text above that if you have an RFC,
> the RFC review is presumed to be sufficient, which means that the
> expert can just stamp it.  So, if the Chairs are appointed Experts,
> they can just declare their approval as part of the end of the
> document cycle.
> 
> Best,
> 
> A
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Thu, 25 Mar 2010 13:40:40 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] RFC 5226, specification required, and experts

To follow up on what I said in the room today, I think that we need to
use Specification Required even though it causes us to need a
Designated Expert.

Even though the RG is not part of the IETF and doesn't "talk to" the
IESG, there's no reason we can't ask the IESG to appoint an Expert --
Experts don't have to be associated with a WG (because they can be
used for maintaining a registry even if there's no associated WG).
Nicely, the IESG can appoint several experts that make a panel, which
can result in having more than one person say things are ready.  The
Chairs can also be appointed Experts.  (The reasons to do this will be
clear in a moment.)

Here's the actual text from 5226:

Specification Required - Values and their meanings must be
            documented in a permanent and readily available public
            specification, in sufficient detail so that interoperability
            between independent implementations is possible.  When used,
            Specification Required also implies use of a Designated
            Expert, who will review the public specification and
            evaluate whether it is sufficiently clear to allow
            interoperable implementations.  The intention behind
            "permanent and readily available" is that a document can
            reasonably be expected to be findable and retrievable long
            after IANA assignment of the requested value.  Publication
            of an RFC is an ideal means of achieving this requirement,
            but Specification Required is intended to also cover the
            case of a document published outside of the RFC path.  For
            RFC publication, the normal RFC review process is expected
            to provide the necessary review for interoperability, though
            the Designated Expert may be a particularly well-qualified
            person to perform such a review.

The reason I'm opposed to RFC Required as the criterion is because
that would require us to maintain a parallel RFC from any other SDO in
case someone wanted a code point.  Having the "same" specification
maintained by two different groups is a good way to impede
interoperability.  But note in the text above that if you have an RFC,
the RFC review is presumed to be sufficient, which means that the
expert can just stamp it.  So, if the Chairs are appointed Experts,
they can just declare their approval as part of the end of the
document cycle.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

Date: Thu, 25 Mar 2010 18:26:14 +0100
From: Anders Lindgren <[email-masked]>
To: "L.Wood" <[email-masked]>
Cc: dtn-interest <[email-masked]>
Subject: Re: [dtn-interest] Posting stuff to materials page now...

--0016e6563aba01350c0482a35850
Content-Type: text/plain; charset=ISO-8859-1

I'm currently looking at those slides, so the link worked for me at least.
Attaching a PDF version of the slides here.

/A

On Thu, Mar 25, 2010 at 6:18 PM,  <[email-masked]> wrote:
> The link to the last slideset - Fun with time - is broken.
> Probably because it's the only powerpoint there, and links to powerpoints tend to get broken, as noted previously.
> So now it's 'fun with Fun with Time'.
>
> Glad to see the rest are pdfs, and unlikely to get lost.
>
> On 25 Mar 2010, at 15:47, Stephen Farrell wrote:
>
>>
>> I've posted the slides I have for now. [1]
>>
>> I don't have all of them (some of which is my fault) so
>> please refresh as the meeting goes on if necessary.
>>
>> Thanks,
>> Stephen.
>>
>> [1] https://datatracker.ietf.org/meeting/77/materials.html#wg-DTNRG
>
> Lloyd Wood
> [email-masked]
> http://sat-net.com/L.Wood
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--0016e6563aba01350c0482a35850
Content-Type: application/pdf; name="funwithtime.pdf"
Content-Disposition: attachment; filename="funwithtime.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g77u4cwm0

--0016e6563aba01350c0482a35850--

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 25 Mar 2010 17:18:35 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked]
Subject: Re: [dtn-interest] Posting stuff to materials page now...

The link to the last slideset - Fun with time - is broken.
Probably because it's the only powerpoint there, and links to powerpoints tend to get broken, as noted previously.
So now it's 'fun with Fun with Time'.

Glad to see the rest are pdfs, and unlikely to get lost.

On 25 Mar 2010, at 15:47, Stephen Farrell wrote:

> 
> I've posted the slides I have for now. [1]
> 
> I don't have all of them (some of which is my fault) so
> please refresh as the meeting goes on if necessary.
> 
> Thanks,
> Stephen.
> 
> [1] https://datatracker.ietf.org/meeting/77/materials.html#wg-DTNRG

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

Date: Thu, 25 Mar 2010 15:47:06 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Posting stuff to materials page now...

I've posted the slides I have for now. [1]

I don't have all of them (some of which is my fault) so
please refresh as the meeting goes on if necessary.

Thanks,
Stephen.

[1] https://datatracker.ietf.org/meeting/77/materials.html#wg-DTNRG

Date: Thu, 25 Mar 2010 10:02:52 +0100
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: Workshop proposals IEEE MASS 2010

[We apologize in advance if you receive multiple copies of this message]

-----------------------------------------------------------------------
		         IEEE MASS 2010
         7th IEEE International Conference on Mobile Ad-hoc
                         and Sensor Systems
                    https://mass2010.soe.ucsc.edu/

              November 8-12, 2010 - San Francisco, CA, USA

Co-sponsored by the IEEE Computer Society Technical Commitee on 
Distributed Processing and IEEE Computer Society Technical Commitee on 
Simulation

-------------------------------------------------------------------------
           ****  Workshop Proposals Deadline:  March 31, 2010  ****
-------------------------------------------------------------------------

IEEE MASS 2010 will be the seventh annual conference on the rapidly
expanding area of multi-hop wireless computing and sensor networking,
and will provide an exciting platform for discussing research vision
of a digitally networked wireless environment.

The MASS Organizing Committee invites proposals for one-day workshops
affiliated with the conference. The workshops will be held prior to, or 
after, the main conference.

The purpose of these workshops is to provide a platform for presenting
novel ideas and more specific research areas in a less formal and possibly
more focused way than at the conference itself.  Please visit
http://www.cs.cityu.edu.hk/mass09/workshops.shtml to view information
on workshops held last year at MASS 2009.

Workshops Proposals are solicited in all areas and topics pertaining
to ad-hoc wireless and sensor networking research and applications.

All papers included in the MASS 2010 workshops will appear in the MASS
2010 Proceedings published by IEEE.  We expect all selected workshops
to adhere to a common paper submission and reviewing schedule outlined
below:

Workshop proposals deadline:    March 31, 2010
Proposals notification:         April 9, 2010
Manuscripts due:                June 18, 2010
Acceptance notification:        August 13, 2010
Camera-ready submission:        September 3, 2010

------------------------------------------------------------------------
Proposal Submission Guidelines:
------------------------------------------------------------------------
Each workshop proposal must include:

1. The name of the workshop
2. The names, addresses, and a short bio (up to 200 words) of the 
organizers  (maximum up to three)
3. A brief description (up to 1 page) of the technical issues that the 
workshop will address, and the reasons why the workshop is of interest 
this time
4. The names of potential participants, such as program committee members
5. Planned format of the workshop, such as number of refereed papers,
keynotes, panels etc.
6. If appropriate, a description of past versions of the workshop, 
including:
number of submitted and accepted papers, number of attendees
7. A description of the publicity plan
8. A call for papers
9. The workshop website address

Workshop proposals should be submitted, no later than March 31, 2010
by e-mail (in PDF format) with "MASS 2010 Workshop Proposal" in the
subject, to BOTH MASS 2010 Workshop Co-chairs:

Cédric Westphal       DoCoMo Labs USA
[email-masked]

Christine Pépin 	    DoCoMo Labs USA
[email-masked]

Date: Thu, 25 Mar 2010 09:01:33 +0000
From: Elwyn Davies <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00
Reply-To: [email-masked]

Hi.

I won't be in Anaheim, so he is my two'pennorth.

Section 2 - Bundle Protocol
- I think you have the right set of registries
- I would go for 'Specification Required'  for all of them except
Primary Bundle Protocol Version where 'RFC Required' is right so the
IETF/IRTF retains control of the protocol as a whole. Also maybe
consider 'RFC Required' for the main Bundle Processing Control flags for
the same reason.
- We should not mention the drafts that are not going to IRSG at the
moment.  They can request allocations as and when they become RFCs
- It would probably be better not mention the drafts that are with the
IRSG at the moment.  It ties them all into a RFC queue bundle.  Again
they can request values in their IANA considerations since they haven't
been approved yet.

s2.1 Bundle Block Types - You could add a Vendor ID block at the top end
if it was thought this might become a standard without major change.

s2.3 Bundle processing control flags.  This field is of indefinite
length. Possibly 19 amd 20 could be made experimental as they fit into
the current  SDNV size.
Consider 'RFC Required' for the policy so that IRTF retains control of
the master protocol.

s2.5 Bundle Status Report flags.  I think I would go with 'Specification
Required'.  It is possible somebody might want extra status reports
which could be defined separately I think.

s2.6 Bundle Status Report Reason Codes.  It is probably overkill but
reserving 255 for potential extension would not harm anything. Go with
'Specification Required'.

s2.7 Bindle Custody Signal Reason Codes. It is probably overkill but
reserving 255 for potential extension would not harm anything. Go with
'Specification Required'.

s3. URI Scheme.  We would have to finish the drafts on naming first. 
Leave this out - it would hold up the current batch of drafts (and
potentially some others).

s4 Mime type.  Why not?  Carrying bundles in emails is envisaged.

s5.Licklider TP.  Seems OK to me.

s6 Security Considerations.  I can't see any additional security hazards
from defining the registries.

Regards,
Elwyn

I think the
Marc Blanchet wrote:
> Stephen Farrell a écrit :
>   
>>     
>>> I'll put all the choices as part of the presentation, so we can pick and
>>> choose.
>>>       
>> That's good. But I don't want you to have to do an IANA
>> tutorial in your slot,
>>     
>
> of course. but a list of possible choices is useful as background info.
>
> I think we should decide the following:
> - for each candidate registry in the draft:
>   1. decide if we want a registry
>   2. if we want to be managed by IANA
>   3. then define the registration policies (rfc5226)
>
>   
>> so again, if people who care would
>> please read at least section 4.1 [1] that'll help us a
>> lot.  http://tools.ietf.org/html/rfc5226#section-4.1
>>     
>
> right!
>
> Marc.
>
>   

Date: Thu, 25 Mar 2010 09:50:15 +0100
From: aviana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE MASS 2010

[We apologize in advance if you receive multiple copies of this message]

======================================================================
                       CALL FOR PAPERS

                       IEEE MASS 2010
     7th IEEE International Conference on Mobile Ad-hoc
                      and Sensor Systems
               https://mass2010.soe.ucsc.edu/

            November 8-12, 2010 - San Francisco, CA, USA

Co-sponsored by the IEEE Computer Society Technical Commitee on 
Distributed Processing and IEEE Computer Society Technical Commitee on 
Simulation

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

IMPORTANT DATES:

Paper Abstract Due:               April 2, 2010
Paper Manuscript Due:             April 9, 2010
Paper Acceptance Notification:    July 12, 2010
Paper Camera-ready Submission:    August 20, 2010

Workshop Proposal Due:             March 31, 2010
Workshop Proposals notification:   April 9, 2010
Workshop Manuscripts due: 	   June 18, 2010
Workshop Acceptance notification:  August 13, 2010
Workshop Camera-ready submission:  September 3, 2010

SCOPE:

The 7th IEEE International Conference on Mobile Ad-hoc and Sensor 
Systems (IEEE MASS 2010) is to be held in San Francisco, CA between 
November 8-12, 2010. Wireless ad-hoc communication has applications in a 
variety of environments, such as conferences, hospitals, battlefields 
and disaster-recovery/rescue operations, and is also being actively 
investigated as an alternative paradigm for Internet connectivity in 
both urban and rural areas. Wireless sensor and actuator networks are 
also being deployed for enhancing industrial control processes and 
supply-chains, and for various forms of environmental monitoring. The 
IEEE MASS 2010 aims at addressing advances in research on multi-hop 
ad-hoc and sensor networks, covering topics ranging from technology 
issues to applications and test-bed development. Please keep checking 
the IEEE MASS 2010 web-space for more information and regular updates.

TOPICS OF INTEREST:

Original, unpublished contributions are solicited in all aspects of
(mobile) ad-hoc networks and wireless sensor networks (WSN), systems and
applications. Topics include, but are not limited to:

*  Vehicular networks and protocols
*  Wireless mesh networks and cognitive networks
*  MAC layer design for ad-hoc networks and WSNs
*  MAC protocols (802.11, 802.15.4, UWB)
*  Multi-channel, multi-radio and MIMO technologies
*  Cross layer design and optimization
*  P2P, overlay, and content distribution architectures for ad-hoc and
sensor networks
*  Delay tolerant networks and opportunistic networking
*  Power-aware architectures, algorithms and protocols design
*  Clustering, topology control, coverage and connectivity
*  Routing protocols (unicast, multicast, broadcast, geocast)
*  Data transport and management in WSNs
*  Data gathering, fusion, and dissemination in WSNs
*  Localization and synchronization in WSNs
*  Cooperative sensing in WSNs
*  Capacity planning and admission control in ad-hoc and sensor networks
*  Handoff / mobility management and seamless internetworking
*  Resource management and wireless QoS Provisioning
*  Key management, trust establishment in wireless networks
*  Security and privacy issues in ad hoc and sensor networks
*  Reliability, resiliency and fault tolerance techniques
*  Security, privacy issues in vehicular, DTNs, and mesh networks
*  Operating systems and middleware support
*  Novel applications and architectures for WSNs
*  Modeling, analysis and performance evaluation
*  Measurements and experience from experimental systems and
test-beds

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

GENERAL CO-CHAIRS

Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS

Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS

- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

- Systems, and applications
Chenyang Lu, Washington Unviersity in St. Louis

- Algorithms and theory
Dong Xuan, Ohio State University

- Reliability, security and privacy
Radha Poovendran, University of Washington

WORKSHOP CO-CHAIRS

Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR

Rajeev Koodli, Starent Networks
Marcelo Dias Amorim, LIP 6, Universite' Paris 6

WEB CHAIR

Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR

Zhen Jiang, West Chester University

PUBLICATION CHAIR

Dajin Wang, Montclair State University

PUBLICITY CHAIR

Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS

Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR

Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING

Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION

Dave Cavalcanti, Phillips Research

From: Stephen Farrell <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 2010 00:39:23 -0700
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-bundle-security

Excellent. We'll post changes when we sort the IANA stuff,
Thanks,
S.

On 25 Mar 2010, at 00:34, Juergen Schoenwaelder <[email-masked] 
 > wrote:

> On Thu, Mar 25, 2010 at 12:16:15AM +0100, Stephen Farrell wrote:
>
>>> a) I am wondering what the following statement means in practice:
>>>
>>>     Implementations SHOULD NOT be very strict in how they process  
>>> X.509
>>>     though, for example, it would probably not be correct to  
>>> insist on
>>>     Certificate Revocation List (CRL) checking in many DTN contexts.
>>>
>>>   This sentence sounds like asking for implementations to be lenient
>>>   at the implementors choice while this is probably not a good idea
>>>   security wise. For example, does this "SHOULD NOT be very strict"
>>>   imply that implementations may accept wildcard certificates and do
>>>   things as they might seem fit? There are many details when it  
>>> comes
>>>   to certificate processing and I believe this deserves a more
>>>   detailed discussion and "SHOULD NOT be very strict in how they
>>>   (implementations) process X.509" seems a too cheap way out.
>>
>> I guess we should restate the paragraph, its a bit vague. First  
>> though,
>> its not a security problem. RFC 5280 makes revocation checking  
>> optional,
>> and that's ok in some contexts. In our context we simply might not be
>> able to access relevant CRLs or OCSP responders. How about if we
>> rewrite it as follows:
>>
>>   RFC 5280 does not insist that implementations include revocation
>>   checking. In the context of a DTN, it is reasonably likely that
>>   some nodes would not be able to use revocation checking services
>>   (either CRLs or OCSP) and deployments SHOULD take this into
>>   account when planning any public key infrastructure to support
>>   this specification.
>
> I am fine with the proposed new text. (However, I still believe that
> the original text was a security problem since it said "SHOULD NOT be
> very strict in how they process X.509" and the CRL checking was only
> mentioned as "for example", leaving the door very wide open.)
>
>>> b) Should the text in the security considerations discuss the fact
>>>   that notifications may be generated if security processing fails,
>>>   thus potentially revealing something about where security
>>>   processing takes place or providing a test mechanism?
>>
>> Sure. How about:
>>
>>   If a security target were to generate reports in the event that
>>   some security validation step fails, then that might leak  
>> information
>>   about the internal structure or policies of the DTN containing the
>>   security target. This is sometimes considered bad security practice
>>   so SHOULD only be done with care.
>
> OK
>
>>> Should there
>>>   be any text in the security considerations concerning any DoS
>>>   possibilities due to heavy security processing caused by
>>>   e.g. replays?
>>
>> In this case, I'd say not. I don't think BSP is different from any
>> other crypto protocol in this respect. If there were a DTN specific
>> issue, I'd have no problem adding something, but I don't think there
>> is. (RFC 5050 has some mention of DoS in a DTN context generally as
>> well.)
>
> It is not clear to me whether BSP is similar to other crypto protocols
> in this respect. BSP is very flexible allowing hop-by-hop and
> end-to-end security and pretty much anything in between and it is not
> so clear to me whether the flexibility opens interesting new ways to
> mount DoS attacks. But since this is not standards-track work, it is
> probably OK to leave this out.
>
> With these changes in place, I am changing my vote to 'Ready to
> publish'.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

Date: Wed, 24 Mar 2010 23:16:15 +0000
From: Stephen Farrell <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-bundle-security

Hi Juergen,

Thanks for the review.

On 03/22/2010 01:57 PM, Juergen Schoenwaelder wrote:
> On Wed, Feb 24, 2010 at 05:27:57PM +0100, Elwyn Davies wrote:
>> Dear IRSG Memeber,
>>
>> The DTN RG I-D: draft-irtf-dtnrg-bundle-security has
>> completed IRSG review.
>> The revised version of the I-D (Version 15) which incorporates the comments is
>> now available at:
>> http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security
>> Andrei Gurtov who has performed the IRSG review and the DTN RG have
>> approved the revised I-D to be progressed for publication.
>>
>> The IRSG review is available from the IRTF tracker web page at:
>> http://trac.tools.ietf.org/group/irtf/trac/ticket/31
>>
>> Please consider this email as the start of a four week IRSG poll. The
>> deadline for this poll is : Wednesday, March 24th, 2010.
>>
>> Please use one of the poll responses defined below.
>> The possible poll responses are:
>>
>>     o  'Ready to publish' -- requires a thorough read and reasonably
>>         detailed review
>>
>>     o  'Not ready to publish' -- requires a thorough read, reasonably
>>        detailed review, and actionable comments.
>>
>>     o  'No objection' -- I don't object if this document goes forward;
>>        I've read the document (perhaps quickly); I have some small
>>        comments which are not show stoppers; I don't have great
>>        expertise in the area.
>>
>>     o  'Request more time to review' -- a commitment to provide a
>>        thorough review in a specified period of time.
> 
> I have read the document (well written but takes some effort to go
> through) and 

I agree. The credit for writing all recent versions goes to Peter L.
(As an aside IRSG review is really supposed to just address this
aspect, but I think your comments below are worth addressing.)

> like to raise a two security related questions before
> this moves forward. The first one I really like to get an answered
> and thus I throw in a 'Not ready to publish'.
> 
> a) I am wondering what the following statement means in practice:
> 
>      Implementations SHOULD NOT be very strict in how they process X.509
>      though, for example, it would probably not be correct to insist on
>      Certificate Revocation List (CRL) checking in many DTN contexts.
> 
>    This sentence sounds like asking for implementations to be lenient
>    at the implementors choice while this is probably not a good idea
>    security wise. For example, does this "SHOULD NOT be very strict"
>    imply that implementations may accept wildcard certificates and do
>    things as they might seem fit? There are many details when it comes
>    to certificate processing and I believe this deserves a more
>    detailed discussion and "SHOULD NOT be very strict in how they
>    (implementations) process X.509" seems a too cheap way out.

I guess we should restate the paragraph, its a bit vague. First though,
its not a security problem. RFC 5280 makes revocation checking optional,
and that's ok in some contexts. In our context we simply might not be
able to access relevant CRLs or OCSP responders. How about if we
rewrite it as follows:

   RFC 5280 does not insist that implementations include revocation
   checking. In the context of a DTN, it is reasonably likely that
   some nodes would not be able to use revocation checking services
   (either CRLs or OCSP) and deployments SHOULD take this into
   account when planning any public key infrastructure to support
   this specification.

> b) Should the text in the security considerations discuss the fact
>    that notifications may be generated if security processing fails,
>    thus potentially revealing something about where security
>    processing takes place or providing a test mechanism? 

Sure. How about:

   If a security target were to generate reports in the event that
   some security validation step fails, then that might leak information
   about the internal structure or policies of the DTN containing the
   security target. This is sometimes considered bad security practice
   so SHOULD only be done with care.

> Should there
>    be any text in the security considerations concerning any DoS
>    possibilities due to heavy security processing caused by
>    e.g. replays?

In this case, I'd say not. I don't think BSP is different from any
other crypto protocol in this respect. If there were a DTN specific
issue, I'd have no problem adding something, but I don't think there
is. (RFC 5050 has some mention of DoS in a DTN context generally as
well.)

> 
> Some editorial nits:
> 
> - p15: s/the the/the/
> 
> - p19: s/dtn/DTN/
> 
> - p22: s/folowing/following/
> 
> - p24: s/defintion/definition/

Thanks,
Stephen.

> 
> /js
> 

From: "Hylton, Alan G. (GRC-RHN0)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 24 Mar 2010 15:13:45 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] IETF Testers Needed

--_000_3A5AA67A8B120B48825BFFCF5443856194881199E2NDJSSCC03ndcn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Howdy,

We need testers to see if the IPN naming support in DTN2 works or not. If a=
nyone at the IETF is interested, we'd like people to bounce some bundles th=
rough NASA GRC's DTNBONE box. using either DTN naming or IPN naming.

The GRC Bone is at 192.55.90.165 on port 5017. It is both TCP and UDP ready=
.

If you would like to receive data through this node, then  you will need to=
 send us your routing info (IP, EID, etc).

If you are willing to give it a shot, ask Joe Ishac to set up a route for y=
ou at [email-masked]<mailto:[email-masked]>.

Thanks,

Alan Hylton

--_000_3A5AA67A8B120B48825BFFCF5443856194881199E2NDJSSCC03ndcn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div>Howdy,</div>
<div>&nbsp;</div>
<div>We need testers to see if the IPN naming support in DTN2 works or not.=
 If anyone at the IETF is interested, we&#8217;d like people to bounce some=
 bundles through NASA GRC&#8217;s DTNBONE box. using either DTN naming or I=
PN naming.</div>
<div>&nbsp;</div>
<div>The GRC Bone is at 192.55.90.165 on port 5017. It is both TCP and UDP =
ready.</div>
<div>&nbsp;</div>
<div>If you would like to receive data through this node, then&nbsp; you wi=
ll need to send us your routing info (IP, EID, etc).</div>
<div>&nbsp;</div>
<div>If you are willing to give it a shot, ask Joe Ishac to set up a route =
for you at <a href=3D"mailto:[email-masked]"><font color=3D"#0000FF"><u>ji=
[email-masked]</u></font></a>.</div>
<div>&nbsp;</div>
<div>Thanks,</div>
<div>&nbsp;</div>
<div>Alan Hylton</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_3A5AA67A8B120B48825BFFCF5443856194881199E2NDJSSCC03ndcn_--

Date: Wed, 24 Mar 2010 02:47:06 -0500
From: [email-masked]
To: "Stephen Farrell" <[email-masked]>
Importance: Normal
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] Warning of end of poll for DRN RG documents

I'm voting "Ready to publish" for the poll.

>>> Dear IRSG Member,
>>>
>>> The DTN RG submitted five documents to the IRSG for consideration
>>> almost 4
>>> weeks
>>> ago.  The polls for these documents all end tomorrow.
>>>
>>> The IRSG reviews are available from the IRTF tracker web page at:
>>> http://trac.tools.ietf.org/group/irtf/trac/ticket/30
>>> through
>>> http://trac.tools.ietf.org/group/irtf/trac/ticket/34
>>>
>>> There has been a limited response to the poll (plaudits to Juergen
>>> Schoenwaelder).  The DTN RG would appreciate it if you can get your
>>> responses in
>>> so we can progress these documents.
>>>
>>> Please use one of the poll responses defined below.
>>> The possible poll responses are:
>>>
>>>     o  'Ready to publish' -- requires a thorough read and reasonably
>>>         detailed review
>>>
>>>     o  'Not ready to publish' -- requires a thorough read, reasonably
>>>        detailed review, and actionable comments.
>>>
>>>     o  'No objection' -- I don't object if this document goes forward;
>>>        I've read the document (perhaps quickly); I have some small
>>>        comments which are not show stoppers; I don't have great
>>>        expertise in the area.
>>>
>>>     o  'Request more time to review' -- a commitment to provide a
>>>        thorough review in a specified period of time.
>>>
>>> The most relevant rule is that "At least two other IRSG members
>>> (besides
>>> the
>>> one sponsoring the document) need to vote 'ready to publish' for the
>>> document to move forward."
>>>
>>> So.. Please review and submit your vote.
>>>
>>> -Elwyn Davies
>>> Document Shepherd for the I-D
>>>
>>>
>>>
>>> _______________________________________________
>>> dtn-interest mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Wed, 24 Mar 2010 02:19:07 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Slides please...

Hi all,

If you've a speaking slot at Thursday's session please
send me your slides before 5pm tomorrow (pacific time)
so I can put them on the meeting materials site in
time for remote participants to see them.

Also, if you're planning to attend remotely, no harm
to let me know so I know to keep people at the mic
doing the right thing. The overall meeting agenda on
the IETF tools site [1] has links to the audio stream,
jabber room etc. Just search down for dtnrg.

Thanks,
Stephen.

[1] http://tools.ietf.org/agenda/77/

Date: Tue, 23 Mar 2010 20:26:39 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] Warning of end of poll for DRN RG documents

I think just sending your vote/comment to the IRSG list
and cc the dtn-interest list is probably the way to do
this and Elwyn can modify the tracker when we're done.

S.

On 03/23/2010 06:35 PM, [email-masked] wrote:
> Elwyn,
> 
> I'm not sure if I did the right thing.
> 
> After reviewing drafts I followed one of the URLs and there I "Resolved to
> Publish".
> 
> Was that the poll? If not, what is the URL for the poll?
> 
> I thought that I had voted on this a couple of weeks back but perhaps I
> was sidetracked.
> 
>> Dear IRSG Member,
>>
>> The DTN RG submitted five documents to the IRSG for consideration almost 4
>> weeks
>> ago.  The polls for these documents all end tomorrow.
>>
>> The IRSG reviews are available from the IRTF tracker web page at:
>> http://trac.tools.ietf.org/group/irtf/trac/ticket/30
>> through
>> http://trac.tools.ietf.org/group/irtf/trac/ticket/34
>>
>> There has been a limited response to the poll (plaudits to Juergen
>> Schoenwaelder).  The DTN RG would appreciate it if you can get your
>> responses in
>> so we can progress these documents.
>>
>> Please use one of the poll responses defined below.
>> The possible poll responses are:
>>
>>     o  'Ready to publish' -- requires a thorough read and reasonably
>>         detailed review
>>
>>     o  'Not ready to publish' -- requires a thorough read, reasonably
>>        detailed review, and actionable comments.
>>
>>     o  'No objection' -- I don't object if this document goes forward;
>>        I've read the document (perhaps quickly); I have some small
>>        comments which are not show stoppers; I don't have great
>>        expertise in the area.
>>
>>     o  'Request more time to review' -- a commitment to provide a
>>        thorough review in a specified period of time.
>>
>> The most relevant rule is that "At least two other IRSG members (besides
>> the
>> one sponsoring the document) need to vote 'ready to publish' for the
>> document to move forward."
>>
>> So.. Please review and submit your vote.
>>
>> -Elwyn Davies
>> Document Shepherd for the I-D
>>
>>
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 23 Mar 2010 13:35:29 -0500
From: [email-masked]
To: "Elwyn Davies" <[email-masked]>
Importance: Normal
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] Warning of end of poll for DRN RG documents

Elwyn,

I'm not sure if I did the right thing.

After reviewing drafts I followed one of the URLs and there I "Resolved to
Publish".

Was that the poll? If not, what is the URL for the poll?

I thought that I had voted on this a couple of weeks back but perhaps I
was sidetracked.

> Dear IRSG Member,
>
> The DTN RG submitted five documents to the IRSG for consideration almost 4
> weeks
> ago.  The polls for these documents all end tomorrow.
>
> The IRSG reviews are available from the IRTF tracker web page at:
> http://trac.tools.ietf.org/group/irtf/trac/ticket/30
> through
> http://trac.tools.ietf.org/group/irtf/trac/ticket/34
>
> There has been a limited response to the poll (plaudits to Juergen
> Schoenwaelder).  The DTN RG would appreciate it if you can get your
> responses in
> so we can progress these documents.
>
> Please use one of the poll responses defined below.
> The possible poll responses are:
>
>     o  'Ready to publish' -- requires a thorough read and reasonably
>         detailed review
>
>     o  'Not ready to publish' -- requires a thorough read, reasonably
>        detailed review, and actionable comments.
>
>     o  'No objection' -- I don't object if this document goes forward;
>        I've read the document (perhaps quickly); I have some small
>        comments which are not show stoppers; I don't have great
>        expertise in the area.
>
>     o  'Request more time to review' -- a commitment to provide a
>        thorough review in a specified period of time.
>
> The most relevant rule is that "At least two other IRSG members (besides
> the
> one sponsoring the document) need to vote 'ready to publish' for the
> document to move forward."
>
> So.. Please review and submit your vote.
>
> -Elwyn Davies
> Document Shepherd for the I-D
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

Date: Tue, 23 Mar 2010 16:52:59 +0000
From: Elwyn Davies <[email-masked]>
To: Internet Research Steering Group <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] Warning of end of poll for DRN RG documents

Dear IRSG Member,

The DTN RG submitted five documents to the IRSG for consideration almost 4 weeks
ago.  The polls for these documents all end tomorrow.

The IRSG reviews are available from the IRTF tracker web page at:
http://trac.tools.ietf.org/group/irtf/trac/ticket/30
through
http://trac.tools.ietf.org/group/irtf/trac/ticket/34

There has been a limited response to the poll (plaudits to Juergen
Schoenwaelder).  The DTN RG would appreciate it if you can get your responses in
so we can progress these documents.

Please use one of the poll responses defined below.
The possible poll responses are:

    o  'Ready to publish' -- requires a thorough read and reasonably
        detailed review

    o  'Not ready to publish' -- requires a thorough read, reasonably
       detailed review, and actionable comments.

    o  'No objection' -- I don't object if this document goes forward;
       I've read the document (perhaps quickly); I have some small
       comments which are not show stoppers; I don't have great
       expertise in the area.

    o  'Request more time to review' -- a commitment to provide a
       thorough review in a specified period of time.

The most relevant rule is that "At least two other IRSG members (besides the
one sponsoring the document) need to vote 'ready to publish' for the
document to move forward."

So.. Please review and submit your vote.

-Elwyn Davies
Document Shepherd for the I-D

Date: Mon, 22 Mar 2010 14:27:11 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Stephen Farrell wrote:
> Thanks for working on this guys.

I must point out that Marc did *all* of the work!

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Mon, 22 Mar 2010 10:11:59 -0700
From: Marc Blanchet <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Stephen Farrell a écrit :
> 
> 
>> I'll put all the choices as part of the presentation, so we can pick and
>> choose.
> 
> That's good. But I don't want you to have to do an IANA
> tutorial in your slot,

of course. but a list of possible choices is useful as background info.

I think we should decide the following:
- for each candidate registry in the draft:
  1. decide if we want a registry
  2. if we want to be managed by IANA
  3. then define the registration policies (rfc5226)

> so again, if people who care would
> please read at least section 4.1 [1] that'll help us a
> lot.  http://tools.ietf.org/html/rfc5226#section-4.1

right!

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Mon, 22 Mar 2010 17:06:54 +0000
From: Stephen Farrell <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

On 03/22/2010 03:28 PM, Marc Blanchet wrote:
>> I think there used to be a handy web page somewhere
>> explaining the various options but I can't find it
>> right now. Anyone know of such a site?
> 
> rfc5226

Thanks. I guess section 4.1 [1] has the standard menu
of choices and I don't think we want to define new
options here, so if folks who are interested can
familiarise themselves with that couple of pages before
we meet that'd be good.

> I'll put all the choices as part of the presentation, so we can pick and
> choose.

That's good. But I don't want you to have to do an IANA
tutorial in your slot, so again, if people who care would
please read at least section 4.1 [1] that'll help us a
lot.

Stephen.

[1] http://tools.ietf.org/html/rfc5226#section-4.1

> 
> Marc.
> 
>>
>> Cheers,
>> S.
> 
> 

Date: Mon, 22 Mar 2010 08:28:44 -0700
From: Marc Blanchet <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Stephen Farrell a écrit :
> Thanks for working on this guys.
> 
> On 03/22/2010 02:32 PM, Marc Blanchet wrote:
>> Daniel Ellard a écrit :
>>> Thank you for writing this up.  This is going to be very useful.
>>>
> 
>>> - Something I'd really like to see is a description of how
>>> new numbers get assigned, preferably via IANA,
>> well, to me, that is the core discussion to happen during our meeting 
>> this week.
>>
> 
> Indeed. Agreeing on the set of registries and the
> (possibly varying) update rules for each is what we
> need to get done.
> 
> I think there used to be a handy web page somewhere
> explaining the various options but I can't find it
> right now. Anyone know of such a site?

rfc5226

I'll put all the choices as part of the presentation, so we can pick and 
choose.

Marc.

> 
> Cheers,
> S.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Mon, 22 Mar 2010 15:24:13 +0000
From: Stephen Farrell <[email-masked]>
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Thanks for working on this guys.

On 03/22/2010 02:32 PM, Marc Blanchet wrote:
> Daniel Ellard a écrit :
>> Thank you for writing this up.  This is going to be very useful.
>>

>> - Something I'd really like to see is a description of how
>> new numbers get assigned, preferably via IANA,
> 
> well, to me, that is the core discussion to happen during our meeting 
> this week.
> 

Indeed. Agreeing on the set of registries and the
(possibly varying) update rules for each is what we
need to get done.

I think there used to be a handy web page somewhere
explaining the various options but I can't find it
right now. Anyone know of such a site?

Cheers,
S.

Date: Mon, 22 Mar 2010 07:32:46 -0700
From: Marc Blanchet <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Daniel Ellard a écrit :
> Thank you for writing this up.  This is going to be very useful.
> 
> A few quick notes:
> 
> - The big tables on pages 5 and 10 are too big! 

I know they are not great looking now. well, that was -00 ;-)
It is actually the xml2rfc renderer who is not doing a very good job in 
allocating columns size by default for this case. I'll add the optional 
attribute to specify column size so it should be better in the next rev.

> None of the
> columns is wide enough to fit each field.  Maybe a list
> would be better than a table, or just shorten the names of
> the I-D's to reference numbers.

good point, I'll look into this.

> 
> - In the "Block Processing Control Flags Registry" table:
> bit 0 is specified twice (second time as "Block contains an
> EID-reference field")

thanks. was a copy/paste. last one should be 6.

> 
> - The tables should be numbered.
> 

ok.

> - Bit positions: is "right to left" the right way to specify
> this?  (not lsb->msb?)

good question. I have to reread the RFCs, I thought I copied the text 
from the RFC, but I'll have to verify. My policy has been to copy 
whatever text in the RFC.

> 
> - Something I'd really like to see is a description of how
> new numbers get assigned, preferably via IANA,

well, to me, that is the core discussion to happen during our meeting 
this week.

  but at least
> through some clearinghouse with a procedure that doesn't
> require writing a new I-D, but does have some sort of sanity
> check. 

that looks like "Expert Review".

Think however that different registries may have different policies. 
Some fields really need wg reviews, some just need someone to verify the 
request is not fishy. It is sometimes related to the size of the field 
or to impact of a new assignment in a field.

Marc.

  Something like RFC4340 Section 19.9, but tailored
> for our needs.
> 
> -Dan
> 
> Marc Blanchet wrote:
>> Hello,
>>   as suggested by Stephen, here is a first version of an attempt to 
>> request IANA to create protocol registries for DTN. It contains a more 
>> exhaustive list of potential registries than the current dtnrg adhoc 
>> registry on purpose, so that no registries are forgotten. This draft is 
>> a strawman.
>>
>> This draft will be presented during dtnrg meeting this week.
>>
>> Marc.
>>
>> ==============
>>
>> Filename:	 draft-blanchet-dtnrg-iana-registries
>> Revision:	 00
>> Title:		 Delay-Tolerant Networks (DTN) IANA Registries
>> Creation_date:	 2010-03-22
>> WG ID:		 Independent Submission
>> Number_of_pages: 14
>>
>> Abstract:
>> The DTNRG research group has defined many protocols such as Bundle
>> Protocol and Licklider.  The specifications of these protocols
>> contain fields that are subject to a registry.  For the purpose of
>> its research work, the group created adhoc registries[DTNRGREG].  As
>> the specifications are stable and have multiple interoperable
>> implementations, the group would like to handoff the registries to
>> IANA for official custidy.  This document describes the actions
>> needed to be executed by IANA.
>>  
>>
>>
> 
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Mon, 22 Mar 2010 10:15:18 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Marc Blanchet <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Thank you for writing this up.  This is going to be very useful.

A few quick notes:

- The big tables on pages 5 and 10 are too big!  None of the
columns is wide enough to fit each field.  Maybe a list
would be better than a table, or just shorten the names of
the I-D's to reference numbers.

- In the "Block Processing Control Flags Registry" table:
bit 0 is specified twice (second time as "Block contains an
EID-reference field")

- The tables should be numbered.

- Bit positions: is "right to left" the right way to specify
this?  (not lsb->msb?)

- Something I'd really like to see is a description of how
new numbers get assigned, preferably via IANA, but at least
through some clearinghouse with a procedure that doesn't
require writing a new I-D, but does have some sort of sanity
check.  Something like RFC4340 Section 19.9, but tailored
for our needs.

-Dan

Marc Blanchet wrote:
> Hello,
>   as suggested by Stephen, here is a first version of an attempt to 
> request IANA to create protocol registries for DTN. It contains a more 
> exhaustive list of potential registries than the current dtnrg adhoc 
> registry on purpose, so that no registries are forgotten. This draft is 
> a strawman.
> 
> This draft will be presented during dtnrg meeting this week.
> 
> Marc.
> 
> ==============
> 
> Filename:	 draft-blanchet-dtnrg-iana-registries
> Revision:	 00
> Title:		 Delay-Tolerant Networks (DTN) IANA Registries
> Creation_date:	 2010-03-22
> WG ID:		 Independent Submission
> Number_of_pages: 14
> 
> Abstract:
> The DTNRG research group has defined many protocols such as Bundle
> Protocol and Licklider.  The specifications of these protocols
> contain fields that are subject to a registry.  For the purpose of
> its research work, the group created adhoc registries[DTNRGREG].  As
> the specifications are stable and have multiple interoperable
> implementations, the group would like to handoff the registries to
> IANA for official custidy.  This document describes the actions
> needed to be executed by IANA.
>  
> 
> 

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Mon, 22 Mar 2010 06:33:37 -0700
From: Marc Blanchet <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] draft-blanchet-dtnrg-iana-registries-00

Hello,
  as suggested by Stephen, here is a first version of an attempt to 
request IANA to create protocol registries for DTN. It contains a more 
exhaustive list of potential registries than the current dtnrg adhoc 
registry on purpose, so that no registries are forgotten. This draft is 
a strawman.

This draft will be presented during dtnrg meeting this week.

Marc.

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

Filename:	 draft-blanchet-dtnrg-iana-registries
Revision:	 00
Title:		 Delay-Tolerant Networks (DTN) IANA Registries
Creation_date:	 2010-03-22
WG ID:		 Independent Submission
Number_of_pages: 14

Abstract:
The DTNRG research group has defined many protocols such as Bundle
Protocol and Licklider.  The specifications of these protocols
contain fields that are subject to a registry.  For the purpose of
its research work, the group created adhoc registries[DTNRGREG].  As
the specifications are stable and have multiple interoperable
implementations, the group would like to handoff the registries to
IANA for official custidy.  This document describes the actions
needed to be executed by IANA.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Fri, 19 Mar 2010 18:14:33 +0000
From: Stephen Farrell <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [Fwd: [theONE] The ONE v.1.4]

Hi Joerg,

Does that mean that ONE now has implementations of
both prophet and maxprop such that one could do
pretty fair comparisons in a set of simulation runs?

If so, are any such results published somewhere?

One of the issues with routing papers I always find
hard is to understand how many of the comparisons are
really fair, even with the authors being as fair and
honest as they can be.

S.

Date: Fri, 19 Mar 2010 07:28:03 +0200
From: Joerg Ott <[email-masked]>
To: Delay Tolerant Networking Interest List <[email-masked]>
Subject: [dtn-interest] [Fwd: [theONE] The ONE v.1.4]

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

--------------040909000905000707000200
Content-Type: message/rfc822;
 name="[theONE] The ONE v.1.4.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="[theONE] The ONE v.1.4.eml"

Date: Fri, 19 Mar 2010 01:16:09 +0200
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= <[email-masked]>
To: [email-masked]
Subject: [theONE] The ONE v.1.4
Sender: [email-masked]

Hi all,

We have released a new version of the ONE (1.4.0) and it's available for
download at the homepage: http://www.netlab.tkk.fi/tutkimus/dtn/theone/

This release is a merge of different development branches so there is a 
good chance that something does not work as expected. So, pay attention 
to the results, even more than usual, when trying this out. And if you 
find bugs, please let us know so that we can fix them.

New features/enhancements/changes include the following:

- Added the possibility for each node having multiple interfaces
  * Requires changes to the configuration files, see default_settings.txt
- New/improved routing algorithms
  * added parametrization for MaxProp (default alpha=1)
  * added Prophet and Maxprop routing algorithm versions that
    take timescale as a parameter, and estimate the needed routing
    algorithm parameters based on that
    * see Karvo and Ott, Time Scales and Delay-Tolerant Routing
      Protocols, CHANTS 2008, for more information.
  * added new (unrealistic) EpidemicOracleRouter that transfers messages
    immediately and deletes all replicas from buffers when the message is
    delivered
  * added maximum meeting probability set size support for MaxProp
    to improve its performance in scenarios with many nodes
- Added MessageReport class for reporting message deliveries,
   CreatedMessagesReport for message creations and EventLogReport for
   reporting everything (in a StandardEventsReader compatible format)
- Added application layer
  * applications can be created by extending the Application class
  * multiple applications can run in the nodes
  * report modules can register for application events
  * see PingApplication and PingAppReporter for an example
- Added ClusterMovement for creating clusters of nodes and
   LinearFormation for lines of nodes
- ExternalMovementReader supports comment lines (starting with "#")
- "Delete all" message event and support for this in
   StandardEventsReader
- Possibility to choose first route stop for MapRouteMovement
- Added new message event generators: OneFromEachMessageGenerator and
   OneToEachMessageGenerator
- Added time range setting to MessageEventGenerator
- GUI improvements
  * highlighting of pause-events to EventLogPanel
  * GUI starts paused by default
  * hh:mm:ss display for simulation time (right-click the simulation
    time)
- Improved and new analysis scripts
  * added "log", "total", and "index" options for the ccdfPlotter.pl
  * added getStatsAverages.pl
- Bugfixes
  * host range checking in MessageEventGenerator
  * command line option -b doesn't require range anymore

Cheers,
Ari
_______________________________________________
theONE mailing list
[email-masked]
https://www.netlab.tkk.fi/mailman/listinfo/theone

--------------040909000905000707000200--

Date: Tue, 16 Mar 2010 10:08:19 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] LA Agenda

Bit of slot shuffling and one forgotten
slot added. (Apologies to Dan B;-)

Cheers,
S.

On 03/15/2010 09:34 PM, Stephen Farrell wrote:
> 
> Folks,
> 
> I got a bit swamped the last couple of weeks but have
> finally posted a draft agenda. [1] Sorry for being late.
> 
> I think it might be better to figure out the exact way
> to structure the rel-time, alt-time etc slot after
> some hallway chats in LA, so for now I've just given
> than an hour with no further breakdown by name or time
> so far.
> 
> If you mailed me earlier for a slot and I've left it
> out, I apologiese - just ping me again and we'll fit it
> in. (Some of the 20 minute slots can be shortened.)
> 
> Stephen.
> 
> [1] http://www.ietf.org/proceedings/10mar/agenda/DTNRG.html
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 

Date: Tue, 16 Mar 2010 09:17:14 +0800 (CST)
From: [email-masked]
To: [email-masked]
Subject: [dtn-interest] help

help

> -----Original E-mail-----
> From: [email-masked]
> Sent Time: 2010-3-16 3:00:02
> To: [email-masked]
> Cc: 
> Subject: dtn-interest Digest, Vol 30, Issue 15
> 
> Send dtn-interest mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dtn-interest digest..."
> 
> 
> Today's Topics:
> 
>    1. New Version Notification for draft-irtf-dtnrg-ipnd-01
>       (Daniel Ellard)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 15 Mar 2010 10:27:38 -0400
> From: Daniel Ellard <[email-masked]>
> Subject: [dtn-interest] New Version Notification for
> 	draft-irtf-dtnrg-ipnd-01
> To: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 
> Apologies if you've already seen this, but it doesn't seem
> to made it to the list.
> 
> > A new version of I-D, draft-irtf-dtnrg-ipnd-01.txt has been successfuly submitted by Dan Brown and posted to the IETF repository.
> > 
> > Filename:	 draft-irtf-dtnrg-ipnd
> > Revision:	 01
> > Title:		 DTN IP Neighbor Discovery (IPND)
> > Creation_date:	 2010-03-08
> > WG ID:		 Independent Submission
> > Number_of_pages: 18
> > 
> > Abstract:
> > Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is
> > a method for otherwise oblivious nodes to learn of the existence,
> > availability, and addresses of other DTN participants.  IPND both
> > sends and listens for small IP UDP announcement "beacons."  Beacon
> > messages are addressed to an IP unicast, multicast, or broadcast
> > destination to discover specified remote neighbors, or unspecified
> > local neighbors in the topology, e.g. within wireless range.  IPND
> > beacons advertise neighbor availability by including the DTN node's
> > canonical endpoint identifier.  IPND beacons optionally include
> > service availability and parameters.  In this way, neighbor discovery
> > and service discovery may be coupled or decoupled as required.  Once
> > discovered, new neighbor pairs use advertised availabilities to
> > connect, exchange routing information, etc.  This document describes
> > DTN IPND.
> >                                                                                   
> > 
> > 
> > The IETF Secretariat.
> > 
> 
> 
> 
> -- 
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
> 
> 
> ------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 
> End of dtn-interest Digest, Vol 30, Issue 15
> ********************************************

Date: Mon, 15 Mar 2010 21:34:28 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] LA Agenda

Folks,

I got a bit swamped the last couple of weeks but have
finally posted a draft agenda. [1] Sorry for being late.

I think it might be better to figure out the exact way
to structure the rel-time, alt-time etc slot after
some hallway chats in LA, so for now I've just given
than an hour with no further breakdown by name or time
so far.

If you mailed me earlier for a slot and I've left it
out, I apologiese - just ping me again and we'll fit it
in. (Some of the 20 minute slots can be shortened.)

Stephen.

[1] http://www.ietf.org/proceedings/10mar/agenda/DTNRG.html

Date: Mon, 15 Mar 2010 10:27:38 -0400
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] New Version Notification for draft-irtf-dtnrg-ipnd-01

Apologies if you've already seen this, but it doesn't seem
to made it to the list.

> A new version of I-D, draft-irtf-dtnrg-ipnd-01.txt has been successfuly submitted by Dan Brown and posted to the IETF repository.
> 
> Filename:	 draft-irtf-dtnrg-ipnd
> Revision:	 01
> Title:		 DTN IP Neighbor Discovery (IPND)
> Creation_date:	 2010-03-08
> WG ID:		 Independent Submission
> Number_of_pages: 18
> 
> Abstract:
> Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is
> a method for otherwise oblivious nodes to learn of the existence,
> availability, and addresses of other DTN participants.  IPND both
> sends and listens for small IP UDP announcement "beacons."  Beacon
> messages are addressed to an IP unicast, multicast, or broadcast
> destination to discover specified remote neighbors, or unspecified
> local neighbors in the topology, e.g. within wireless range.  IPND
> beacons advertise neighbor availability by including the DTN node's
> canonical endpoint identifier.  IPND beacons optionally include
> service availability and parameters.  In this way, neighbor discovery
> and service discovery may be coupled or decoupled as required.  Once
> discovered, new neighbor pairs use advertised availabilities to
> connect, exchange routing information, etc.  This document describes
> DTN IPND.
>                                                                                   
> 
> 
> The IETF Secretariat.
> 

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: "Symington, Susan F." <[email-masked]>
To: Kevin Fall <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 11 Mar 2010 13:53:17 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] SCHL draft

Kevin,

I read your I-D: DTN Scope Control using Hop Limits (SCHL)
                        draft-fall-dtnrg-schl-00

I can see a need for this block and would like to see it implemented. In addition, I can see a need for using the hop count field alone, not in conjunction with the hop limit field (not for scoping). Below are some specific comments:

1) Bundle Block type 9 is already reserved for the Extension Security Block in the BSP. (see http://www.dtnrg.org/wiki/AssignedNamesAndNumbers ) We may be willing to sell it to you for a small fee;)

2) Section 4.1, end of 1st paragraph.  Not sure what the "x" is there for.

3) I may want to know the hop count for reasons other than limiting the scope of the bundle. The hop count may be interesting information for me on which to base routing decisions, for example. Therefore, I'd like you to add an option to set the hop limit to "unlimited". In other words, I can envision wanting to know the hop count, but not wanting to have to set an a priory hop limit (instead, I would just rely on the bundle timeout feature to make an old bundle go away). Could an initial hop limit value of 0 be used to mean "unlimited"? 

4) Security Considerations: You should also mention that a malicious bundle agent could also modify the hop limit field. Perhaps this shouldn't be allowed. Assuming the hop limit field is not ever intended to be mutable, there might be an argument for placing this hop limit value in a separate extension block that could be protected end-to-end. On the other hand, if a malicious agent can muck with the hop count, protecting the hop limit from being modified may not be all that useful. Still, there may be some value in being able to ensure that this limit hasn't been modified, especially if it was initially set to "unlimited", meaning that the hop count isn't being used for scoping purposes.
 
5) What happens if a BPA receives a bundle with the SCHL block and it doesn't support the SCHL block?  Should it discard the block? Delete the bundle? Forward the bundle without, obviously, incrementing the hop count?  If a BPA receives a bundle with this block and the block has a flag indicating that the block was forwarded without being processed, should the receiving BPA increment the hop count twice?

-susan

>-----Original Message-----
>From: [email-masked] [mailto:dtn-interest-
>[email-masked]] On Behalf Of Kevin Fall
>Sent: Monday, March 01, 2010 7:22 PM
>To: [email-masked]
>Subject: [dtn-interest] SCHL draft
>
>
>For those interested, I uploaded a -00 draft (DTN Scope Control using Hop
>Limits - SCHL) yesterday.
>It does pretty much what it says-- defines an extension block to do scope
>control using a count-up
>form of hop limit scoping.
>
>- K
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 11 Mar 2010 18:35:34 +0000
From: Piero Cornice <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN2 on Maemo - preliminary results

The research team of Prof. Carlo Caini (DEIS, University of Bologna, Italy) have
successfully installed DTN2 on a Nokia N900 with Maemo 5.

Preliminary results are available at this page: http://cnrl.deis.unibo.it/

Kind regards,
Piero Cornice

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 9 Mar 2010 17:05:34 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] What's the Bundle Protocol equivalent of this?

--_000_FD514C8A5155C64C9B145B48D674EF544A4476D235ALTPHYEMBEVSP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Right, postmaster@sprint accepted custody and then attempted to forward to =
gpau@sprint but failed at the "convergence layer" (blackberry not turned on=
 or whatever).  I'd guess that postmaster@sprint tried for some time to mak=
e this happen and finally gave up, which I think could be taken as the func=
tional equivalent of bundle expiration.  ["I have tried and tried to forwar=
d this bundle, for a very long time, and upon the lapse of all this time I =
find no further need to continue."]  This resulted in bundle deletion, whic=
h caused transmission of a status message (effectively, status code 16 and =
reason code 1) back to you because the "bundle" was "custodial".  Not too a=
lien, I think.

Scott

From: [email-masked] [mailto:dtn-interes=
[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, March 06, 2010 1:02 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] What's the Bundle Protocol equivalent of this?

It's like a custody transfer followed by....? It's not equivalent to a cust=
ody transfer failure message, as postmaster@sprint successfully became the =
custodian.

In a parallel with the Bundle Protocol, there are interestingly messed-up c=
locks....

Begin forwarded message:

From: "[email-masked]<mailto:[email-masked]=
.net>" <[email-masked]<mailto:[email-masked]=
y.net>>
Date: 6 March 2010 01:42:55 GMT
To: "Wood L Dr (Electronic Eng)" <[email-masked]<mailto:L.Wood@surrey.=
ac.uk>>
Subject: Delivery Status Notification(Failure)

Your message:
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse
Sent Date: 27:38 +0000
has not been delivered to the recipient's BlackBerry Handheld.

Final-Recipient: RFC822;[email-masked]
Action: Failed
Status: 5.0.0

Lloyd Wood
[email-masked]<mailto:[email-masked]>
http://sat-net.com/L.Wood

--_000_FD514C8A5155C64C9B145B48D674EF544A4476D235ALTPHYEMBEVSP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: break-wor=
d;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Right, postmaster@sprint accepted custody and then attempted=
 to
forward to gpau@sprint but failed at the &#8220;convergence layer&#8221;
(blackberry not turned on or whatever).&nbsp; I&#8217;d guess that
postmaster@sprint tried for some time to make this happen and finally gave =
up, which
I think could be taken as the functional equivalent of bundle expiration.&n=
bsp;
[&#8220;I have tried and tried to forward this bundle, for a very long time=
, and
upon the lapse of all this time I find no further need to continue.&#8221;]=
&nbsp;
This resulted in bundle deletion, which caused transmission of a status mes=
sage
(effectively, status code 16 and reason code 1) back to you because the &#8=
220;bundle&#8221;
was &#8220;custodial&#8221;.&nbsp; Not too alien, I think.<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Scott<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked]
[mailto:[email-masked]] <b>On Behalf Of =
</b>[email-masked]<br>
<b>Sent:</b> Saturday, March 06, 2010 1:02 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> [dtn-interest] What's the Bundle Protocol equivalent of thi=
s?<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>It's like a custody transfer followed by....? It's not
equivalent to a custody transfer failure message, as postmaster@sprint
successfully became the custodian.<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<div>

<p class=3DMsoNormal>In a parallel with the Bundle Protocol, there are
interestingly messed-up clocks....<o:p></o:p></p>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Begin forwarded message:<o:p></o:p></p>

</div>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<div>

<p class=3DMsoNormal><b><span style=3D'font-size:13.5pt;font-family:"Helvet=
ica","sans-serif"'>From:
</span></b><span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-se=
rif"'>&quot;<a
href=3D"mailto:[email-masked]">[email-masked]=
ry.net</a>&quot;
&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
lackberry.net</a>&gt;</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><b><span style=3D'font-size:13.5pt;font-family:"Helvet=
ica","sans-serif"'>Date:
</span></b><span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-se=
rif"'>6
March 2010 01:42:55 GMT</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><b><span style=3D'font-size:13.5pt;font-family:"Helvet=
ica","sans-serif"'>To:
</span></b><span style=3D'font-size:13.5pt;font-family:"Helvetica","sans-se=
rif"'>&quot;Wood
L Dr (Electronic Eng)&quot; &lt;<a href=3D"mailto:[email-masked]">L.Wo=
[email-masked]</a>&gt;</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><b><span style=3D'font-size:13.5pt;font-family:"Helvet=
ica","sans-serif"'>Subject:
Delivery Status Notification(Failure)</span></b><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
Your message:<br>
To: <a href=3D"mailto:[email-masked]">[email-masked]=
t</a><br>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse<br>
Sent Date: 27:38 +0000<br>
has not been delivered to the recipient's BlackBerry Handheld.<br>
<br>
Final-Recipient: RFC822;[email-masked]<br>
Action: Failed<br>
Status: 5.0.0<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:13.5pt;font-family:"Helvetica=
","sans-serif";
color:black'>Lloyd Wood<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:13.5pt;font-family:"Helvetica=
","sans-serif";
color:black'><a href=3D"mailto:[email-masked]">[email-masked]</a>=
<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:13.5pt;font-family:"Helvetica=
","sans-serif";
color:black'><a href=3D"http://sat-net.com/L.Wood">http://sat-net.com/L.Woo=
d</a><o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:13.5pt;font-family:"Helvetica=
","sans-serif";
color:black'><o:p>&nbsp;</o:p></span></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</div>

</body>

</html>

--_000_FD514C8A5155C64C9B145B48D674EF544A4476D235ALTPHYEMBEVSP_--

Date: Mon, 8 Mar 2010 10:14:10 +0000
From: Fehmi Ben Abdesslem <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] ACM HotPlanet 2010 workshop (co-located with ACM MobiSys) - Extended Deadline

--------------050500090100080102070209
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

    -------------------------------------------------------------
    Our apologies if you receive multiple copies of this message.
    -------------------------------------------------------------

Note: Due to numerous requests the paper submission deadline has been extended to March 21, 2010.
Please register your paper before March 14, 2010.

The 2nd ACM Workshop on Hot Topics in Planet-scale Measurement (HotPlanet)
co-located with ACM MobiSys '10, San Francisco, CA, USA
June 15, 2010
http://www.hotplanetconf.net/10/

Important dates:
Paper registration deadline:   March 14, 2010
Submission deadline:   March 21, 2010
Authors notification:  April 18, 2010
Camera ready:          May 7, 2010
Workshop date:         June 15, 2010

It is well-known that successfully researching, designing and building new mobile, ad hoc, mesh and opportunistic networking systems and algorithms requires access to large-scale data on human mobility, encounter, and social network patterns. Unfortunately, the wireless and mobile  research communities lack such data, with typical human contact traces consisting of less than 100 nodes. We believe that large-scale datasets are important, not only in communication network design, but also for fundamental study in other academic disciplines, e.g., epidemiology, urban planning, and social science. Complex networks research has flourished since 1989 when the first large Internet (and later WWW) datasets became available. To achieve similar improvements in mobile networking and related fields, large-scale, and ideally planet-scale, datasets must be collected and made available.

Following a successful introductory event at ACM MobiSys 2009, this year's workshop will challenge the community to collect large-scale human mobility traces. Our aim is to highlight the issues in collecting data on a planet-wide scale, so that the community can help develop mechanisms to collect, share and analyse such data.

Topics for the workshop include, but are not limited to:
- Motivating applications for large-scale human mobility data collection, especially from other disciplines, e.g., epidemiology, sociology
- Methods for collecting large-scale human mobility datasets
- New analyses and applications of large-scale human mobility datasets, e.g., human dynamics characterisation and modelling
- Planet-scale data collection infrastructures
- Testbed federation for planet-scale data collection
- Incentive models for encouraging users and businesses to collect and contribute data on a planet-wide scale
- Enabling security, privacy and anonymity for large-scale data collection
- Regulatory, legal and ethical issues in planet-wide data collection

SUBMISSION GUIDELINES

All submitted papers will be carefully evaluated based on their originality, significance, technical soundness, and clarity of expression. Accepted papers will be published by ACM and placed in the ACM Digital Library. Submissions must be in English, no longer than 6 pages and in PDF format, and use the ACM templates<http://www.acm.org/sigs/publications/proceedings-templates>. All fonts must be embedded within the PDF and be Type 1 (scalable).

In order to allow papers to appear in the ACM Digital Library, authors of accepted papers will be asked to submit, together with their camera-ready, an ACM proceedings copyright transfer form<http://www.acm.org/publications/copyright_form>. Failure to send the camera-ready and copyright transfer on time will prevent the publication of the paper and its inclusion in the ACM Digital Library.

Papers should be submitted through EDAS at<http://edas.info/N8637>.
Further details are on the workshop website at<http://www.hotplanetconf.net/>

PROGRAMME CHAIRS
- Tristan Henderson, University of St Andrews, UK
- Pablo Vidales, Deutsche Telekom Laboratories, DE

PROGRAMME COMMITTEE
- Andrew Campbell, Dartmouth College, US
- Guanling Chen, University of Massachusetts Lowell, US
- Jon Crowcroft, University of Cambridge, UK
- Fernando Esponda, Instituto Tecnologico Autonomo de Mexico, MX
- Xiaoming Fu, University of Goettingen, DE
- Pan Hui, Deutsche Telekom Laboratories, DE
- Vassilis Kostakos, University of Madeira, PT
- David Kotz, Dartmouth College, US
- Anders Lindgren, Swedish Institute of Computer Science, SE
- Iqbal Mohomed, Microsoft Research, US
- Richard Mortier, University of Nottingham, UK
- Mirco Musolesi, University of St Andrews, UK
- Andrea Passarella, CNR-IIT, IT
- Michal Piorkowski, Bmob, CH
- Calicrates Policroniades, Telenor, NO
- Cigdem Sengul, TU Berlin, DE
- Chuan Wu, University of Hong Kong, CN

-- Fehmi Ben Abdesslem Postdoctoral Researcher Networked and Distributed 
Systems University of St Andrews - School of Computer Science Office 
1.02, Jack Cole Building, North Haugh St Andrews, Fife KY16 9SX, 
Scotland, UK The University of St Andrews is committed to sustainable 
practices and the preservation of the environment. Please do not print 
this email unless absolutely necessary. The University of St Andrews is 
a charity registered in Scotland: No SC013532

--------------050500090100080102070209
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">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
 style="font-family: -moz-fixed; font-size: 13px;" lang="x-western">
<pre wrap="">   -------------------------------------------------------------
   Our apologies if you receive multiple copies of this message.
   -------------------------------------------------------------

Note: Due to numerous requests the paper submission deadline has been extended to March 21, 2010.
Please register your paper before March 14, 2010.

The 2nd ACM Workshop on Hot Topics in Planet-scale Measurement (HotPlanet)
co-located with ACM MobiSys '10, San Francisco, CA, USA
June 15, 2010
<a class="moz-txt-link-freetext" href="http://www.hotplanetconf.net/10/">http://www.hotplanetconf.net/10/</a>

Important dates:
Paper registration deadline:   March 14, 2010
Submission deadline:   March 21, 2010
Authors notification:  April 18, 2010
Camera ready:          May 7, 2010
Workshop date:         June 15, 2010

It is well-known that successfully researching, designing and building new mobile, ad hoc, mesh and opportunistic networking systems and algorithms requires access to large-scale data on human mobility, encounter, and social network patterns. Unfortunately, the wireless and mobile  research communities lack such data, with typical human contact traces consisting of less than 100 nodes. We believe that large-scale datasets are important, not only in communication network design, but also for fundamental study in other academic disciplines, e.g., epidemiology, urban planning, and social science. Complex networks research has flourished since 1989 when the first large Internet (and later WWW) datasets became available. To achieve similar improvements in mobile networking and related fields, large-scale, and ideally planet-scale, datasets must be collected and made available.

Following a successful introductory event at ACM MobiSys 2009, this year's workshop will challenge the community to collect large-scale human mobility traces. Our aim is to highlight the issues in collecting data on a planet-wide scale, so that the community can help develop mechanisms to collect, share and analyse such data.

Topics for the workshop include, but are not limited to:
- Motivating applications for large-scale human mobility data collection, especially from other disciplines, e.g., epidemiology, sociology
- Methods for collecting large-scale human mobility datasets
- New analyses and applications of large-scale human mobility datasets, e.g., human dynamics characterisation and modelling
- Planet-scale data collection infrastructures
- Testbed federation for planet-scale data collection
- Incentive models for encouraging users and businesses to collect and contribute data on a planet-wide scale
- Enabling security, privacy and anonymity for large-scale data collection
- Regulatory, legal and ethical issues in planet-wide data collection

SUBMISSION GUIDELINES

All submitted papers will be carefully evaluated based on their originality, significance, technical soundness, and clarity of expression. Accepted papers will be published by ACM and placed in the ACM Digital Library. Submissions must be in English, no longer than 6 pages and in PDF format, and use the ACM templates<a
 class="moz-txt-link-rfc2396E"
 href="http://www.acm.org/sigs/publications/proceedings-templates">&lt;http://www.acm.org/sigs/publications/proceedings-templates&gt;</a>. All fonts must be embedded within the PDF and be Type 1 (scalable).

In order to allow papers to appear in the ACM Digital Library, authors of accepted papers will be asked to submit, together with their camera-ready, an ACM proceedings copyright transfer form<a
 class="moz-txt-link-rfc2396E"
 href="http://www.acm.org/publications/copyright_form">&lt;http://www.acm.org/publications/copyright_form&gt;</a>. Failure to send the camera-ready and copyright transfer on time will prevent the publication of the paper and its inclusion in the ACM Digital Library.

Papers should be submitted through EDAS at<a
 class="moz-txt-link-rfc2396E" href="http://edas.info/N8637">&lt;http://edas.info/N8637&gt;</a>.
Further details are on the workshop website at<a
 class="moz-txt-link-rfc2396E" href="http://www.hotplanetconf.net/">&lt;http://www.hotplanetconf.net/&gt;</a>

PROGRAMME CHAIRS
- Tristan Henderson, University of St Andrews, UK
- Pablo Vidales, Deutsche Telekom Laboratories, DE

PROGRAMME COMMITTEE
- Andrew Campbell, Dartmouth College, US
- Guanling Chen, University of Massachusetts Lowell, US
- Jon Crowcroft, University of Cambridge, UK
- Fernando Esponda, Instituto Tecnologico Autonomo de Mexico, MX
- Xiaoming Fu, University of Goettingen, DE
- Pan Hui, Deutsche Telekom Laboratories, DE
- Vassilis Kostakos, University of Madeira, PT
- David Kotz, Dartmouth College, US
- Anders Lindgren, Swedish Institute of Computer Science, SE
- Iqbal Mohomed, Microsoft Research, US
- Richard Mortier, University of Nottingham, UK
- Mirco Musolesi, University of St Andrews, UK
- Andrea Passarella, CNR-IIT, IT
- Michal Piorkowski, Bmob, CH
- Calicrates Policroniades, Telenor, NO
- Cigdem Sengul, TU Berlin, DE
- Chuan Wu, University of Hong Kong, CN

<div class="moz-txt-sig">-- 
Fehmi Ben Abdesslem
Postdoctoral Researcher
Networked and Distributed Systems

University of St Andrews - School of Computer Science
Office 1.02, Jack Cole Building, North Haugh
St Andrews, Fife KY16 9SX, Scotland, UK

The University of St Andrews is committed to sustainable practices and the preservation of the environment.
Please do not print this email unless absolutely necessary.

The University of St Andrews is a charity registered in Scotland: No SC013532
</div></pre>
</div>
</body>
</html>

--------------050500090100080102070209--

From: <[email-masked]>
To: <[email-masked]>
Date: Sat, 6 Mar 2010 09:02:20 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked]
Subject: [dtn-interest] What's the Bundle Protocol equivalent of this?

--_000_DB4C25DDC5FC44898E699EE5B0EE7048surreyacuk_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It's like a custody transfer followed by....? It's not equivalent to a cust=
ody transfer failure message, as postmaster@sprint successfully became the =
custodian.

In a parallel with the Bundle Protocol, there are interestingly messed-up c=
locks....

Begin forwarded message:

From: "[email-masked]<mailto:[email-masked]=
.net>" <[email-masked]<mailto:[email-masked]=
y.net>>
Date: 6 March 2010 01:42:55 GMT
To: "Wood L Dr (Electronic Eng)" <[email-masked]<mailto:L.Wood@surrey.=
ac.uk>>
Subject: Delivery Status Notification(Failure)

Your message:
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse
Sent Date: 27:38 +0000
has not been delivered to the recipient's BlackBerry Handheld.

Final-Recipient: RFC822;[email-masked]
Action: Failed
Status: 5.0.0

Lloyd Wood
[email-masked]<mailto:[email-masked]>
http://sat-net.com/L.Wood

--_000_DB4C25DDC5FC44898E699EE5B0EE7048surreyacuk_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; ">It's like a custody transf=
er followed by....? It's not equivalent to a custody transfer failure messa=
ge, as postmaster@sprint successfully became the custodian.<div><br></div><=
div>In a parallel with the Bundle Protocol, there are interestingly messed-=
up clocks....<br><div><br><div>Begin forwarded message:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite"><div style=3D"margin-to=
p: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span sty=
le=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><=
b>From: </b></span><span style=3D"font-family:'Helvetica'; font-size:medium=
;">"<a href=3D"mailto:[email-masked]">[email-masked]=
lackberry.net</a>" &lt;<a href=3D"mailto:[email-masked]">=
[email-masked]</a>&gt;<br></span></div><div style=3D"marg=
in-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><spa=
n style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1=
);"><b>Date: </b></span><span style=3D"font-family:'Helvetica'; font-size:m=
edium;">6 March 2010 01:42:55 GMT<br></span></div><div style=3D"margin-top:=
 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style=
=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>=
To: </b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">"=
Wood L Dr (Electronic Eng)" &lt;<a href=3D"mailto:[email-masked]">L.Wo=
[email-masked]</a>&gt;<br></span></div><div style=3D"margin-top: 0px; marg=
in-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style=3D"font-f=
amily:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Subject: <=
/b></span><span style=3D"font-family:'Helvetica'; font-size:medium;"><b>Del=
ivery Status Notification(Failure)</b><br></span></div><br>Your message:<br=
>To: <a href=3D"mailto:[email-masked]">[email-masked]=
et</a><br>Subject: Re: [dtn-interest] DTNRG: let's elevate the level of dis=
course<br>Sent Date: 27:38 +0000<br>has not been delivered to the recipient=
's BlackBerry Handheld.<br><br>Final-Recipient: RFC822;[email-masked]=
ry.net<br>Action: Failed<br>Status: 5.0.0<br><br><br><br><br><br></blockquo=
te></div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
 rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-borde=
r-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-te=
xt-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-tex=
t-stroke-width: 0px; "><div>Lloyd Wood</div><div><a href=3D"mailto:L.Wood@s=
urrey.ac.uk">[email-masked]</a></div><div><a href=3D"http://sat-net.co=
m/L.Wood">http://sat-net.com/L.Wood</a></div><div><br></div></span><br clas=
s=3D"Apple-interchange-newline">
</div>
<br></div></body></html>=

--_000_DB4C25DDC5FC44898E699EE5B0EE7048surreyacuk_--

Date: Fri, 05 Mar 2010 16:38:34 +0000
From: Elwyn Davies <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Cc: Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start	for	draft-irtf-dtnrg-metadata-block

Hi, Scott.

Burleigh, Scott C (313B) wrote:
>> -----Original Message-----
>>     
<<snip>>
>> I think there are two 'global' registries that could affect any bundle
>> protocol related draft:
>> - Extension block code
>> - Block processing control flags
>>     
>
> I agree that we need a global registry for block types, but why is one needed for the block processing control flags?  The flags are all fully defined in section 4.2 of RFC5050.
>
> Bits 9 through 13 of the block processing control flags SDNV are reserved for future use.  I would expect any eventual definition of those flags to appear in a successor document to RFC5050 (since that definition would conflict with what RFC5050 says) rather than just be posted to a registry.
>   
Technically the new document would be an update for RFC 5050 anyway, so
there is not necessarily a conflict, and you would have to have a
specification to register and specify a use for such an extra flag.  A
bundle agent that understood extra extension blocks that used any extra
flags would be backwards compatible so it doesn't seem tn be a big
problem.  It is generally good practice if you have a field with
reserved bits that are associated with extensions to make it into a
registry in case somebody finds a good usage.

Regards,
Elwyn
> Scott
>  
>   
>> The registry defining I-D could progress in parallel with the other
>> drafts that are going forward.  Since it will be short and sweet it
>> won't be a significant blockage for the other drafts as long as it
>> exists by the time the other drafts are ready to reach RFC Editor state.
>>
>> I believe that the other registries needed at the moment are draft
>> specific.  The ones in the drafts currently headed for the IRSG seem to be
>> - Ciphersuites in BSP
>> - Ciphersuite flags in BSP
>> - Security parameter types in BSP
>> - Metatdata types in metadata block
>> - Several in the PRoPHET draft which already has a full IANA
>> considerations section with 'Specification Required' policies throughout.
>>
>> I think it would be best to define the registries in these documents
>> where they are introduced, rather than adding them to the global draft.
>>
>> The cbhe, sdnv and previous hop block drafts don't have any.
>>
>> The BSP, metedata and previous hop block drafts would need to be updated
>> to refer to the new draft and to request some values from the registries.
>>
>> Regards,
>> Elwyn
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>     

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, Stephen Farrell <[email-masked]>
Date: Fri, 5 Mar 2010 08:00:35 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start	for	draft-irtf-dtnrg-metadata-block

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Elwyn Davies
> Sent: Friday, March 05, 2010 4:22 AM
> To: Stephen Farrell
> Cc: Internet Research Steering Group; Delay Tolerant Networking Interest
> List; Elwyn Davies
> Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for
> draft-irtf-dtnrg-metadata-block
> 
> Stephen Farrell wrote:
> > On 03/04/2010 01:00 PM, Juergen Schoenwaelder wrote:
> >
> >> On Thu, Mar 04, 2010 at 01:39:05PM +0100, Stephen Farrell wrote:
> >>
> >>>> I read the document and I vote "Note ready to publish" for two
> >>>> reasons:
> >>>>
> >>>> First, the IANA considerations sections seems to be at odds with
> >>>> section 4.2 which requires registration of metadata types. The IANA
> >>>> Considerations section, however, only loosely talks about "we may
> >>>> consider creating a registry". I believe the document should actually
> >>>> create the relevant registries and establish the necessary procedures.
> >>>>
> >>> Fair point. However, rfc5050 itself is really to blame here - it
> >>> should have created registries. But co-incidentally, just today,
> >>> (and literally 5 minutes before I saw your mail!) I've gotten
> >>> volunteers [1] to write an I-D to get BP registries created so we
> >>> are handling this. So I'd ask that we let this one go ahead on
> >>> the basis that the real sinner was rfc5050 and the RG are tackling
> >>> that to make up for all our past sins in one go?
> >>>
> >> I don't know whether this is a workable solution or not. But even
> >> then, I believe the text in the IANA considerations needs to change to
> >> be clear about the fact that another document creates the registry.
> >>
> >
> > Yes I think we can change the wording in those sections. Probably
> > best is the RG discuss this in LA and we then add text requesting
> > or referencing the appropriate IANA registry entries in each of
> > these documents.
> >
> > I don't know if we have to also add a reference to an I-D that
> > requests creation of those registries. I guess worst case that'd
> > mean all these drafts sitting in the RFC editor queue until that
> > document catches up. Maybe there's a way to get the registries
> > created earlier, and to tidy up later on with an I-D. I'll check.
> > (If someone knows, feel free to enlighten me:-)
> >
> > In any case, would you agree that once we change as above that
> > these documents can then go forward to IESG review and the RFC
> > editor queue?
> >
> >
> Two approaches could be taken:
> - Build a very short I-D defining the registries, updating RFC 5050
> (preferred)
> - Add the registry definitions to the BSP which uses the block codes
> exensively or the metadata block spec maybe
> 
> I don't think there are any shortcuts but the registry draft is hardly
> going to be controversial and could be crafted in a couple of hours once
> it is agreed what 'global' registries are required. I would be happy to
> do this if although I think Stephen has offers of effort elsewhere as well.
> 
> I think there are two 'global' registries that could affect any bundle
> protocol related draft:
> - Extension block code
> - Block processing control flags

I agree that we need a global registry for block types, but why is one needed for the block processing control flags?  The flags are all fully defined in section 4.2 of RFC5050.

Bits 9 through 13 of the block processing control flags SDNV are reserved for future use.  I would expect any eventual definition of those flags to appear in a successor document to RFC5050 (since that definition would conflict with what RFC5050 says) rather than just be posted to a registry.

Scott
 
> The registry defining I-D could progress in parallel with the other
> drafts that are going forward.  Since it will be short and sweet it
> won't be a significant blockage for the other drafts as long as it
> exists by the time the other drafts are ready to reach RFC Editor state.
> 
> I believe that the other registries needed at the moment are draft
> specific.  The ones in the drafts currently headed for the IRSG seem to be
> - Ciphersuites in BSP
> - Ciphersuite flags in BSP
> - Security parameter types in BSP
> - Metatdata types in metadata block
> - Several in the PRoPHET draft which already has a full IANA
> considerations section with 'Specification Required' policies throughout.
> 
> I think it would be best to define the registries in these documents
> where they are introduced, rather than adding them to the global draft.
> 
> The cbhe, sdnv and previous hop block drafts don't have any.
> 
> The BSP, metedata and previous hop block drafts would need to be updated
> to refer to the new draft and to request some values from the registries.
> 
> Regards,
> Elwyn
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Fri, 05 Mar 2010 15:06:58 +0100
From: Aline Carneiro Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE MASS 2010

7th IEEE International Conference on Mobile Ad-Hoc and Sensor Systems
                         IEEE MASS 2010
                 https://mass2010.soe.ucsc.edu/
            San Francisco, California, November 2010

-------------------------------------------------------------------------------------------------------
               ****  Workshop Proposals Deadline:  March 31, 2010  ****

Co-sponsored by the IEEE Computer Society Technical Committee on
Distributed Processing and the IEEE Computer Society Technical Committee
on Simulation

-------------------------------------------------------------------------------------------------------
IEEE MASS 2010 will be the seventh annual conference on the rapidly
expanding area of multi-hop wireless computing and sensor networking,
and will provide an exciting platform for discussing research vision
of a digitally networked wireless environment.

The MASS Organizing Committee invites proposals for one-day workshops
affiliated with the conference. The workshops will be held prior to, or 
after,
the main conference.

The purpose of these workshops is to provide a platform for presenting
novel ideas and more specific research areas in a less formal and possibly
more focused way than at the conference itself.  Please visit
http://www.cs.cityu.edu.hk/mass09/workshops.shtml to view information
on workshops held last year at MASS 2009.

Workshops Proposals are solicited in all areas and topics pertaining
to ad-hoc wireless and sensor networking research and applications.

All papers included in the MASS 2010 workshops will appear in the MASS
2010 Proceedings published by IEEE.  We expect all selected workshops
to adhere to a common paper submission and reviewing schedule outlined
below:

Workshop proposals deadline:    March 31, 2010
Proposals notification:         April 9, 2010
Manuscripts due:                June 18, 2010
Acceptance notification:        August 13, 2010
Camera-ready submission:        September 3, 2010

------------------------------------------------
Proposal Submission Guidelines:
------------------------------------------------
Each workshop proposal must include:

1. The name of the workshop
2. The names, addresses, and a short bio (up to 200 words) of the organizers
  (maximum up to three)
3. A brief description (up to 1 page) of the technical issues that the 
workshop
will address, and the reasons why the workshop is of interest this time
4. The names of potential participants, such as program committee members
5. Planned format of the workshop, such as number of refereed papers,
keynotes, panels etc.
6. If appropriate, a description of past versions of the workshop, 
including:
number of submitted and accepted papers, number of attendees
7. A description of the publicity plan
8. A call for papers
9. The workshop website address

Workshop proposals should be submitted, no later than March 31, 2010
by e-mail (in PDF format) with "MASS 2010 Workshop Proposal" in the
subject, to BOTH MASS 2010 Workshop Co-chairs:

Cédric Westphal
DoCoMo Labs USA
[email-masked]

Christine Pépin
[email-masked]

Date: Fri, 05 Mar 2010 14:49:32 +0100
From: Aline Carneiro Viana <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: IEEE MASS 2010

[We apologize in advance if you receive multiple copies of this message]

==========================================================================
                     CALL FOR PAPERS

                     IEEE MASS 2010
     7th IEEE International Conference on Mobile Ad-hoc
                      and Sensor Systems
               https://mass2010.soe.ucsc.edu/

            November 2010 - San Francisco, CA, USA

Co-sponsored by the IEEE Computer Society Technical Committee on 
Distributed Processing and the IEEE Computer Society Technical Committee 
on Simulation

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

IMPORTANT DATES:

Abstract Due:               March 26, 2010
Manuscript Due:             April 2, 2010
Acceptance Notification:    July 12, 2010
Camera-ready Submission:    August 20, 2010

SCOPE:

The 7th IEEE International Conference on Mobile Ad-hoc and Sensor
Systems (IEEE MASS 2010) is to be held in San Francisco, CA between
October TBD, 2010. Wireless ad-hoc communication has applications in a
variety of environments, such as conferences, hospitals, battlefields
and disaster-recovery/rescue operations, and is also being actively
investigated as an alternative paradigm for Internet connectivity in
both urban and rural areas. Wireless sensor and actuator networks are
also being deployed for enhancing industrial control processes and
supply-chains, and for various forms of environmental monitoring. The
IEEE MASS 2010 aims at addressing advances in research on multi-hop
ad-hoc and sensor networks, covering topics ranging from technology
issues to applications and test-bed development. Please keep checking
this web-space for more information and regular updates about MASS 2010.

TOPICS OF INTEREST:

Original, unpublished contributions are solicited in all aspects of
(mobile) ad-hoc networks and wireless sensor networks (WSN), systems and
applications. Topics include, but are not limited to:

*  Vehicular networks and protocols
*  Wireless mesh networks and cognitive networks
*  MAC layer design for ad-hoc networks and WSNs
*  MAC protocols (802.11, 802.15.4, UWB)
*  Multi-channel, multi-radio and MIMO technologies
*  Cross layer design and optimization
*  P2P, overlay, and content distribution architectures for ad-hoc and
sensor networks
*  Delay tolerant networks and opportunistic networking
*  Power-aware architectures, algorithms and protocols design
*  Clustering, topology control, coverage and connectivity
*  Routing protocols (unicast, multicast, broadcast, geocast)
*  Data transport and management in WSNs
*  Data gathering, fusion, and dissemination in WSNs
*  Localization and synchronization in WSNs
*  Cooperative sensing in WSNs
*  Capacity planning and admission control in ad-hoc and sensor networks
*  Handoff / mobility management and seamless internetworking
*  Resource management and wireless QoS Provisioning
*  Key management, trust establishment in wireless networks
*  Security and privacy issues in ad hoc and sensor networks
*  Reliability, resiliency and fault tolerance techniques
*  Security, privacy issues in vehicular, DTNs, and mesh networks
*  Operating systems and middleware support
*  Novel applications and architectures for WSNs
*  Modeling, analysis and performance evaluation
*  Measurements and experience from experimental systems and
test-beds

WORKSHOPS:

Proposals for full day workshops are solicited. Selections will be made
considering the expertise and experience of the workshop organizers and
the relevance of the topic to the central theme of the conference.
Proposals of at most 4 pages, including a 1-page biographical sketch,
should be submitted to the Workshops Chair by March 31, 2009.

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

GENERAL CO-CHAIRS

Mario Gerla, University of California, Los Angeles
Katia Obraczka, University of California, Santa Cruz

PROGRAM CO-CHAIRS

Guohong Cao, Pennsylvania State University
Prasant Mohapatra, University of California, Davis

TPC SUB-AREA CHAIRS

- Protocols and Cross-Layer Technologies
Ahmed Helmy, University of Florida

- Systems, and applications
Chenyang Lu, Washington Unviersity in St. Louis

- Algorithms and theory
Dong Xuan, Ohio State University

- Reliability, security and privacy
Radha Poovendran, University of Washington

WORKSHOP CO-CHAIRS

Cedric Westphal, DoCoMo Labs
Christine Pepin, DoCoMo Labs

DEMO CHAIR

Rajeev Koodli, Starent Networks
Marcelo Dias Amorim, LIP 6, Universite' Paris 6

WEB CHAIR

Venkatesh Rajendran, Wionics

FINANCE AND REGISTRATION CHAIR

Zhen Jiang, West Chester University

PUBLICATION CHAIR

Dajin Wang, Montclair State University

PUBLICITY CHAIR

Aline Carneiro Viana, INRIA

LOCAL ARRANGEMENTS CO-CHAIRS

Kumar Viswanath, NTT Labs
Ignacio Solis, PARC

STEERING COMMITTEE CHAIR

Dharma P. Agrawal, University of Cincinnati

CHAIR OF IEEE TC ON DISTRIBUTED PROCESSING

Jie Wu, US National Science Foundation

CHAIR OF IEEE TC ON SIMULATION

Dave Cavalcanti, Phillips Research

Date: Fri, 5 Mar 2010 12:59:49 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>, Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-metadata-block

On 03/05/2010 11:25 AM, Juergen Schoenwaelder wrote:
>> In any case, would you agree that once we change as above that
>> these documents can then go forward to IESG review and the RFC
>> editor queue?
> 
> I think thats what I wrote, no?

Great. I just wasn't clear that you were ok with these
progressing out of the IRSG review stage or not.

> I now understand that it is not the intention to make the use of SDNVs
> in other protocols easier. So be it. I raised the issue because I
> wanted this to be clarified. So put this to bed (and I will get over
> the tone of this conversation quickly).

Apologies for being cranky, which I guess I was.

AFAIK, no one other than DTNRG has expressed an interest in using
SDNVs and DTNRG hasn't considered extracting that definition to
date. I do agree that if/when we revise 5050 &/or 5326 that'd be
something to consider.

Regards,
Stephen.

Date: Fri, 05 Mar 2010 12:22:04 +0000
From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>, Elwyn Davies <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for	draft-irtf-dtnrg-metadata-block
Reply-To: [email-masked]

Stephen Farrell wrote:
> On 03/04/2010 01:00 PM, Juergen Schoenwaelder wrote:
>   
>> On Thu, Mar 04, 2010 at 01:39:05PM +0100, Stephen Farrell wrote:
>>     
>>>> I read the document and I vote "Note ready to publish" for two
>>>> reasons:
>>>>
>>>> First, the IANA considerations sections seems to be at odds with
>>>> section 4.2 which requires registration of metadata types. The IANA
>>>> Considerations section, however, only loosely talks about "we may
>>>> consider creating a registry". I believe the document should actually
>>>> create the relevant registries and establish the necessary procedures.
>>>>         
>>> Fair point. However, rfc5050 itself is really to blame here - it
>>> should have created registries. But co-incidentally, just today,
>>> (and literally 5 minutes before I saw your mail!) I've gotten
>>> volunteers [1] to write an I-D to get BP registries created so we
>>> are handling this. So I'd ask that we let this one go ahead on
>>> the basis that the real sinner was rfc5050 and the RG are tackling
>>> that to make up for all our past sins in one go?
>>>       
>> I don't know whether this is a workable solution or not. But even
>> then, I believe the text in the IANA considerations needs to change to
>> be clear about the fact that another document creates the registry.
>>     
>
> Yes I think we can change the wording in those sections. Probably
> best is the RG discuss this in LA and we then add text requesting
> or referencing the appropriate IANA registry entries in each of
> these documents.
>
> I don't know if we have to also add a reference to an I-D that
> requests creation of those registries. I guess worst case that'd
> mean all these drafts sitting in the RFC editor queue until that
> document catches up. Maybe there's a way to get the registries
> created earlier, and to tidy up later on with an I-D. I'll check.
> (If someone knows, feel free to enlighten me:-)
>
> In any case, would you agree that once we change as above that
> these documents can then go forward to IESG review and the RFC
> editor queue?
>
>   
Two approaches could be taken:
- Build a very short I-D defining the registries, updating RFC 5050
(preferred)
- Add the registry definitions to the BSP which uses the block codes
exensively or the metadata block spec maybe

I don't think there are any shortcuts but the registry draft is hardly
going to be controversial and could be crafted in a couple of hours once
it is agreed what 'global' registries are required. I would be happy to
do this if although I think Stephen has offers of effort elsewhere as well.

I think there are two 'global' registries that could affect any bundle
protocol related draft:
- Extension block code
- Block processing control flags

The registry defining I-D could progress in parallel with the other
drafts that are going forward.  Since it will be short and sweet it
won't be a significant blockage for the other drafts as long as it
exists by the time the other drafts are ready to reach RFC Editor state.

I believe that the other registries needed at the moment are draft
specific.  The ones in the drafts currently headed for the IRSG seem to be
- Ciphersuites in BSP
- Ciphersuite flags in BSP
- Security parameter types in BSP
- Metatdata types in metadata block
- Several in the PRoPHET draft which already has a full IANA
considerations section with 'Specification Required' policies throughout.

I think it would be best to define the registries in these documents
where they are introduced, rather than adding them to the global draft.

The cbhe, sdnv and previous hop block drafts don't have any.

The BSP, metedata and previous hop block drafts would need to be updated
to refer to the new draft and to request some values from the registries.

Regards,
Elwyn

Date: Fri, 5 Mar 2010 10:59:17 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>, Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-metadata-block

On 03/04/2010 01:00 PM, Juergen Schoenwaelder wrote:
> On Thu, Mar 04, 2010 at 01:39:05PM +0100, Stephen Farrell wrote:
>>>
>>> I read the document and I vote "Note ready to publish" for two
>>> reasons:
>>>
>>> First, the IANA considerations sections seems to be at odds with
>>> section 4.2 which requires registration of metadata types. The IANA
>>> Considerations section, however, only loosely talks about "we may
>>> consider creating a registry". I believe the document should actually
>>> create the relevant registries and establish the necessary procedures.
>>
>> Fair point. However, rfc5050 itself is really to blame here - it
>> should have created registries. But co-incidentally, just today,
>> (and literally 5 minutes before I saw your mail!) I've gotten
>> volunteers [1] to write an I-D to get BP registries created so we
>> are handling this. So I'd ask that we let this one go ahead on
>> the basis that the real sinner was rfc5050 and the RG are tackling
>> that to make up for all our past sins in one go?
> 
> I don't know whether this is a workable solution or not. But even
> then, I believe the text in the IANA considerations needs to change to
> be clear about the fact that another document creates the registry.

Yes I think we can change the wording in those sections. Probably
best is the RG discuss this in LA and we then add text requesting
or referencing the appropriate IANA registry entries in each of
these documents.

I don't know if we have to also add a reference to an I-D that
requests creation of those registries. I guess worst case that'd
mean all these drafts sitting in the RFC editor queue until that
document catches up. Maybe there's a way to get the registries
created earlier, and to tidy up later on with an I-D. I'll check.
(If someone knows, feel free to enlighten me:-)

In any case, would you agree that once we change as above that
these documents can then go forward to IESG review and the RFC
editor queue?

>>> Second, I am wondering what the authoritative reference for SDNV
>>> encodings is going to be. This document refers to the bundle protocol
>>> specification but it is brought forward with a separate document
>>> defining SDNVs. This raises in fact the question whether
>>> draft-irtf-dtnrg-sdnv-06 is going to update RFC 5050, which has its
>>> own set of questions (an Informational document updating an
>>> Experimental document).
>>
>> No draft-irtf-dtnrg-sdnv-06 does not update rfc5050, its just
>> commentary and not specification. rfc5050 is the specification.
>> So I don't see a problem here.
> 
> See, I thought draft-irtf-dtnrg-sdnv-06 is the revised specification
> coming out of RFC5050 and RFC5326. The text says:
> 
>    SDNVs are tersely defined in both the bundle protocol [RFC5050] and
>    LTP [RFC5326] specifications, due to the flow of document production
>    in the DTNRG.  This document clarifies and further explains the
>    motivations and engineering decisions behind SDNVs.

"clarifies and further explains" != updates

> So which document is now the official definition? 

5050 (or 5326) as I said, and as draft-irtf-dtnrg-sdnv says.

[Aside: the fact that SDNVs are defined in both 5050 and
5326 is for historic reasons we don't need to get into and
would I hope be fixed were 5050 or 5326 revised.]

> Since the new ID is
> much more detailed, I thought it will update RFC5050 and RFC5326 so
> that there is a single well worked out definition that can also be
> used by other protocols should the need arise without a dependency on
> RFC5050 nor RFC5326.

That is not the case and is said in the document not to
be the case. If/when we get around to updating 5050 and 5326
then we may make use of the fact that draft-irtf-dtnrg-sdnv
contains explanations of why things were done. If someone
else wants to use the SDNV encoding then they would need
to reference 5050 or 5326.

I've heard many times that RFCs should exist that say why
design decisions were made etc. and draft-irtf-drnrg-sdnv
is one such attempt. I think that's a good thing and to
be encouraged and not discouraged.

And if I were to accept your argument, and take it to its
limit, then no one should be allowed further clarify an RFC,
in an RFC, without the latter formally updating the former.
Wouldn't such a rule just be a bad idea?

I really cannot see that this is at all unclear. But if you
still think it is please suggest text to include in
draft-irtf-dtnrg-sdnv that would solve what you perceive
to be the problem.

Stephen.

Date: Thu, 04 Mar 2010 12:39:05 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>, Internet Research Steering Group <[email-masked]>, Delay Tolerant Networking Interest List <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] Notification of IRSG poll start for draft-irtf-dtnrg-metadata-block

Hi Juergen,

Thanks for taking the time to review these.

On 03/04/2010 12:22 PM, Juergen Schoenwaelder wrote:
> On Wed, Feb 24, 2010 at 05:32:19PM +0100, Elwyn Davies wrote:
>> Dear IRSG Memeber,
>>
>> The DTN RG I-D: draft-irtf-dtnrg-metadata-block has
>> completed IRSG review.
>> The revised version of the I-D (Version 07) which incorporates the comments is
>> now available at:
>> http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
>> Loxia Zhang who has performed the IRSG review and the DTN RG have
>> approved the revised I-D to be progressed for publication.
>>
>> The IRSG review is available from the IRTF tracker web page at:
>> http://trac.tools.ietf.org/group/irtf/trac/ticket/33
>>
>> Please consider this email as the start of a four week IRSG poll. The
>> deadline for this poll is : Wednesday, March 24th, 2010.
>>
>> Please use one of the poll responses defined below.
>> The possible poll responses are:
>>
>>     o  'Ready to publish' -- requires a thorough read and reasonably
>>         detailed review
>>
>>     o  'Not ready to publish' -- requires a thorough read, reasonably
>>        detailed review, and actionable comments.
>>
>>     o  'No objection' -- I don't object if this document goes forward;
>>        I've read the document (perhaps quickly); I have some small
>>        comments which are not show stoppers; I don't have great
>>        expertise in the area.
>>
>>     o  'Request more time to review' -- a commitment to provide a
>>        thorough review in a specified period of time.
>>
>> The most relevant rule is that "At least two other IRSG members (besides the
>> one sponsoring the document) need to vote 'ready to publish' for the
>> document to move forward."
> 
> I read the document and I vote "Note ready to publish" for two
> reasons:
> 
> First, the IANA considerations sections seems to be at odds with
> section 4.2 which requires registration of metadata types. The IANA
> Considerations section, however, only loosely talks about "we may
> consider creating a registry". I believe the document should actually
> create the relevant registries and establish the necessary procedures.

Fair point. However, rfc5050 itself is really to blame here - it
should have created registries. But co-incidentally, just today,
(and literally 5 minutes before I saw your mail!) I've gotten
volunteers [1] to write an I-D to get BP registries created so we
are handling this. So I'd ask that we let this one go ahead on
the basis that the real sinner was rfc5050 and the RG are tackling
that to make up for all our past sins in one go?

> Second, I am wondering what the authoritative reference for SDNV
> encodings is going to be. This document refers to the bundle protocol
> specification but it is brought forward with a separate document
> defining SDNVs. This raises in fact the question whether
> draft-irtf-dtnrg-sdnv-06 is going to update RFC 5050, which has its
> own set of questions (an Informational document updating an
> Experimental document).

No draft-irtf-dtnrg-sdnv-06 does not update rfc5050, its just
commentary and not specification. rfc5050 is the specification.
So I don't see a problem here.

Stephen.

[1] http://mailman.dtnrg.org/pipermail/dtn-interest/2010-March/004611.html

> 
> /js
> 
> PS: Someone needs to forward my comments to the DTNRG mailing list
>     since I am not subscribed and the mailer simply rejects my emails.
> 

Date: Thu, 04 Mar 2010 12:32:14 +0000
From: Stephen Farrell <[email-masked]>
To: Daniel Ellard <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] IANA registries

Hi Dan,

On 03/04/2010 12:22 PM, Daniel Ellard wrote:
> Stephen Farrell wrote:
>> Hi all,
>>
>> An offlist discussion reminded me of something I'd meant to
>> ask.
>>
>> A number of BP drafts create new extension blocks and it'd
>> be good if we had an IANA registry for those. There are a few
>> other aspects of the BP that might benefit from registries
>> (ciphersuites at least).
>>
>> So, do folks agree that IANA registries would be useful? I
>> would imagine so. If so, would anyone have a bit of time to
>> write the required I-D?
> 
> I can start the ball rolling, 

That's great. Marc Blanchet also stepped up in an offlist
mail, so thanks to you both. Probably easiest if you share
the load. (Or whatever works for you is fine for me.)

> although I believe we are
> already in (or will be in, by the time I have something
> written down) the blackout period for -00 I-D's prior to
> Anaheim.

Right. But if you can shoot -00 out during the week, we can
discuss it anyway.

> 
> If you have an extension block that you're using for
> something you believe is of broad utility and should be
> standardized, please update the wiki:
> 
> http://www.dtnrg.org/wiki/AssignedNamesAndNumbers
> 
> In my opinion, the minimum criteria for inclusion in this
> list is either an I-D describing the use of the block type,
> or evidence on the mailing list of strong consensus about
> the importance of the block type prior to the submission of
> such an I-D.  (Of course, this is open to discussion too,
> because the existence of an I-D doesn't imply consensus, nor
> does consensus imply that an ID will be written promptly...)

We did create registries for LTP [1] (the IESG asked for them
during review) and in that case we said "specification required"
and (following IANA's advice) we also allocated a block for
private use and another block we reserved for the RG to handle
later. (That's when I learned that reserved != unassigned but
I've since forgotten the precise semantics:-)

I think that might be a good starting point here too. The
point about specification required is that e.g. a CCSDS doc,
or an ANSI spec could get an assignment then, not everything
would have to come via the RFC process.

Thanks again to you both,
Stephen.

[1] http://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml

> 
> -Dan
> 

Date: Thu, 04 Mar 2010 07:22:24 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Stephen Farrell <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] IANA registries

Stephen Farrell wrote:
> Hi all,
> 
> An offlist discussion reminded me of something I'd meant to
> ask.
> 
> A number of BP drafts create new extension blocks and it'd
> be good if we had an IANA registry for those. There are a few
> other aspects of the BP that might benefit from registries
> (ciphersuites at least).
> 
> So, do folks agree that IANA registries would be useful? I
> would imagine so. If so, would anyone have a bit of time to
> write the required I-D?

I can start the ball rolling, although I believe we are
already in (or will be in, by the time I have something
written down) the blackout period for -00 I-D's prior to
Anaheim.

If you have an extension block that you're using for
something you believe is of broad utility and should be
standardized, please update the wiki:

http://www.dtnrg.org/wiki/AssignedNamesAndNumbers

In my opinion, the minimum criteria for inclusion in this
list is either an I-D describing the use of the block type,
or evidence on the mailing list of strong consensus about
the importance of the block type prior to the submission of
such an I-D.  (Of course, this is open to discussion too,
because the existence of an I-D doesn't imply consensus, nor
does consensus imply that an ID will be written promptly...)

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Thu, 4 Mar 2010 12:48:46 +0100
From: Anders Lindgren <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] CFP: ExtremeCom 2010 - The Himalayan Expedition

Hi,

Apologies if you receive multiple copies. Should be of interest to
people working on DTN. Last year's workshop was very successful, with
participants being very happy with the experience, and we aim for an
equally good workshop this year.
Please note that the workshop is held the week after Sigcomm 2010
(which is in Delhi), so if you plan to attend Sigcomm, the extra
travel expenses for ExtremeCom will be small.
Also make sure to check the web site for the exciting opportunity
offered to the recipient of the best student paper award.

/Anders

--------

Call for Papers and Demos for The 2nd Extreme Workshop on Communication -
The Himalayan Expedition (ExtremeCom 2010)

September 4-10, 2010

The Extreme Workshop on Communication (ExtremeCom) intends to bring
together researchers and practitioners in areas related to challenged
networks in order to gain experience and insight into the challenges
that such environments pose for the network and the users. Such
networks include delay and disruption tolerant networks, sparse sensor
networks, power-efficient networking, as well as other networking
paradigms for rural and remote areas.

We aim to do this through a real-life experience in the Indian
Himalayan region. Dharamsala, where the workshop will take place, is a
well-frequented and loved destination for visitors. This mountainous
town presents a unique mix of cultures and spiritual traditions and is
also a starting point to a number of spectacular trekking trails.
Dharamsala is also the place where Dharamsala Community Network came
to life in February 2005, following the deregulation of WiFi for
outdoor use in India.  Built and operated by AirJaldi, a social
enterprise, the network grew from 8 campuses in 2005 to over 2,000
computers spread in campuses, offices and homes within a radius of
70Km. in and around Dharamsala.  AirJaldi is building additional
networks in other rural locations in India.
The ExtremeCom 2010 workshop is planned around AirJaldi’s Dharamsala
network’s locations and facilities, thereby giving participants a
great opportunity to be involved in a real-life network deployment.

The workshop will start with a four-day field trip into the mountain
regions around Dharamsala. During this time, participants will be
given the opportunity to hike along the trails in the mountains, visit
local villages and Tibetan settlements and meet the local population
and users of the network.  The combination of trekking and meetings
will give participants a better idea of both the technical and user
requirements of the network, as well as provide opportunities for
informal research discussions between the participants.

Participants who have their own solutions for scenarios like this will
also, to as great an extent as possible, be encouraged to test and
demonstrate it within this environment. (We are currently planning the
mountain-based part of the workshop and some details are subject to
change.) During the field trip, participants will be given the chance
to work with AirJaldi to set up more relays, for example in schools
along the hiking trail (details to be provided at a later stage).

Upon reaching the end of the hike, we will conduct a two-day technical
session in a more traditional conference venue with paper
presentations and demos. The focus will still be on informal research
discussions, with the hope that the recent field experience they have
gone through together will give participants the ability to view and
discuss the topics presented with additional insights.

Authors should submit a 6-page paper outlining ideas and visions about
the topics of the workshop or alternatively a 2-page proposal for a
demo to be shown during the workshop.  Visionary and thought-provoking
papers that are likely to generate much discussion during the workshop
are especially solicited.  The aim of the workshop is to maintain an
informal environment, where new research ideas can be discussed and
developed.

Topics for the workshop include, but are not limited to:
* Testbeds for large-scale sustainable testing of DTN systems
* Real deployments of networks in extreme environments
* Business and service models for networks in rural, remote, and other
challenging environments
* User experience research
* Delay tolerant networking
* Low-power and intermittent-power protocols
* Mechanisms for emergency and urgent communications
* Networked applications and services

Due to logistics and the need to conduct the workshop in harmony with
the local population and the environment, the number of participants
may be limited. Priority will be given to authors of papers.

*****************************************************************************
Important dates
---------------
Submission deadline: April 30, 2010
Notification of acceptance: May 30, 2010
Registration deadline: June 30, 2010
Workshop dates: September 4-10, 2010

*****************************************************************************
Organizers
----------
General co-chairs:
Anders Lindgren, Swedish Institute of Computer Science, Sweden
Pan Hui, Deutsche Telekom Laboratories and TU Berlin, Germany

Hosts:
AirJaldi.Org

Local arrangements chair:
Michael Ginguld, AirJaldi, India

Web chair:
Fehmi Ben Abdesslem, University of St. Andrews, UK

Technical Program Committee:
Bengt Ahlgren, Swedish Insitute of Computer Science, Sweden
Elizabeth M. Belding, University of California Santa Barbara, USA
Jon Crowcroft, University of Cambridge, UK
Elwyn Davies, Folly Consulting, UK
Avri Doria, Lulea University of Technology, Sweden
Kevin Fall, Intel Research Berkeley, USA
Stephen Farrell, Trinity College Dublin, Ireland
Michael Ginguld, AirJaldi, India
Tristan Henderson, University of St. Andrews, UK
S. Keshav, University of Waterloo, Canada
Cecilia Mascolo, University of Cambridge, UK
Jörg Ott, Helsinki University of Technology, Finland
Aaditeshwar Seth, IIT Delhi, India

Steering Committee:
Jon Crowcroft, University of Cambridge, UK
Avri Doria, Luleå University of Technology, Sweden
Tristan Henderson, University of St. Andrews, UK
Pan Hui, Deutsche Telekom Laboratories and TU Berlin, Germany
Anders Lindgren, Swedish Institute of Computer Science, Sweden

*****************************************************************************

Date: Thu, 04 Mar 2010 11:12:18 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] IANA registries

Hi all,

An offlist discussion reminded me of something I'd meant to
ask.

A number of BP drafts create new extension blocks and it'd
be good if we had an IANA registry for those. There are a few
other aspects of the BP that might benefit from registries
(ciphersuites at least).

So, do folks agree that IANA registries would be useful? I
would imagine so. If so, would anyone have a bit of time to
write the required I-D?

Thanks,
Stephen.

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Wed, 3 Mar 2010 12:24:46 +0000
Accept-Language: en-US, en-GB
acceptlanguage: en-US, en-GB
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

http://en.wikipedia.org/wiki/GSM-R

> A number of years ago I proposed a scenario of using DTN as a way to exchange
> status information between trains in a railway system - mainly as a toolset to
> exchange measurement information regarding rail status and congestion information
> between train-sets. This in combination with a high degree of intelligence in the
> mobile nodes for analysis of trends and changes in the rail status, vibration status
> across bridges, some basic status management of traffic patterns etc.

From: =?iso-8859-1?Q?Sten-Erik_Bj=F6rling?= <[email-masked]>
Date: Wed, 3 Mar 2010 12:29:37 +0100
To: Phani Rohit <[email-masked]>
Cc: DTN <[email-masked]>, Uday Kumar <[email-masked]>, "Chaudhari, Rohit K." <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Hi,

A number of years ago I proposed a scenario of using DTN as a way to exchange status information between trains in a railway system - mainly as a toolset to exchange measurement information regarding rail status and congestion information between train-sets. This in combination with a high degree of intelligence in the mobile nodes for analysis of trends and changes in the rail status, vibration status across bridges, some basic status management of traffic patterns etc.

By using data exchange between train sets and before passing bridges etc the system can act as a "semi-real-time" monitoring system for the status of rail sections, bridges, switches etc allowing the speed of the train to be optimally adapted for changed circumstances.

Much of the same structures can be used by implementing DTN as a information support system for rescue services etc retrieving fairly large data-sets by info-nodes on the way out to the rescue scene - getting the data while it is aggregated by the central servers. This was also proposed by me a couple of years ago.

A third proposal a number of years ago where how to integrate DTN with other communication links in rescue services command and control in combination with local MANETs. The DTN is not the main problem here as long as the environment can transfer a file from one point to another - the main challenges are the design of the application layer and the interaction with multiple, disparate information sources.

Take care,

Stene

_____

On 1 mar 2010, at 18.46, Phani Rohit wrote:

> Hi Rajesh,
> 
> This is first Rohit, Who started the conversation of using DTN's in New York
> subway stations. Let me address myself as  " PHANI ". [This is my pet name
> and just to avoid future confusion]
> 
> As " Chaudhari, Rohit " pointed out establishment cost is definitely a
> crucial factor. To add to this points i would say 'scalability' is the
> another  most important factor to choose DTN.  DTN has greater and better
> scope for scalability with respect to cost as well as the infrastructure. We
> can achieve maximum results with DTN than 3G or other internet.
> 
> And for the second question, the sub way station scenario would be a perfect
> application for multi hop DTN. Please see below for further explaination..
> 
> 1. When a user in train 1 wants to send message to outside world but he will
> not get in touch with the broker node sitting at next station for atleast
> next 10 min.
> 
> 2. but there is another train 'train 2' going in opposite direction which
> can carry your bundle and drop in other station where it gets connectivity
> in next 2-3 min
> 
> 3. Train 1 -- > Train 2 ---> DTN Node 1 [Broker Node sitting at station] ---
>> DTN Gateway [ Node 2 at same station, which has connectivity to the outer
> world]...
> 
> 4. so we can use the movement of trains for routing the bundles and
> calculate minimum delay path and transfer the bundles...
> 
> 5. Above mentioned is a simple scenario...even complex scenarios are
> possible...
> 
> Please let me know if you need any further explaination
> 
> Regards,
> Phani Rohit Mullangi (PhD)
> University of Georgia
> Athens GA

Sten-Erik Björling
Enviro Data
Kyrkogatan 5A 2 tr
SE-972 32  Luleå
Sweden

E-Mail: [email-masked]
Mobile: +46-70-655 11 72
Skype: stenerikbjorling
iChat: [email-masked]
Hotmail / Messenger: [email-masked]
GMail: [email-masked]

To: "Phani Rohit" <[email-masked]>
Date: Wed, 03 Mar 2010 11:58:10 +0100
From: $witch <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse : 2 trains analogy

On Mon, 01 Mar 2010 18:46:43 +0100, Phani Rohit <[email-masked]> wrote:

>
> And for the second question, the sub way station scenario would be a  
> perfect
> application for multi hop DTN. Please see below for further  
> explaination..
>
> 1. When a user in train 1 wants to send message to outside world but he  
> will
> not get in touch with the broker node sitting at next station for atleast
> next 10 min.
>
> 2. but there is another train 'train 2' going in opposite direction which
> can carry your bundle and drop in other station where it gets  
> connectivity
> in next 2-3 min
>
> 3. Train 1 -- > Train 2 ---> DTN Node 1 [Broker Node sitting at station]  
> ---
>> DTN Gateway [ Node 2 at same station, which has connectivity to the  
>> outer
> world]...
>
> 4. so we can use the movement of trains for routing the bundles and
> calculate minimum delay path and transfer the bundles...
>
> 5. Above mentioned is a simple scenario...even complex scenarios are
> possible...
>
> Please let me know if you need any further explaination
>

hi, Rohit

having no first-hand experience, hope to not post a foolish question :

when (1) the "message" goes out from user-1-device to user-2-device is
there any TCP-like ack ?

am very sorry to know no better way than the following to express what i
mean.... take it as best-effort to be understood by all readers.

if (connection-type == UDP-like) {

	msg ack(s) are at application level and there is no "simple" way to know
WHERE user-1 will "pop-up" again (just image tunnel-1 splits anywhere
AFTER train-1 and train-2 intersection or a temporary down of user1's
next-station-device) BEFORE he effectively reach any  
"station-with-working-devices".

any type of app(lication)-ack can't reach user-1 until he reconnect OR  
another train carries user-3-device that in turn carries the app-ack.

} else {

	we deal with delivery-guaranteed msg with ack(s) at transport layer
(maybe any layer lower than application).

	if (number_of_msg_copies == 1) {

		the msg must be crypted or "temporary msg carrier" can "hack" it,
application must ensure integrity, confidentiality, and so on

	} else {

		multiple copies, some may be manipulated by "hacker", must be delivered
to application that is responsable to "choose" the "original" msg between
one XOR more copies

	}
}

in any case there are major drawbacks, so i can't imagine a real-world
WORKING enviroment for that case.

while feel it as "possible", it is hard to consider that transport-analogy
as a competitor to "normal" IP.

finally, wish you all a smile @
http://imgs.xkcd.com/comics/devotion_to_duty.png

Alessandro

-- 
"It's hard to exploit a sysadmin by social engineering because he hardly
has any friends." Polytropon

From: Kevin Fall <[email-masked]>
Date: Mon, 1 Mar 2010 16:22:00 -0800
To: [email-masked]
Subject: [dtn-interest] SCHL draft

For those interested, I uploaded a -00 draft (DTN Scope Control using Hop Limits - SCHL) yesterday.
It does pretty much what it says-- defines an extension block to do scope control using a count-up
form of hop limit scoping.

- K

From: Phani Rohit <[email-masked]>
Date: Mon, 1 Mar 2010 15:14:14 -0500
To: Rajesh Krishnan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Chaudhari, Rohit K." <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

--0016e65ae5d6cb96380480c2e577
Content-Type: text/plain; charset=ISO-8859-1

Hi Rajesh,

We need not carry messages through others cell phones. We can take
inspiration from UMASS DTN test bed. [ http://prisms.cs.umass.edu/dome/] ..
the delay need not be in minutes if the frequency of the trains are
good...it can be in order of seconds..simulations might give an approximate
number...

Regards,
Phani.

On Mon, Mar 1, 2010 at 2:18 PM, Rajesh Krishnan <[email-masked]>wrote:

> Hi Phani,
>
> I think you propose a reasonable application that will exercise DTN/BP
> and multi-hop DTN routing.  The cost and scalability arguments for
> real world deployments are trickier to make for multi-hop DTN; I
> suppose it comes down to revenue models.   The latency gains in your
> analysis are in the same order of magnitude, i.e., units of minutes --
> in the email/SMS range, but not quite in the IM range.   Extending
> cell coverage into subway stations is already being done in many
> places, and that lets you do more than just SMS while waiting for the
> train.     This service will need to compete with that trend.
>
> I think there are three perspectives here (that I may be mixing somewhat):
>    (i) is there a strong application here with a reasonable
> business/revenue model
>   (ii) is there a strong advantage that DTN/BP provides in that
> application compared to other incumbents
>  (iii) is there a strong case for multi-hop DTN routing, as opposed
> to just nomadic end-points
>
> None of these questions have static answers, and can be asked again
> when resource trade-offs change.   But we must ask them in the context
> of trends we can reasonably project.
>
> The missing link for multi-party (your example is still single-party
> provider I think), multi-hop might well be a business that can assure
> some level of trust and resource accounting between handsets of
> strangers who are frequently disconnected from infrastructure.  What
> will convince strangers on the train cache, carry, and forward SMS
> messages for others?
>
> Coming back to your scenario, I expect that low-end LTE/WiMAX
> BS/relays will be quite inexpensive soon; regardless of the
> technology, installing and maintaining the box and service is going to
> dominate the costs, which mobile phone providers have a better way to
> recoup than a new entrant.   Would power line networking (ANSI/EIA 709
> or other) with possibly LED lighting in the tunnels provide continuous
> connectivity in the subway environment completely obviating need for
> DTN?
>
> Now, none of what I say above ought to deter R&D in DTN.
>
> Best Regards,
> Rajesh
>
>
>
> On Mon, Mar 1, 2010 at 12:46 PM, Phani Rohit <[email-masked]> wrote:
> > Hi Rajesh,
> > This is first Rohit, Who started the conversation of using DTN's in New
> York
> > subway stations. Let me address myself as  " PHANI ". [This is my pet
> name
> > and just to avoid future confusion]
> > As " Chaudhari, Rohit " pointed out establishment cost is definitely a
> > crucial factor. To add to this points i would say 'scalability' is the
> > another  most important factor to choose DTN.  DTN has greater and better
> > scope for scalability with respect to cost as well as the infrastructure.
> We
> > can achieve maximum results with DTN than 3G or other internet.
> > And for the second question, the sub way station scenario would be a
> perfect
> > application for multi hop DTN. Please see below for further
> explaination..
> > 1. When a user in train 1 wants to send message to outside world but he
> will
> > not get in touch with the broker node sitting at next station for atleast
> > next 10 min.
> > 2. but there is another train 'train 2' going in opposite direction which
> > can carry your bundle and drop in other station where it gets
> connectivity
> > in next 2-3 min
> > 3. Train 1 -- > Train 2 ---> DTN Node 1 [Broker Node sitting at station]
> ---
> >> DTN Gateway [ Node 2 at same station, which has connectivity to the
> outer
> > world]...
> > 4. so we can use the movement of trains for routing the bundles and
> > calculate minimum delay path and transfer the bundles...
> > 5. Above mentioned is a simple scenario...even complex scenarios are
> > possible...
> > Please let me know if you need any further explaination
> > Regards,
> > Phani Rohit Mullangi (PhD)
> > University of Georgia
> > Athens GA
> >
> >
> >
> > On Mon, Mar 1, 2010 at 11:01 AM, Chaudhari, Rohit K.
> > <[email-masked]> wrote:
> >>
> >> Hey Rajesh,
> >>
> >> The extension of 3G is also a great (and probably preferred) alternative
> >> since infrastructure is definitely more stable than queuing messages in
> the
> >> store-and-forward operations of DTN.  But the 3G coverage would vary
> network
> >> to network since some 3G providers do not have as extensive coverage.
> >>  Depending on the overall costs, DTN could be more cost efficient and be
> >> universal across all networks, I would presume, but I could be wrong
> here.
> >>  Even if 3G is expanded a more long-term goal with DTN could be greatly
> >> beneficial.  You do, however, bring up a valid point, but once again,
> cost
> >> is always a factor.
> >>
> >> -Rohit
> >>
> >> -----Original Message-----
> >> From: Rajesh Krishnan [mailto:[email-masked]]
> >> Sent: Monday, March 01, 2010 10:56 AM
> >> To: Chaudhari, Rohit K.
> >> Cc: [email-masked]; [email-masked]
> >> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse
> >>
> >> Rohit,
> >>
> >> This could be a useful service, but if all we did was extend 3G (or
> >> other Internet) coverage into the stations, will we get similar
> >> results?
> >> Is a multi-hop DTN necessary for this application? Endpoints can queue
> >> up messages till the next station where they connect to
> >> infrastructure.
> >>
> >> -Rajesh
> >>
> >>
> >> On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.
> >> <[email-masked]> wrote:
> >> > Hi all,
> >> >
> >> > My name is Rohit as well and I recently joined the DTN-interest
> mailing
> >> > list this morning.  As the other Rohit suggested, I too have recently
> read
> >> > about NYC subways.  Over 6 million people use the subway in NYC
> everyday and
> >> > to think that cell phone communications within them is pretty much
> >> > non-existent is pretty deplorable.  I know that at one point NYC
> wanted to
> >> > redo the cell infrastructure in the subways which would cost them tens
> of
> >> > millions of dollars, but they did also bring up the topic of DTN and
> using
> >> > it commercially.  This is definitely something that could be explored
> in the
> >> > future if a commercial angle seems appropriate.  Hope everyone is
> enjoying
> >> > their day so far. Let me know what you guys think.
> >> >
> >> > Thanks,
> >> >
> >> > Rohit
> >> >
> >> > -----Original Message-----
> >> > From: [email-masked]
> >> > [mailto:[email-masked]] On Behalf
> Of
> >> > [email-masked]
> >> > Sent: Monday, March 01, 2010 10:12 AM
> >> > To: [email-masked]
> >> > Subject: dtn-interest Digest, Vol 30, Issue 1
> >> >
> >> > Send dtn-interest mailing list submissions to
> >> >        [email-masked]
> >> >
> >> > To subscribe or unsubscribe via the World Wide Web, visit
> >> >
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> > or, via email, send a message with subject or body 'help' to
> >> >        [email-masked]
> >> >
> >> > You can reach the person managing the list at
> >> >        [email-masked]
> >> >
> >> > When replying, please edit your Subject line so it is more specific
> >> > than "Re: Contents of dtn-interest digest..."
> >> >
> >> >
> >> > Today's Topics:
> >> >
> >> >   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
> >> >   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
> >> >   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
> >> >   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
> >> >   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
> >> >
> >> >
> >> > ----------------------------------------------------------------------
> >> >
> >> > Message: 1
> >> > Date: Sun, 28 Feb 2010 17:27:29 -0500
> >> > From: Rajesh Krishnan <[email-masked]>
> >> > Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
> >> > To: [email-masked]
> >> > Message-ID:
> >> >        <[email-masked]>
> >> > Content-Type: text/plain; charset=ISO-8859-1
> >> >
> >> > I started implementing RFC5050 in Haskell, with a goal of fitting it
> >> > in less than 500 lines of code (which was roughly the size of the
> >> > Xmonad tiling window manager in 2007).
> >> > Clearly I had underestimated the challenge and did not get very far.
> >> > I figured I might as well set this free and move on.
> >> >
> >> > http://www.rajesh-krishnan.com/repos
> >> >
> >> > -Rajesh
> >> >
> >> > P.S.:  SDNV is a good exercise for a first course in functional
> >> > programming.   One that may cause CS students to pay attention to
> >> > DTN/BP as a side benefit.  :)
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> > Message: 2
> >> > Date: Mon, 1 Mar 2010 00:10:33 -0500
> >> > From: Phani Rohit <[email-masked]>
> >> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >> >        discourse
> >> > To: Rajesh Krishnan <[email-masked]>
> >> > Cc: [email-masked]
> >> > Message-ID:
> >> >        <[email-masked]>
> >> > Content-Type: text/plain; charset="iso-8859-1"
> >> >
> >> > Hi All,
> >> >
> >> > I am posting for the first time in this research group. Please excuse
> me
> >> > if
> >> > my idea does not make sense. I have an idea for using DTN's in day to
> >> > day
> >> > life. I don't know its commercial value.
> >> >
> >> > Recently I visited New York City, one of the busiest and happening
> >> > place.
> >> > The moment you get in to sub way station the communication with the
> >> > world is
> >> > lost. so  why can't any body have a simple DTN deployment like bunch
> of
> >> > broker nodes sitting at the opening of each station and route the
> >> > bundles
> >> > via moving trains and deliver it to outer world. A simple app in this
> >> > scenario would be SMS application running on DTN or chat client.
> >> >
> >> > Please let me know if this make sense  or if you need any further
> >> > explanation.
> >> >
> >> > Thanks,
> >> > Rohit
> >> >
> >> >
> >> > On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan
> >> > <[email-masked]>wrote:
> >> >
> >> >> Hi Brenton,
> >> >>
> >> >> Interesting game ideas.
> >> >>
> >> >> >From time to time, as my professional life has demanded, I have
> tried
> >> >> to use or work with BP.   I will happily be the fellow who is going
> to
> >> >> use BP, but the fact of the matter is I have not created or found a
> >> >> deployment/application that I can use in my daily life.
> >> >>
> >> >> There are several possible vectors that can achieve critical mass for
> >> >> DTN/BP:
> >> >>    - seeding into future-oriented systems (which some Government
> >> >> agencies have done), hoping it will grow big in a few decades
> >> >>    - a new application or a content overlay  that is generally
> >> >> useful, that happens to use BP, and grows popular rapidly  [ our
> >> >> current discussion ]
> >> >>    - through regulation or acquisition policy (may be as successful
> >> >> as GOSIP and Ada :)
> >> >>    - through education
> >> >>
> >> >> One idea was to see if it makes sense to explore BP in place of
> >> >> packetbb as a mechanism to gateway between diverse MANETs (require
> >> >> this as acquisition policy); one problem there is MANETs are still
> >> >> looking for their killer commercial application too.   As 3G/4G
> >> >> coverage increases, the need for multi-hop DTN routing will be
> >> >> increasingly pushed to challenging regimes of space, underground,
> >> >> underwater, etc.   There will be niche terrestrial opportunities
> >> >> (reindeer nets) and opportunities in virtual overlays (for
> distributed
> >> >> algorithm purists).
> >> >>
> >> >> Regardless of whether BP achieves population inversion or not (either
> >> >> over application overlay protocols or  Layer 2/3 encapsulations),
> >> >> important lessons can be learned from achieving critical mass around
> >> >> the BP.   Without critical mass, many of the ideas generated for ATM
> >> >> research would not have been; some of those ideas (or the competition
> >> >> they created) transformed IP networks.
> >> >>
> >> >> During one of my earlier briefings to the NSF FIND folks to explore
> >> >> synergies, I found they (i) wanted freedom from any constraints, BP
> or
> >> >>  otherwise, OR (ii) wanted critical mass such as that provided by
> >> >> TCP/IP and 802.11 in order to justify living with the constraints.
> >> >> There was some concern expressed around the ramp up time and
> perceived
> >> >> complexity of the BP.  In any case, I had failed to convince them of
> >> >> the enormous opportunity that was available in the middle ground --
> >> >> between clean slate and retrofit -- for novel routing and naming
> >> >> research.   BP offers a near clean slate, the benefits of an existing
> >> >> research community that provides the nucleus, and a good metadata
> >> >> extension block, especially for routing, naming, content-networking,
> >> >> and context/location-aware computing.  I have not given up hope;  BP
> >> >> on NSF GENI would be a good way to keep DTN/BP more relevant to the
> >> >> mainstream networking community.
> >> >>
> >> >> On the other hand, when I spoke to folks who do commercialization,
> >> >> their question to me was what is one thing you can do with the BP
> >> >> today  that they cannot hire programmers to do over other popular
> >> >> Internet-based technologies.  They can do meter reading, elevator
> net,
> >> >> email or content delivery to remote facilities using custom
> >> >> applications that are disruption-tolerant, and without buying into
> the
> >> >> full DTN/BP program.    Clearly they do not care about technical
> >> >> features, elegance, or potential for transformation provided by the
> >> >> DTN architecture.   Disruptive uses of the BP in settings would be
> >> >> interesting in order to exercise non-traditional routing and rich
> >> >> naming;  otherwise, the question of why not do it with SOAP (or
> >> >> alternative for which I can hire low-cost programmers) will persist?
> >> >> There need to see value additions that can be monetized in the short
> >> >> term.
> >> >>
> >> >> While all of the applications you mention will exercise the BP, all
> of
> >> >> them can be expeditiously done on an iPhone/Droid and can take
> >> >> advantage of remote servers.
> >> >> Regardless, the playing you suggest is better than the theorizing I
> >> >> provide above.
> >> >>
> >> >> Best Regards,
> >> >> Rajesh
> >> >>
> >> >> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <
> [email-masked]>
> >> >> wrote:
> >> >> > Hi Rajesh,
> >> >> >        Why is it always some other poor fellow who is going to use
> >> >> > BP?  I
> >> >> > think we should be trying to think of ways to use it ourselves in
> our
> >> >> > daily lives.  I feel like there are a lot of possibilities.  Even
> >> >> > though
> >> >> > access to expensive (3G, wimax) infrastructure is increasing,
> access
> >> >> > to
> >> >> > cheap infrastructure (open wifi APs) is getting more restrictive.
> >> >> >  Lots
> >> >> > of communication I do is pretty local, and BP (and associated
> >> >> > technologies) is a very robust tool for that sort of thing.
> >> >> >
> >> >> >        One thing people at our lab have been talking about is
> trying
> >> >> > to
> >> >> > organize some sort of BP-based activity at the IETF.  Not a
> >> >> > disconnectathon that focuses specifically on technical
> >> >> > interoperability,
> >> >> > but something that gives people a motivation to bring a handset or
> >> >> > laptop with a BPA on it and play with it during those boring
> sessions
> >> >> > they don't really care about.
> >> >> >
> >> >> > Some ideas we have had:
> >> >> > - bundle scavenger hunt.  There are bundles that can be found with
> >> >> > varying degrees of difficulty.  You get points for receiving them.
> >> >> > - bundle trivia.  Like the bundle scavenger hunt, but you would
> have
> >> >> > to
> >> >> > send responses to some EID.
> >> >> > - bundle mad libs.  I don't quite understand this one, but people
> >> >> > were
> >> >> > excited about it.
> >> >> > - bundle capture the flag.  OK, I'll stop.
> >> >> >
> >> >> > Stupid idea?
> >> >> > Already been done?
> >> >> >
> >> >> > Thanks,
> >> >> > Brenton
> >> >> >
> >> >> >
> >> >> >
> >> >> > Rajesh Krishnan wrote:
> >> >> >> In think in Parikh et al.'s application, DTN was useful to let
> chat
> >> >> >> participants catch up on the conversation they missed while they
> >> >> >> were
> >> >> >> temporarily disconnected; these are environments where end-to-end
> >> >> >> access to one server cannot be assured.
> >> >> >>
> >> >> >> The sailboat-based email delivery is definitely interesting.
> >> >> >>
> >> >> >> Best Regards,
> >> >> >> Rajesh
> >> >> >>
> >> >> >>
> >> >> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
> >> >> >> <[email-masked]> wrote:
> >> >> >>>> What I find strange is that the DTN community isn't trying to
> run
> >> >> email
> >> >> >>>> and chat over BP.  Those are natural applications for DTN, but
> yet
> >> >> >>>> there's not (to my knowledge) a release of an MTA, jabber
> client,
> >> >> jabber
> >> >> >>>> server, etc., that uses BP, and I don't hear anyone talking
> about
> >> >> having
> >> >> >>>> problems running those programs on the global dbone.
> >> >> >>>>
> >> >> >>>> Is anyone trying to use BP to do anything other than tests?
> >> >> >>> I can't see how a realtime application like jabber would be
> >> >> >>> something
> >> >> >>> DTN would address; surely disconnected jabber is email, no?
> >> >> >>>
> >> >> >>> One natural application for DTN is providing email service to
> >> >> >>> sailboats on the gulf coast of British Columbia.
> >> >> >>>
> >> >> >>> The stretch of water up the Strait from Vancouver to the north
> end
> >> >> >>> of
> >> >> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes
> of
> >> >> >>> cellular connectivity.  In almost every marina, email access is
> >> >> >>> found
> >> >> >>> by subscription only to services such as BBX.  There is no access
> >> >> >>> outside of the pay-per-mail marina wifi access points.
> >> >> >>>
> >> >> >>> There is no hope of running land-based network backhaul into most
> >> >> >>> of
> >> >> >>> the locations sailors would park in.  A BP-based email network is
> a
> >> >> >>> likely option for people on the coast living away from land-based
> >> >> >>> infrastructure.
> >> >> >>>
> >> >> >>> --lyndon
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> dtn-interest mailing list
> >> >> >> [email-masked]
> >> >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >> >>
> >> >> >
> >> >> > _______________________________________________
> >> >> > dtn-interest mailing list
> >> >> > [email-masked]
> >> >> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> dtn-interest mailing list
> >> >> [email-masked]
> >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >>
> >> > -------------- next part --------------
> >> > An HTML attachment was scrubbed...
> >> > URL:
> >> >
> http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html
> >> >
> >> > ------------------------------
> >> >
> >> > Message: 3
> >> > Date: Mon, 01 Mar 2010 09:02:54 -0500
> >> > From: Greg Troxel <[email-masked]>
> >> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >> >        discourse
> >> > To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
> >> > Cc: [email-masked]
> >> > Message-ID: <[email-masked]>
> >> > Content-Type: text/plain; charset="us-ascii"
> >> >
> >> >
> >> > "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:
> >> >
> >> >> I can't see how a realtime application like jabber would be something
> >> >> DTN would address; surely disconnected jabber is email, no?
> >> >
> >> > Disconnection can happen on many time scales.  If it's a few minutes,
> >> > it's still different than email, and you can still have presence
> >> > indications.
> >> >
> >> > Still, my real point is that until there's freely available code to
> plug
> >> > in alternate transports for things like pidgin, and enough dbone
> >> > infrastructure that people can actually use this, it's really hard to
> >> > know under what circumstances DTN will be really useful compared to
> what
> >> > we have now.
> >> > -------------- next part --------------
> >> > A non-text attachment was scrubbed...
> >> > Name: not available
> >> > Type: application/pgp-signature
> >> > Size: 194 bytes
> >> > Desc: not available
> >> > Url :
> >> >
> http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin
> >> >
> >> > ------------------------------
> >> >
> >> > Message: 4
> >> > Date: Mon, 01 Mar 2010 10:08:10 -0500
> >> > From: Daniel Ellard <[email-masked]>
> >> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >> >        discourse
> >> > To: Brenton Walker <[email-masked]>
> >> > Cc: [email-masked]
> >> > Message-ID: <[email-masked]>
> >> > Content-Type: text/plain; charset=ISO-8859-1
> >> >
> >> > Brenton Walker wrote:
> >> >> Hi Rajesh,
> >> >>       Why is it always some other poor fellow who is going to use BP?
> >> >
> >> > We might *all* be that poor fellow at some point:
> >> >
> >> >
> >> >
> http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007
> >> >
> >> > -Dan
> >> >
> >> > --
> >> > Daniel Ellard, Ph.D.
> >> > Senior Scientist, Network Research
> >> > BBN Technologies
> >> > 10 Moulton Street
> >> > Cambridge, MA 02138
> >> > [email-masked]
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> > Message: 5
> >> > Date: Mon, 01 Mar 2010 10:12:07 -0500
> >> > From: Daniel Ellard <[email-masked]>
> >> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >> >        discourse
> >> > To: Brenton Walker <[email-masked]>
> >> > Cc: [email-masked]
> >> > Message-ID: <[email-masked]>
> >> > Content-Type: text/plain; charset=ISO-8859-1
> >> >
> >> > Brenton Walker wrote:
> >> >> Hi Rajesh,
> >> >>       Why is it always some other poor fellow who is going to use BP?
> >> >>  I
> >> >> think we should be trying to think of ways to use it ourselves in our
> >> >> daily lives.  I feel like there are a lot of possibilities.  Even
> >> >> though
> >> >> access to expensive (3G, wimax) infrastructure is increasing, access
> to
> >> >> cheap infrastructure (open wifi APs) is getting more restrictive.
>  Lots
> >> >> of communication I do is pretty local, and BP (and associated
> >> >> technologies) is a very robust tool for that sort of thing.
> >> >
> >> > There's a group inside BBN who have been getting email and
> >> > web access (and maybe some other IP services) exclusively
> >> > via BP for a few months.  So far, so good.
> >> >
> >> >>       One thing people at our lab have been talking about is trying
> to
> >> >> organize some sort of BP-based activity at the IETF.  Not a
> >> >> disconnectathon that focuses specifically on technical
> >> >> interoperability,
> >> >> but something that gives people a motivation to bring a handset or
> >> >> laptop with a BPA on it and play with it during those boring sessions
> >> >> they don't really care about.
> >> >>
> >> >> Some ideas we have had:
> >> >> - bundle scavenger hunt.  There are bundles that can be found with
> >> >> varying degrees of difficulty.  You get points for receiving them.
> >> >> - bundle trivia.  Like the bundle scavenger hunt, but you would have
> to
> >> >> send responses to some EID.
> >> >> - bundle mad libs.  I don't quite understand this one, but people
> were
> >> >> excited about it.
> >> >> - bundle capture the flag.  OK, I'll stop.
> >> >
> >> > It sounds like fun.  Lots of work to set up, but fun, if you
> >> > can find volunteers.
> >> >
> >> > And you need to find someone very honest to be in charge of
> >> > disrupting the network in a completely fair manner...  :-)
> >> >
> >> > -Dan
> >> >
> >> >
> >> > --
> >> > Daniel Ellard, Ph.D.
> >> > Senior Scientist, Network Research
> >> > BBN Technologies
> >> > 10 Moulton Street
> >> > Cambridge, MA 02138
> >> > [email-masked]
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> > _______________________________________________
> >> > dtn-interest mailing list
> >> > [email-masked]
> >> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >
> >> >
> >> > End of dtn-interest Digest, Vol 30, Issue 1
> >> > *******************************************
> >> >
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> >
>

--0016e65ae5d6cb96380480c2e577
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Rajesh,<br><br>We need not carry messages through others cell phones. We=
 can take inspiration from UMASS DTN test bed. [ <a href=3D"http://prisms.c=
s.umass.edu/dome/">http://prisms.cs.umass.edu/dome/</a>] .. the delay need =
not be in minutes if the frequency of the trains are good...it can be in or=
der of seconds..simulations might give an approximate number... <br>

<br>Regards,<br>Phani.<br><br><br><br><div class=3D"gmail_quote">On Mon, Ma=
r 1, 2010 at 2:18 PM, Rajesh Krishnan <span dir=3D"ltr">&lt;<a href=3D"mail=
to:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 20=
4, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi Phani,<br>
<br>
I think you propose a reasonable application that will exercise DTN/BP<br>
and multi-hop DTN routing. =A0The cost and scalability arguments for<br>
real world deployments are trickier to make for multi-hop DTN; I<br>
suppose it comes down to revenue models. =A0 The latency gains in your<br>
analysis are in the same order of magnitude, i.e., units of minutes --<br>
in the email/SMS range, but not quite in the IM range. =A0 Extending<br>
cell coverage into subway stations is already being done in many<br>
places, and that lets you do more than just SMS while waiting for the<br>
train. =A0 =A0 This service will need to compete with that trend.<br>
<br>
I think there are three perspectives here (that I may be mixing somewhat):<=
br>
 =A0 =A0(i) is there a strong application here with a reasonable<br>
business/revenue model<br>
 =A0 (ii) is there a strong advantage that DTN/BP provides in that<br>
application compared to other incumbents<br>
 =A0(iii) is there a strong case for multi-hop DTN routing, as opposed<br>
to just nomadic end-points<br>
<br>
None of these questions have static answers, and can be asked again<br>
when resource trade-offs change. =A0 But we must ask them in the context<br=
>
of trends we can reasonably project.<br>
<br>
The missing link for multi-party (your example is still single-party<br>
provider I think), multi-hop might well be a business that can assure<br>
some level of trust and resource accounting between handsets of<br>
strangers who are frequently disconnected from infrastructure. =A0What<br>
will convince strangers on the train cache, carry, and forward SMS<br>
messages for others?<br>
<br>
Coming back to your scenario, I expect that low-end LTE/WiMAX<br>
BS/relays will be quite inexpensive soon; regardless of the<br>
technology, installing and maintaining the box and service is going to<br>
dominate the costs, which mobile phone providers have a better way to<br>
recoup than a new entrant. =A0 Would power line networking (ANSI/EIA 709<br=
>
or other) with possibly LED lighting in the tunnels provide continuous<br>
connectivity in the subway environment completely obviating need for<br>
DTN?<br>
<br>
Now, none of what I say above ought to deter R&amp;D in DTN.<br>
<br>
Best Regards,<br>
<font color=3D"#888888">Rajesh<br>
</font><div><div></div><div class=3D"h5"><br>
<br>
<br>
On Mon, Mar 1, 2010 at 12:46 PM, Phani Rohit &lt;<a href=3D"mailto:mprohit@=
gmail.com">[email-masked]</a>&gt; wrote:<br>
&gt; Hi Rajesh,<br>
&gt; This is first Rohit, Who started the conversation of using DTN&#39;s i=
n New York<br>
&gt; subway stations. Let me address myself as =A0&quot; PHANI &quot;. [Thi=
s is my pet name<br>
&gt; and just to avoid future confusion]<br>
&gt; As &quot; Chaudhari, Rohit &quot; pointed out=A0establishment=A0cost i=
s definitely a<br>
&gt; crucial factor. To add to this points i would say &#39;scalability&#39=
; is the<br>
&gt; another =A0most important factor to choose DTN. =A0DTN has greater and=
 better<br>
&gt; scope for=A0scalability with respect to cost as well as the=A0infrastr=
ucture. We<br>
&gt; can achieve maximum results with DTN than 3G or other internet.<br>
&gt; And for the second question, the sub way station scenario would be a p=
erfect<br>
&gt; application for multi hop DTN. Please see below for further explainati=
on..<br>
&gt; 1. When a user in train 1 wants to send message to outside world but h=
e will<br>
&gt; not get in touch with the broker node sitting at next=A0station for at=
least<br>
&gt; next 10 min.<br>
&gt; 2. but there is another train &#39;train 2&#39; going in opposite dire=
ction which<br>
&gt; can carry your bundle and drop in other station where it gets connecti=
vity<br>
&gt; in next 2-3 min<br>
&gt; 3. Train 1 -- &gt; Train 2 ---&gt; DTN Node 1 [Broker Node sitting at =
station] ---<br>
&gt;&gt; DTN Gateway [ Node 2 at same station, which has connectivity to th=
e outer<br>
&gt; world]...<br>
&gt; 4. so we can use the movement of trains for routing the bundles and<br=
>
&gt; calculate minimum delay path and transfer the bundles...<br>
&gt; 5. Above mentioned is a simple scenario...even complex scenarios are<b=
r>
&gt; possible...<br>
&gt; Please let me know if you need any further explaination<br>
&gt; Regards,<br>
&gt; Phani Rohit Mullangi (PhD)<br>
&gt; University of Georgia<br>
&gt; Athens GA<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Mar 1, 2010 at 11:01 AM, Chaudhari, Rohit K.<br>
&gt; &lt;<a href=3D"mailto:[email-masked]">Rohit.Chaudhari@jhua=
pl.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hey Rajesh,<br>
&gt;&gt;<br>
&gt;&gt; The extension of 3G is also a great (and probably preferred) alter=
native<br>
&gt;&gt; since infrastructure is definitely more stable than queuing messag=
es in the<br>
&gt;&gt; store-and-forward operations of DTN. =A0But the 3G coverage would =
vary network<br>
&gt;&gt; to network since some 3G providers do not have as extensive covera=
ge.<br>
&gt;&gt; =A0Depending on the overall costs, DTN could be more cost efficien=
t and be<br>
&gt;&gt; universal across all networks, I would presume, but I could be wro=
ng here.<br>
&gt;&gt; =A0Even if 3G is expanded a more long-term goal with DTN could be =
greatly<br>
&gt;&gt; beneficial. =A0You do, however, bring up a valid point, but once a=
gain, cost<br>
&gt;&gt; is always a factor.<br>
&gt;&gt;<br>
&gt;&gt; -Rohit<br>
&gt;&gt;<br>
&gt;&gt; -----Original Message-----<br>
&gt;&gt; From: Rajesh Krishnan [mailto:<a href=3D"mailto:rjsh.krshnn@gmail.=
com">[email-masked]</a>]<br>
&gt;&gt; Sent: Monday, March 01, 2010 10:56 AM<br>
&gt;&gt; To: Chaudhari, Rohit K.<br>
&gt;&gt; Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a>; <a=
 href=3D"mailto:[email-masked]">[email-masked].=
org</a><br>
&gt;&gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of =
discourse<br>
&gt;&gt;<br>
&gt;&gt; Rohit,<br>
&gt;&gt;<br>
&gt;&gt; This could be a useful service, but if all we did was extend 3G (o=
r<br>
&gt;&gt; other Internet) coverage into the stations, will we get similar<br=
>
&gt;&gt; results?<br>
&gt;&gt; Is a multi-hop DTN necessary for this application? Endpoints can q=
ueue<br>
&gt;&gt; up messages till the next station where they connect to<br>
&gt;&gt; infrastructure.<br>
&gt;&gt;<br>
&gt;&gt; -Rajesh<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.<br>
&gt;&gt; &lt;<a href=3D"mailto:[email-masked]">Rohit.Chaudhari@=
jhuapl.edu</a>&gt; wrote:<br>
&gt;&gt; &gt; Hi all,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; My name is Rohit as well and I recently joined the DTN-intere=
st mailing<br>
&gt;&gt; &gt; list this morning. =A0As the other Rohit suggested, I too hav=
e recently read<br>
&gt;&gt; &gt; about NYC subways. =A0Over 6 million people use the subway in=
 NYC everyday and<br>
&gt;&gt; &gt; to think that cell phone communications within them is pretty=
 much<br>
&gt;&gt; &gt; non-existent is pretty deplorable. =A0I know that at one poin=
t NYC wanted to<br>
&gt;&gt; &gt; redo the cell infrastructure in the subways which would cost =
them tens of<br>
&gt;&gt; &gt; millions of dollars, but they did also bring up the topic of =
DTN and using<br>
&gt;&gt; &gt; it commercially. =A0This is definitely something that could b=
e explored in the<br>
&gt;&gt; &gt; future if a commercial angle seems appropriate. =A0Hope every=
one is enjoying<br>
&gt;&gt; &gt; their day so far. Let me know what you guys think.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Rohit<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -----Original Message-----<br>
&gt;&gt; &gt; From: <a href=3D"mailto:[email-masked]=
research.net">[email-masked]</a><br>
&gt;&gt; &gt; [mailto:<a href=3D"mailto:[email-masked]=
l-research.net">[email-masked]</a>] On B=
ehalf Of<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]=
ch.net">[email-masked]</a><br>
&gt;&gt; &gt; Sent: Monday, March 01, 2010 10:12 AM<br>
&gt;&gt; &gt; To: <a href=3D"mailto:[email-masked]=
et">[email-masked]</a><br>
&gt;&gt; &gt; Subject: dtn-interest Digest, Vol 30, Issue 1<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Send dtn-interest mailing list submissions to<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0<a href=3D"mailto:[email-masked]=
-research.net">[email-masked]</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; To subscribe or unsubscribe via the World Wide Web, visit<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0<a href=3D"http://maillists.intel-research.net=
/mailman/listinfo/dtn-interest" target=3D"_blank">http://maillists.intel-re=
search.net/mailman/listinfo/dtn-interest</a><br>
&gt;&gt; &gt; or, via email, send a message with subject or body &#39;help&=
#39; to<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0<a href=3D"mailto:dtn-interest-request@maillis=
ts.intel-research.net">[email-masked]</a=
><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You can reach the person managing the list at<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0<a href=3D"mailto:dtn-interest-owner@maillists=
.intel-research.net">[email-masked]</a><br=
>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; When replying, please edit your Subject line so it is more sp=
ecific<br>
&gt;&gt; &gt; than &quot;Re: Contents of dtn-interest digest...&quot;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Today&#39;s Topics:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; =A0 1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan=
)<br>
&gt;&gt; &gt; =A0 2. Re: DTNRG: let&#39;s elevate the level of discourse (P=
hani Rohit)<br>
&gt;&gt; &gt; =A0 3. Re: DTNRG: let&#39;s elevate the level of discourse (G=
reg Troxel)<br>
&gt;&gt; &gt; =A0 4. Re: DTNRG: let&#39;s elevate the level of discourse (D=
aniel Ellard)<br>
&gt;&gt; &gt; =A0 5. Re: DTNRG: let&#39;s elevate the level of discourse (D=
aniel Ellard)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -------------------------------------------------------------=
---------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Message: 1<br>
&gt;&gt; &gt; Date: Sun, 28 Feb 2010 17:27:29 -0500<br>
&gt;&gt; &gt; From: Rajesh Krishnan &lt;<a href=3D"mailto:rjsh.krshnn@gmail=
.com">[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Subject: [dtn-interest] sketch of RFC5050 portions in Haskell=
<br>
&gt;&gt; &gt; To: <a href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a><br>
&gt;&gt; &gt; Message-ID:<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:ebcd90ee1002281427h31321=
[email-masked]">ebcd90ee1002281427h3132144q6b873a909984=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I started implementing RFC5050 in Haskell, with a goal of fit=
ting it<br>
&gt;&gt; &gt; in less than 500 lines of code (which was roughly the size of=
 the<br>
&gt;&gt; &gt; Xmonad tiling window manager in 2007).<br>
&gt;&gt; &gt; Clearly I had underestimated the challenge and did not get ve=
ry far.<br>
&gt;&gt; &gt; I figured I might as well set this free and move on.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; <a href=3D"http://www.rajesh-krishnan.com/repos" target=3D"_b=
lank">http://www.rajesh-krishnan.com/repos</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -Rajesh<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; P.S.: =A0SDNV is a good exercise for a first course in functi=
onal<br>
&gt;&gt; &gt; programming. =A0 One that may cause CS students to pay attent=
ion to<br>
&gt;&gt; &gt; DTN/BP as a side benefit. =A0:)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ------------------------------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Message: 2<br>
&gt;&gt; &gt; Date: Mon, 1 Mar 2010 00:10:33 -0500<br>
&gt;&gt; &gt; From: Phani Rohit &lt;<a href=3D"mailto:[email-masked]">mp=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the leve=
l of<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0discourse<br>
&gt;&gt; &gt; To: Rajesh Krishnan &lt;<a href=3D"mailto:[email-masked]=
om">[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Cc: <a href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a><br>
&gt;&gt; &gt; Message-ID:<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:38f37aa41002282110m49461=
[email-masked]">38f37aa41002282110m4946139etee6a45e142=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Content-Type: text/plain; charset=3D&quot;iso-8859-1&quot;<br=
>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hi All,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I am posting for the first time in this research group. Pleas=
e excuse me<br>
&gt;&gt; &gt; if<br>
&gt;&gt; &gt; my idea does not make sense. I have an idea for using DTN&#39=
;s in day to<br>
&gt;&gt; &gt; day<br>
&gt;&gt; &gt; life. I don&#39;t know its commercial value.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Recently I visited New York City, one of the busiest and happ=
ening<br>
&gt;&gt; &gt; place.<br>
&gt;&gt; &gt; The moment you get in to sub way station the communication wi=
th the<br>
&gt;&gt; &gt; world is<br>
&gt;&gt; &gt; lost. so =A0why can&#39;t any body have a simple DTN deployme=
nt like bunch of<br>
&gt;&gt; &gt; broker nodes sitting at the opening of each station and route=
 the<br>
&gt;&gt; &gt; bundles<br>
&gt;&gt; &gt; via moving trains and deliver it to outer world. A simple app=
 in this<br>
&gt;&gt; &gt; scenario would be SMS application running on DTN or chat clie=
nt.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Please let me know if this make sense =A0or if you need any f=
urther<br>
&gt;&gt; &gt; explanation.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt; Rohit<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan<br>
&gt;&gt; &gt; &lt;<a href=3D"mailto:[email-masked]">rjsh.krshnn@gmai=
l.com</a>&gt;wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; Hi Brenton,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Interesting game ideas.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;From time to time, as my professional life has demand=
ed, I have tried<br>
&gt;&gt; &gt;&gt; to use or work with BP. =A0 I will happily be the fellow =
who is going to<br>
&gt;&gt; &gt;&gt; use BP, but the fact of the matter is I have not created =
or found a<br>
&gt;&gt; &gt;&gt; deployment/application that I can use in my daily life.<b=
r>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; There are several possible vectors that can achieve criti=
cal mass for<br>
&gt;&gt; &gt;&gt; DTN/BP:<br>
&gt;&gt; &gt;&gt; =A0 =A0- seeding into future-oriented systems (which some=
 Government<br>
&gt;&gt; &gt;&gt; agencies have done), hoping it will grow big in a few dec=
ades<br>
&gt;&gt; &gt;&gt; =A0 =A0- a new application or a content overlay =A0that i=
s generally<br>
&gt;&gt; &gt;&gt; useful, that happens to use BP, and grows popular rapidly=
 =A0[ our<br>
&gt;&gt; &gt;&gt; current discussion ]<br>
&gt;&gt; &gt;&gt; =A0 =A0- through regulation or acquisition policy (may be=
 as successful<br>
&gt;&gt; &gt;&gt; as GOSIP and Ada :)<br>
&gt;&gt; &gt;&gt; =A0 =A0- through education<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; One idea was to see if it makes sense to explore BP in pl=
ace of<br>
&gt;&gt; &gt;&gt; packetbb as a mechanism to gateway between diverse MANETs=
 (require<br>
&gt;&gt; &gt;&gt; this as acquisition policy); one problem there is MANETs =
are still<br>
&gt;&gt; &gt;&gt; looking for their killer commercial application too. =A0 =
As 3G/4G<br>
&gt;&gt; &gt;&gt; coverage increases, the need for multi-hop DTN routing wi=
ll be<br>
&gt;&gt; &gt;&gt; increasingly pushed to challenging regimes of space, unde=
rground,<br>
&gt;&gt; &gt;&gt; underwater, etc. =A0 There will be niche terrestrial oppo=
rtunities<br>
&gt;&gt; &gt;&gt; (reindeer nets) and opportunities in virtual overlays (fo=
r distributed<br>
&gt;&gt; &gt;&gt; algorithm purists).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Regardless of whether BP achieves population inversion or=
 not (either<br>
&gt;&gt; &gt;&gt; over application overlay protocols or =A0Layer 2/3 encaps=
ulations),<br>
&gt;&gt; &gt;&gt; important lessons can be learned from achieving critical =
mass around<br>
&gt;&gt; &gt;&gt; the BP. =A0 Without critical mass, many of the ideas gene=
rated for ATM<br>
&gt;&gt; &gt;&gt; research would not have been; some of those ideas (or the=
 competition<br>
&gt;&gt; &gt;&gt; they created) transformed IP networks.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; During one of my earlier briefings to the NSF FIND folks =
to explore<br>
&gt;&gt; &gt;&gt; synergies, I found they (i) wanted freedom from any const=
raints, BP or<br>
&gt;&gt; &gt;&gt; =A0otherwise, OR (ii) wanted critical mass such as that p=
rovided by<br>
&gt;&gt; &gt;&gt; TCP/IP and 802.11 in order to justify living with the con=
straints.<br>
&gt;&gt; &gt;&gt; There was some concern expressed around the ramp up time =
and perceived<br>
&gt;&gt; &gt;&gt; complexity of the BP. =A0In any case, I had failed to con=
vince them of<br>
&gt;&gt; &gt;&gt; the enormous opportunity that was available in the middle=
 ground --<br>
&gt;&gt; &gt;&gt; between clean slate and retrofit -- for novel routing and=
 naming<br>
&gt;&gt; &gt;&gt; research. =A0 BP offers a near clean slate, the benefits =
of an existing<br>
&gt;&gt; &gt;&gt; research community that provides the nucleus, and a good =
metadata<br>
&gt;&gt; &gt;&gt; extension block, especially for routing, naming, content-=
networking,<br>
&gt;&gt; &gt;&gt; and context/location-aware computing. =A0I have not given=
 up hope; =A0BP<br>
&gt;&gt; &gt;&gt; on NSF GENI would be a good way to keep DTN/BP more relev=
ant to the<br>
&gt;&gt; &gt;&gt; mainstream networking community.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On the other hand, when I spoke to folks who do commercia=
lization,<br>
&gt;&gt; &gt;&gt; their question to me was what is one thing you can do wit=
h the BP<br>
&gt;&gt; &gt;&gt; today =A0that they cannot hire programmers to do over oth=
er popular<br>
&gt;&gt; &gt;&gt; Internet-based technologies. =A0They can do meter reading=
, elevator net,<br>
&gt;&gt; &gt;&gt; email or content delivery to remote facilities using cust=
om<br>
&gt;&gt; &gt;&gt; applications that are disruption-tolerant, and without bu=
ying into the<br>
&gt;&gt; &gt;&gt; full DTN/BP program. =A0 =A0Clearly they do not care abou=
t technical<br>
&gt;&gt; &gt;&gt; features, elegance, or potential for transformation provi=
ded by the<br>
&gt;&gt; &gt;&gt; DTN architecture. =A0 Disruptive uses of the BP in settin=
gs would be<br>
&gt;&gt; &gt;&gt; interesting in order to exercise non-traditional routing =
and rich<br>
&gt;&gt; &gt;&gt; naming; =A0otherwise, the question of why not do it with =
SOAP (or<br>
&gt;&gt; &gt;&gt; alternative for which I can hire low-cost programmers) wi=
ll persist?<br>
&gt;&gt; &gt;&gt; There need to see value additions that can be monetized i=
n the short<br>
&gt;&gt; &gt;&gt; term.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; While all of the applications you mention will exercise t=
he BP, all of<br>
&gt;&gt; &gt;&gt; them can be expeditiously done on an iPhone/Droid and can=
 take<br>
&gt;&gt; &gt;&gt; advantage of remote servers.<br>
&gt;&gt; &gt;&gt; Regardless, the playing you suggest is better than the th=
eorizing I<br>
&gt;&gt; &gt;&gt; provide above.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Best Regards,<br>
&gt;&gt; &gt;&gt; Rajesh<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker &lt;<a h=
ref=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt; Hi Rajesh,<br>
&gt;&gt; &gt;&gt; &gt; =A0 =A0 =A0 =A0Why is it always some other poor fell=
ow who is going to use<br>
&gt;&gt; &gt;&gt; &gt; BP? =A0I<br>
&gt;&gt; &gt;&gt; &gt; think we should be trying to think of ways to use it=
 ourselves in our<br>
&gt;&gt; &gt;&gt; &gt; daily lives. =A0I feel like there are a lot of possi=
bilities. =A0Even<br>
&gt;&gt; &gt;&gt; &gt; though<br>
&gt;&gt; &gt;&gt; &gt; access to expensive (3G, wimax) infrastructure is in=
creasing, access<br>
&gt;&gt; &gt;&gt; &gt; to<br>
&gt;&gt; &gt;&gt; &gt; cheap infrastructure (open wifi APs) is getting more=
 restrictive.<br>
&gt;&gt; &gt;&gt; &gt; =A0Lots<br>
&gt;&gt; &gt;&gt; &gt; of communication I do is pretty local, and BP (and a=
ssociated<br>
&gt;&gt; &gt;&gt; &gt; technologies) is a very robust tool for that sort of=
 thing.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; =A0 =A0 =A0 =A0One thing people at our lab have been=
 talking about is trying<br>
&gt;&gt; &gt;&gt; &gt; to<br>
&gt;&gt; &gt;&gt; &gt; organize some sort of BP-based activity at the IETF.=
 =A0Not a<br>
&gt;&gt; &gt;&gt; &gt; disconnectathon that focuses specifically on technic=
al<br>
&gt;&gt; &gt;&gt; &gt; interoperability,<br>
&gt;&gt; &gt;&gt; &gt; but something that gives people a motivation to brin=
g a handset or<br>
&gt;&gt; &gt;&gt; &gt; laptop with a BPA on it and play with it during thos=
e boring sessions<br>
&gt;&gt; &gt;&gt; &gt; they don&#39;t really care about.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Some ideas we have had:<br>
&gt;&gt; &gt;&gt; &gt; - bundle scavenger hunt. =A0There are bundles that c=
an be found with<br>
&gt;&gt; &gt;&gt; &gt; varying degrees of difficulty. =A0You get points for=
 receiving them.<br>
&gt;&gt; &gt;&gt; &gt; - bundle trivia. =A0Like the bundle scavenger hunt, =
but you would have<br>
&gt;&gt; &gt;&gt; &gt; to<br>
&gt;&gt; &gt;&gt; &gt; send responses to some EID.<br>
&gt;&gt; &gt;&gt; &gt; - bundle mad libs. =A0I don&#39;t quite understand t=
his one, but people<br>
&gt;&gt; &gt;&gt; &gt; were<br>
&gt;&gt; &gt;&gt; &gt; excited about it.<br>
&gt;&gt; &gt;&gt; &gt; - bundle capture the flag. =A0OK, I&#39;ll stop.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Stupid idea?<br>
&gt;&gt; &gt;&gt; &gt; Already been done?<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt;&gt; &gt; Brenton<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Rajesh Krishnan wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt; In think in Parikh et al.&#39;s application, DTN=
 was useful to let chat<br>
&gt;&gt; &gt;&gt; &gt;&gt; participants catch up on the conversation they m=
issed while they<br>
&gt;&gt; &gt;&gt; &gt;&gt; were<br>
&gt;&gt; &gt;&gt; &gt;&gt; temporarily disconnected; these are environments=
 where end-to-end<br>
&gt;&gt; &gt;&gt; &gt;&gt; access to one server cannot be assured.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; The sailboat-based email delivery is definitely =
interesting.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Best Regards,<br>
&gt;&gt; &gt;&gt; &gt;&gt; Rajesh<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenber=
g (VE6BBM/VE7TFX)<br>
&gt;&gt; &gt;&gt; &gt;&gt; &lt;<a href=3D"mailto:[email-masked]">lyndon@=
orthanc.ca</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; What I find strange is that the DTN comm=
unity isn&#39;t trying to run<br>
&gt;&gt; &gt;&gt; email<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; and chat over BP. =A0Those are natural a=
pplications for DTN, but yet<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; there&#39;s not (to my knowledge) a rele=
ase of an MTA, jabber client,<br>
&gt;&gt; &gt;&gt; jabber<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; server, etc., that uses BP, and I don&#3=
9;t hear anyone talking about<br>
&gt;&gt; &gt;&gt; having<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; problems running those programs on the g=
lobal dbone.<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;&gt; Is anyone trying to use BP to do anythin=
g other than tests?<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; I can&#39;t see how a realtime application l=
ike jabber would be<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; something<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; DTN would address; surely disconnected jabbe=
r is email, no?<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; One natural application for DTN is providing=
 email service to<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; sailboats on the gulf coast of British Colum=
bia.<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; The stretch of water up the Strait from Vanc=
ouver to the north end<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; of<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; Vancouver Is. is a patchwork of fjords, isle=
ts, and black holes of<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; cellular connectivity. =A0In almost every ma=
rina, email access is<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; found<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; by subscription only to services such as BBX=
. =A0There is no access<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; outside of the pay-per-mail marina wifi acce=
ss points.<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; There is no hope of running land-based netwo=
rk backhaul into most<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; of<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; the locations sailors would park in. =A0A BP=
-based email network is a<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; likely option for people on the coast living=
 away from land-based<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; infrastructure.<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; --lyndon<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; _______________________________________________<=
br>
&gt;&gt; &gt;&gt; &gt;&gt; dtn-interest mailing list<br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href=3D"mailto:[email-masked]=
esearch.net">[email-masked]</a><br>
&gt;&gt; &gt;&gt; &gt;&gt; <a href=3D"http://maillists.intel-research.net/m=
ailman/listinfo/dtn-interest" target=3D"_blank">http://maillists.intel-rese=
arch.net/mailman/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; &gt; dtn-interest mailing list<br>
&gt;&gt; &gt;&gt; &gt; <a href=3D"mailto:[email-masked]=
rch.net">[email-masked]</a><br>
&gt;&gt; &gt;&gt; &gt; <a href=3D"http://maillists.intel-research.net/mailm=
an/listinfo/dtn-interest" target=3D"_blank">http://maillists.intel-research=
.net/mailman/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; dtn-interest mailing list<br>
&gt;&gt; &gt;&gt; <a href=3D"mailto:[email-masked]=
et">[email-masked]</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://maillists.intel-research.net/mailman/li=
stinfo/dtn-interest" target=3D"_blank">http://maillists.intel-research.net/=
mailman/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt; -------------- next part --------------<br>
&gt;&gt; &gt; An HTML attachment was scrubbed...<br>
&gt;&gt; &gt; URL:<br>
&gt;&gt; &gt; <a href=3D"http://maillists.intel-research.net/pipermail/dtn-=
interest/attachments/20100301/5528783a/attachment-0001.html" target=3D"_bla=
nk">http://maillists.intel-research.net/pipermail/dtn-interest/attachments/=
20100301/5528783a/attachment-0001.html</a><br>

&gt;&gt; &gt;<br>
&gt;&gt; &gt; ------------------------------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Message: 3<br>
&gt;&gt; &gt; Date: Mon, 01 Mar 2010 09:02:54 -0500<br>
&gt;&gt; &gt; From: Greg Troxel &lt;<a href=3D"mailto:[email-masked]">gdt@i=
r.bbn.com</a>&gt;<br>
&gt;&gt; &gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the leve=
l of<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0discourse<br>
&gt;&gt; &gt; To: &quot;Lyndon Nerenberg \(VE6BBM\/VE7TFX\)&quot; &lt;<a hr=
ef=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Cc: <a href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a><br>
&gt;&gt; &gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]=
n.com">[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Content-Type: text/plain; charset=3D&quot;us-ascii&quot;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &quot;Lyndon Nerenberg (VE6BBM/VE7TFX)&quot; =A0&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; writes:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; I can&#39;t see how a realtime application like jabber wo=
uld be something<br>
&gt;&gt; &gt;&gt; DTN would address; surely disconnected jabber is email, n=
o?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Disconnection can happen on many time scales. =A0If it&#39;s =
a few minutes,<br>
&gt;&gt; &gt; it&#39;s still different than email, and you can still have p=
resence<br>
&gt;&gt; &gt; indications.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Still, my real point is that until there&#39;s freely availab=
le code to plug<br>
&gt;&gt; &gt; in alternate transports for things like pidgin, and enough db=
one<br>
&gt;&gt; &gt; infrastructure that people can actually use this, it&#39;s re=
ally hard to<br>
&gt;&gt; &gt; know under what circumstances DTN will be really useful compa=
red to what<br>
&gt;&gt; &gt; we have now.<br>
&gt;&gt; &gt; -------------- next part --------------<br>
&gt;&gt; &gt; A non-text attachment was scrubbed...<br>
&gt;&gt; &gt; Name: not available<br>
&gt;&gt; &gt; Type: application/pgp-signature<br>
&gt;&gt; &gt; Size: 194 bytes<br>
&gt;&gt; &gt; Desc: not available<br>
&gt;&gt; &gt; Url :<br>
&gt;&gt; &gt; <a href=3D"http://maillists.intel-research.net/pipermail/dtn-=
interest/attachments/20100301/2b1662d0/attachment-0001.bin" target=3D"_blan=
k">http://maillists.intel-research.net/pipermail/dtn-interest/attachments/2=
0100301/2b1662d0/attachment-0001.bin</a><br>

&gt;&gt; &gt;<br>
&gt;&gt; &gt; ------------------------------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Message: 4<br>
&gt;&gt; &gt; Date: Mon, 01 Mar 2010 10:08:10 -0500<br>
&gt;&gt; &gt; From: Daniel Ellard &lt;<a href=3D"mailto:[email-masked]">de=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the leve=
l of<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0discourse<br>
&gt;&gt; &gt; To: Brenton Walker &lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Cc: <a href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a><br>
&gt;&gt; &gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]">4=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Brenton Walker wrote:<br>
&gt;&gt; &gt;&gt; Hi Rajesh,<br>
&gt;&gt; &gt;&gt; =A0 =A0 =A0 Why is it always some other poor fellow who i=
s going to use BP?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; We might *all* be that poor fellow at some point:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; <a href=3D"http://www.npr.org/templates/story/story.php?story=
Id=3D124125001&amp;ft=3D1&amp;f=3D1007" target=3D"_blank">http://www.npr.or=
g/templates/story/story.php?storyId=3D124125001&amp;ft=3D1&amp;f=3D1007</a>=
<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -Dan<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Daniel Ellard, Ph.D.<br>
&gt;&gt; &gt; Senior Scientist, Network Research<br>
&gt;&gt; &gt; BBN Technologies<br>
&gt;&gt; &gt; 10 Moulton Street<br>
&gt;&gt; &gt; Cambridge, MA 02138<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ------------------------------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Message: 5<br>
&gt;&gt; &gt; Date: Mon, 01 Mar 2010 10:12:07 -0500<br>
&gt;&gt; &gt; From: Daniel Ellard &lt;<a href=3D"mailto:[email-masked]">de=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the leve=
l of<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0discourse<br>
&gt;&gt; &gt; To: Brenton Walker &lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Cc: <a href=3D"mailto:[email-masked]">dtn-int=
[email-masked]</a><br>
&gt;&gt; &gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]">4=
[email-masked]</a>&gt;<br>
&gt;&gt; &gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Brenton Walker wrote:<br>
&gt;&gt; &gt;&gt; Hi Rajesh,<br>
&gt;&gt; &gt;&gt; =A0 =A0 =A0 Why is it always some other poor fellow who i=
s going to use BP?<br>
&gt;&gt; &gt;&gt; =A0I<br>
&gt;&gt; &gt;&gt; think we should be trying to think of ways to use it ours=
elves in our<br>
&gt;&gt; &gt;&gt; daily lives. =A0I feel like there are a lot of possibilit=
ies. =A0Even<br>
&gt;&gt; &gt;&gt; though<br>
&gt;&gt; &gt;&gt; access to expensive (3G, wimax) infrastructure is increas=
ing, access to<br>
&gt;&gt; &gt;&gt; cheap infrastructure (open wifi APs) is getting more rest=
rictive. =A0Lots<br>
&gt;&gt; &gt;&gt; of communication I do is pretty local, and BP (and associ=
ated<br>
&gt;&gt; &gt;&gt; technologies) is a very robust tool for that sort of thin=
g.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There&#39;s a group inside BBN who have been getting email an=
d<br>
&gt;&gt; &gt; web access (and maybe some other IP services) exclusively<br>
&gt;&gt; &gt; via BP for a few months. =A0So far, so good.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; =A0 =A0 =A0 One thing people at our lab have been talking=
 about is trying to<br>
&gt;&gt; &gt;&gt; organize some sort of BP-based activity at the IETF. =A0N=
ot a<br>
&gt;&gt; &gt;&gt; disconnectathon that focuses specifically on technical<br=
>
&gt;&gt; &gt;&gt; interoperability,<br>
&gt;&gt; &gt;&gt; but something that gives people a motivation to bring a h=
andset or<br>
&gt;&gt; &gt;&gt; laptop with a BPA on it and play with it during those bor=
ing sessions<br>
&gt;&gt; &gt;&gt; they don&#39;t really care about.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Some ideas we have had:<br>
&gt;&gt; &gt;&gt; - bundle scavenger hunt. =A0There are bundles that can be=
 found with<br>
&gt;&gt; &gt;&gt; varying degrees of difficulty. =A0You get points for rece=
iving them.<br>
&gt;&gt; &gt;&gt; - bundle trivia. =A0Like the bundle scavenger hunt, but y=
ou would have to<br>
&gt;&gt; &gt;&gt; send responses to some EID.<br>
&gt;&gt; &gt;&gt; - bundle mad libs. =A0I don&#39;t quite understand this o=
ne, but people were<br>
&gt;&gt; &gt;&gt; excited about it.<br>
&gt;&gt; &gt;&gt; - bundle capture the flag. =A0OK, I&#39;ll stop.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; It sounds like fun. =A0Lots of work to set up, but fun, if yo=
u<br>
&gt;&gt; &gt; can find volunteers.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; And you need to find someone very honest to be in charge of<b=
r>
&gt;&gt; &gt; disrupting the network in a completely fair manner... =A0:-)<=
br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; -Dan<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Daniel Ellard, Ph.D.<br>
&gt;&gt; &gt; Senior Scientist, Network Research<br>
&gt;&gt; &gt; BBN Technologies<br>
&gt;&gt; &gt; 10 Moulton Street<br>
&gt;&gt; &gt; Cambridge, MA 02138<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; ------------------------------<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; dtn-interest mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]">=
[email-masked]</a><br>
&gt;&gt; &gt; <a href=3D"http://maillists.intel-research.net/mailman/listin=
fo/dtn-interest" target=3D"_blank">http://maillists.intel-research.net/mail=
man/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; End of dtn-interest Digest, Vol 30, Issue 1<br>
&gt;&gt; &gt; *******************************************<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dtn-interest mailing list<br>
&gt;&gt; <a href=3D"mailto:[email-masked]">dtn-i=
[email-masked]</a><br>
&gt;&gt; <a href=3D"http://maillists.intel-research.net/mailman/listinfo/dt=
n-interest" target=3D"_blank">http://maillists.intel-research.net/mailman/l=
istinfo/dtn-interest</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br>

--0016e65ae5d6cb96380480c2e577--

Date: Mon, 1 Mar 2010 14:18:50 -0500
From: Rajesh Krishnan <[email-masked]>
To: Phani Rohit <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Chaudhari, Rohit K." <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Hi Phani,

I think you propose a reasonable application that will exercise DTN/BP
and multi-hop DTN routing.  The cost and scalability arguments for
real world deployments are trickier to make for multi-hop DTN; I
suppose it comes down to revenue models.   The latency gains in your
analysis are in the same order of magnitude, i.e., units of minutes --
in the email/SMS range, but not quite in the IM range.   Extending
cell coverage into subway stations is already being done in many
places, and that lets you do more than just SMS while waiting for the
train.     This service will need to compete with that trend.

I think there are three perspectives here (that I may be mixing somewhat):
    (i) is there a strong application here with a reasonable
business/revenue model
   (ii) is there a strong advantage that DTN/BP provides in that
application compared to other incumbents
  (iii) is there a strong case for multi-hop DTN routing, as opposed
to just nomadic end-points

None of these questions have static answers, and can be asked again
when resource trade-offs change.   But we must ask them in the context
of trends we can reasonably project.

The missing link for multi-party (your example is still single-party
provider I think), multi-hop might well be a business that can assure
some level of trust and resource accounting between handsets of
strangers who are frequently disconnected from infrastructure.  What
will convince strangers on the train cache, carry, and forward SMS
messages for others?

Coming back to your scenario, I expect that low-end LTE/WiMAX
BS/relays will be quite inexpensive soon; regardless of the
technology, installing and maintaining the box and service is going to
dominate the costs, which mobile phone providers have a better way to
recoup than a new entrant.   Would power line networking (ANSI/EIA 709
or other) with possibly LED lighting in the tunnels provide continuous
connectivity in the subway environment completely obviating need for
DTN?

Now, none of what I say above ought to deter R&D in DTN.

Best Regards,
Rajesh

On Mon, Mar 1, 2010 at 12:46 PM, Phani Rohit <[email-masked]> wrote:
> Hi Rajesh,
> This is first Rohit, Who started the conversation of using DTN's in New York
> subway stations. Let me address myself as  " PHANI ". [This is my pet name
> and just to avoid future confusion]
> As " Chaudhari, Rohit " pointed out establishment cost is definitely a
> crucial factor. To add to this points i would say 'scalability' is the
> another  most important factor to choose DTN.  DTN has greater and better
> scope for scalability with respect to cost as well as the infrastructure. We
> can achieve maximum results with DTN than 3G or other internet.
> And for the second question, the sub way station scenario would be a perfect
> application for multi hop DTN. Please see below for further explaination..
> 1. When a user in train 1 wants to send message to outside world but he will
> not get in touch with the broker node sitting at next station for atleast
> next 10 min.
> 2. but there is another train 'train 2' going in opposite direction which
> can carry your bundle and drop in other station where it gets connectivity
> in next 2-3 min
> 3. Train 1 -- > Train 2 ---> DTN Node 1 [Broker Node sitting at station] ---
>> DTN Gateway [ Node 2 at same station, which has connectivity to the outer
> world]...
> 4. so we can use the movement of trains for routing the bundles and
> calculate minimum delay path and transfer the bundles...
> 5. Above mentioned is a simple scenario...even complex scenarios are
> possible...
> Please let me know if you need any further explaination
> Regards,
> Phani Rohit Mullangi (PhD)
> University of Georgia
> Athens GA
>
>
>
> On Mon, Mar 1, 2010 at 11:01 AM, Chaudhari, Rohit K.
> <[email-masked]> wrote:
>>
>> Hey Rajesh,
>>
>> The extension of 3G is also a great (and probably preferred) alternative
>> since infrastructure is definitely more stable than queuing messages in the
>> store-and-forward operations of DTN.  But the 3G coverage would vary network
>> to network since some 3G providers do not have as extensive coverage.
>>  Depending on the overall costs, DTN could be more cost efficient and be
>> universal across all networks, I would presume, but I could be wrong here.
>>  Even if 3G is expanded a more long-term goal with DTN could be greatly
>> beneficial.  You do, however, bring up a valid point, but once again, cost
>> is always a factor.
>>
>> -Rohit
>>
>> -----Original Message-----
>> From: Rajesh Krishnan [mailto:[email-masked]]
>> Sent: Monday, March 01, 2010 10:56 AM
>> To: Chaudhari, Rohit K.
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse
>>
>> Rohit,
>>
>> This could be a useful service, but if all we did was extend 3G (or
>> other Internet) coverage into the stations, will we get similar
>> results?
>> Is a multi-hop DTN necessary for this application? Endpoints can queue
>> up messages till the next station where they connect to
>> infrastructure.
>>
>> -Rajesh
>>
>>
>> On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.
>> <[email-masked]> wrote:
>> > Hi all,
>> >
>> > My name is Rohit as well and I recently joined the DTN-interest mailing
>> > list this morning.  As the other Rohit suggested, I too have recently read
>> > about NYC subways.  Over 6 million people use the subway in NYC everyday and
>> > to think that cell phone communications within them is pretty much
>> > non-existent is pretty deplorable.  I know that at one point NYC wanted to
>> > redo the cell infrastructure in the subways which would cost them tens of
>> > millions of dollars, but they did also bring up the topic of DTN and using
>> > it commercially.  This is definitely something that could be explored in the
>> > future if a commercial angle seems appropriate.  Hope everyone is enjoying
>> > their day so far. Let me know what you guys think.
>> >
>> > Thanks,
>> >
>> > Rohit
>> >
>> > -----Original Message-----
>> > From: [email-masked]
>> > [mailto:[email-masked]] On Behalf Of
>> > [email-masked]
>> > Sent: Monday, March 01, 2010 10:12 AM
>> > To: [email-masked]
>> > Subject: dtn-interest Digest, Vol 30, Issue 1
>> >
>> > Send dtn-interest mailing list submissions to
>> >        [email-masked]
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> > or, via email, send a message with subject or body 'help' to
>> >        [email-masked]
>> >
>> > You can reach the person managing the list at
>> >        [email-masked]
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of dtn-interest digest..."
>> >
>> >
>> > Today's Topics:
>> >
>> >   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
>> >   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
>> >   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
>> >   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>> >   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Sun, 28 Feb 2010 17:27:29 -0500
>> > From: Rajesh Krishnan <[email-masked]>
>> > Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
>> > To: [email-masked]
>> > Message-ID:
>> >        <[email-masked]>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > I started implementing RFC5050 in Haskell, with a goal of fitting it
>> > in less than 500 lines of code (which was roughly the size of the
>> > Xmonad tiling window manager in 2007).
>> > Clearly I had underestimated the challenge and did not get very far.
>> > I figured I might as well set this free and move on.
>> >
>> > http://www.rajesh-krishnan.com/repos
>> >
>> > -Rajesh
>> >
>> > P.S.:  SDNV is a good exercise for a first course in functional
>> > programming.   One that may cause CS students to pay attention to
>> > DTN/BP as a side benefit.  :)
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 2
>> > Date: Mon, 1 Mar 2010 00:10:33 -0500
>> > From: Phani Rohit <[email-masked]>
>> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>> >        discourse
>> > To: Rajesh Krishnan <[email-masked]>
>> > Cc: [email-masked]
>> > Message-ID:
>> >        <[email-masked]>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > Hi All,
>> >
>> > I am posting for the first time in this research group. Please excuse me
>> > if
>> > my idea does not make sense. I have an idea for using DTN's in day to
>> > day
>> > life. I don't know its commercial value.
>> >
>> > Recently I visited New York City, one of the busiest and happening
>> > place.
>> > The moment you get in to sub way station the communication with the
>> > world is
>> > lost. so  why can't any body have a simple DTN deployment like bunch of
>> > broker nodes sitting at the opening of each station and route the
>> > bundles
>> > via moving trains and deliver it to outer world. A simple app in this
>> > scenario would be SMS application running on DTN or chat client.
>> >
>> > Please let me know if this make sense  or if you need any further
>> > explanation.
>> >
>> > Thanks,
>> > Rohit
>> >
>> >
>> > On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan
>> > <[email-masked]>wrote:
>> >
>> >> Hi Brenton,
>> >>
>> >> Interesting game ideas.
>> >>
>> >> >From time to time, as my professional life has demanded, I have tried
>> >> to use or work with BP.   I will happily be the fellow who is going to
>> >> use BP, but the fact of the matter is I have not created or found a
>> >> deployment/application that I can use in my daily life.
>> >>
>> >> There are several possible vectors that can achieve critical mass for
>> >> DTN/BP:
>> >>    - seeding into future-oriented systems (which some Government
>> >> agencies have done), hoping it will grow big in a few decades
>> >>    - a new application or a content overlay  that is generally
>> >> useful, that happens to use BP, and grows popular rapidly  [ our
>> >> current discussion ]
>> >>    - through regulation or acquisition policy (may be as successful
>> >> as GOSIP and Ada :)
>> >>    - through education
>> >>
>> >> One idea was to see if it makes sense to explore BP in place of
>> >> packetbb as a mechanism to gateway between diverse MANETs (require
>> >> this as acquisition policy); one problem there is MANETs are still
>> >> looking for their killer commercial application too.   As 3G/4G
>> >> coverage increases, the need for multi-hop DTN routing will be
>> >> increasingly pushed to challenging regimes of space, underground,
>> >> underwater, etc.   There will be niche terrestrial opportunities
>> >> (reindeer nets) and opportunities in virtual overlays (for distributed
>> >> algorithm purists).
>> >>
>> >> Regardless of whether BP achieves population inversion or not (either
>> >> over application overlay protocols or  Layer 2/3 encapsulations),
>> >> important lessons can be learned from achieving critical mass around
>> >> the BP.   Without critical mass, many of the ideas generated for ATM
>> >> research would not have been; some of those ideas (or the competition
>> >> they created) transformed IP networks.
>> >>
>> >> During one of my earlier briefings to the NSF FIND folks to explore
>> >> synergies, I found they (i) wanted freedom from any constraints, BP or
>> >>  otherwise, OR (ii) wanted critical mass such as that provided by
>> >> TCP/IP and 802.11 in order to justify living with the constraints.
>> >> There was some concern expressed around the ramp up time and perceived
>> >> complexity of the BP.  In any case, I had failed to convince them of
>> >> the enormous opportunity that was available in the middle ground --
>> >> between clean slate and retrofit -- for novel routing and naming
>> >> research.   BP offers a near clean slate, the benefits of an existing
>> >> research community that provides the nucleus, and a good metadata
>> >> extension block, especially for routing, naming, content-networking,
>> >> and context/location-aware computing.  I have not given up hope;  BP
>> >> on NSF GENI would be a good way to keep DTN/BP more relevant to the
>> >> mainstream networking community.
>> >>
>> >> On the other hand, when I spoke to folks who do commercialization,
>> >> their question to me was what is one thing you can do with the BP
>> >> today  that they cannot hire programmers to do over other popular
>> >> Internet-based technologies.  They can do meter reading, elevator net,
>> >> email or content delivery to remote facilities using custom
>> >> applications that are disruption-tolerant, and without buying into the
>> >> full DTN/BP program.    Clearly they do not care about technical
>> >> features, elegance, or potential for transformation provided by the
>> >> DTN architecture.   Disruptive uses of the BP in settings would be
>> >> interesting in order to exercise non-traditional routing and rich
>> >> naming;  otherwise, the question of why not do it with SOAP (or
>> >> alternative for which I can hire low-cost programmers) will persist?
>> >> There need to see value additions that can be monetized in the short
>> >> term.
>> >>
>> >> While all of the applications you mention will exercise the BP, all of
>> >> them can be expeditiously done on an iPhone/Droid and can take
>> >> advantage of remote servers.
>> >> Regardless, the playing you suggest is better than the theorizing I
>> >> provide above.
>> >>
>> >> Best Regards,
>> >> Rajesh
>> >>
>> >> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <[email-masked]>
>> >> wrote:
>> >> > Hi Rajesh,
>> >> >        Why is it always some other poor fellow who is going to use
>> >> > BP?  I
>> >> > think we should be trying to think of ways to use it ourselves in our
>> >> > daily lives.  I feel like there are a lot of possibilities.  Even
>> >> > though
>> >> > access to expensive (3G, wimax) infrastructure is increasing, access
>> >> > to
>> >> > cheap infrastructure (open wifi APs) is getting more restrictive.
>> >> >  Lots
>> >> > of communication I do is pretty local, and BP (and associated
>> >> > technologies) is a very robust tool for that sort of thing.
>> >> >
>> >> >        One thing people at our lab have been talking about is trying
>> >> > to
>> >> > organize some sort of BP-based activity at the IETF.  Not a
>> >> > disconnectathon that focuses specifically on technical
>> >> > interoperability,
>> >> > but something that gives people a motivation to bring a handset or
>> >> > laptop with a BPA on it and play with it during those boring sessions
>> >> > they don't really care about.
>> >> >
>> >> > Some ideas we have had:
>> >> > - bundle scavenger hunt.  There are bundles that can be found with
>> >> > varying degrees of difficulty.  You get points for receiving them.
>> >> > - bundle trivia.  Like the bundle scavenger hunt, but you would have
>> >> > to
>> >> > send responses to some EID.
>> >> > - bundle mad libs.  I don't quite understand this one, but people
>> >> > were
>> >> > excited about it.
>> >> > - bundle capture the flag.  OK, I'll stop.
>> >> >
>> >> > Stupid idea?
>> >> > Already been done?
>> >> >
>> >> > Thanks,
>> >> > Brenton
>> >> >
>> >> >
>> >> >
>> >> > Rajesh Krishnan wrote:
>> >> >> In think in Parikh et al.'s application, DTN was useful to let chat
>> >> >> participants catch up on the conversation they missed while they
>> >> >> were
>> >> >> temporarily disconnected; these are environments where end-to-end
>> >> >> access to one server cannot be assured.
>> >> >>
>> >> >> The sailboat-based email delivery is definitely interesting.
>> >> >>
>> >> >> Best Regards,
>> >> >> Rajesh
>> >> >>
>> >> >>
>> >> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
>> >> >> <[email-masked]> wrote:
>> >> >>>> What I find strange is that the DTN community isn't trying to run
>> >> email
>> >> >>>> and chat over BP.  Those are natural applications for DTN, but yet
>> >> >>>> there's not (to my knowledge) a release of an MTA, jabber client,
>> >> jabber
>> >> >>>> server, etc., that uses BP, and I don't hear anyone talking about
>> >> having
>> >> >>>> problems running those programs on the global dbone.
>> >> >>>>
>> >> >>>> Is anyone trying to use BP to do anything other than tests?
>> >> >>> I can't see how a realtime application like jabber would be
>> >> >>> something
>> >> >>> DTN would address; surely disconnected jabber is email, no?
>> >> >>>
>> >> >>> One natural application for DTN is providing email service to
>> >> >>> sailboats on the gulf coast of British Columbia.
>> >> >>>
>> >> >>> The stretch of water up the Strait from Vancouver to the north end
>> >> >>> of
>> >> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes of
>> >> >>> cellular connectivity.  In almost every marina, email access is
>> >> >>> found
>> >> >>> by subscription only to services such as BBX.  There is no access
>> >> >>> outside of the pay-per-mail marina wifi access points.
>> >> >>>
>> >> >>> There is no hope of running land-based network backhaul into most
>> >> >>> of
>> >> >>> the locations sailors would park in.  A BP-based email network is a
>> >> >>> likely option for people on the coast living away from land-based
>> >> >>> infrastructure.
>> >> >>>
>> >> >>> --lyndon
>> >> >>>
>> >> >>>
>> >> >>
>> >> >> _______________________________________________
>> >> >> dtn-interest mailing list
>> >> >> [email-masked]
>> >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > dtn-interest mailing list
>> >> > [email-masked]
>> >> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >> >
>> >>
>> >> _______________________________________________
>> >> dtn-interest mailing list
>> >> [email-masked]
>> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >>
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL:
>> > http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html
>> >
>> > ------------------------------
>> >
>> > Message: 3
>> > Date: Mon, 01 Mar 2010 09:02:54 -0500
>> > From: Greg Troxel <[email-masked]>
>> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>> >        discourse
>> > To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
>> > Cc: [email-masked]
>> > Message-ID: <[email-masked]>
>> > Content-Type: text/plain; charset="us-ascii"
>> >
>> >
>> > "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:
>> >
>> >> I can't see how a realtime application like jabber would be something
>> >> DTN would address; surely disconnected jabber is email, no?
>> >
>> > Disconnection can happen on many time scales.  If it's a few minutes,
>> > it's still different than email, and you can still have presence
>> > indications.
>> >
>> > Still, my real point is that until there's freely available code to plug
>> > in alternate transports for things like pidgin, and enough dbone
>> > infrastructure that people can actually use this, it's really hard to
>> > know under what circumstances DTN will be really useful compared to what
>> > we have now.
>> > -------------- next part --------------
>> > A non-text attachment was scrubbed...
>> > Name: not available
>> > Type: application/pgp-signature
>> > Size: 194 bytes
>> > Desc: not available
>> > Url :
>> > http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin
>> >
>> > ------------------------------
>> >
>> > Message: 4
>> > Date: Mon, 01 Mar 2010 10:08:10 -0500
>> > From: Daniel Ellard <[email-masked]>
>> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>> >        discourse
>> > To: Brenton Walker <[email-masked]>
>> > Cc: [email-masked]
>> > Message-ID: <[email-masked]>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Brenton Walker wrote:
>> >> Hi Rajesh,
>> >>       Why is it always some other poor fellow who is going to use BP?
>> >
>> > We might *all* be that poor fellow at some point:
>> >
>> >
>> > http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007
>> >
>> > -Dan
>> >
>> > --
>> > Daniel Ellard, Ph.D.
>> > Senior Scientist, Network Research
>> > BBN Technologies
>> > 10 Moulton Street
>> > Cambridge, MA 02138
>> > [email-masked]
>> >
>> >
>> > ------------------------------
>> >
>> > Message: 5
>> > Date: Mon, 01 Mar 2010 10:12:07 -0500
>> > From: Daniel Ellard <[email-masked]>
>> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>> >        discourse
>> > To: Brenton Walker <[email-masked]>
>> > Cc: [email-masked]
>> > Message-ID: <[email-masked]>
>> > Content-Type: text/plain; charset=ISO-8859-1
>> >
>> > Brenton Walker wrote:
>> >> Hi Rajesh,
>> >>       Why is it always some other poor fellow who is going to use BP?
>> >>  I
>> >> think we should be trying to think of ways to use it ourselves in our
>> >> daily lives.  I feel like there are a lot of possibilities.  Even
>> >> though
>> >> access to expensive (3G, wimax) infrastructure is increasing, access to
>> >> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
>> >> of communication I do is pretty local, and BP (and associated
>> >> technologies) is a very robust tool for that sort of thing.
>> >
>> > There's a group inside BBN who have been getting email and
>> > web access (and maybe some other IP services) exclusively
>> > via BP for a few months.  So far, so good.
>> >
>> >>       One thing people at our lab have been talking about is trying to
>> >> organize some sort of BP-based activity at the IETF.  Not a
>> >> disconnectathon that focuses specifically on technical
>> >> interoperability,
>> >> but something that gives people a motivation to bring a handset or
>> >> laptop with a BPA on it and play with it during those boring sessions
>> >> they don't really care about.
>> >>
>> >> Some ideas we have had:
>> >> - bundle scavenger hunt.  There are bundles that can be found with
>> >> varying degrees of difficulty.  You get points for receiving them.
>> >> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
>> >> send responses to some EID.
>> >> - bundle mad libs.  I don't quite understand this one, but people were
>> >> excited about it.
>> >> - bundle capture the flag.  OK, I'll stop.
>> >
>> > It sounds like fun.  Lots of work to set up, but fun, if you
>> > can find volunteers.
>> >
>> > And you need to find someone very honest to be in charge of
>> > disrupting the network in a completely fair manner...  :-)
>> >
>> > -Dan
>> >
>> >
>> > --
>> > Daniel Ellard, Ph.D.
>> > Senior Scientist, Network Research
>> > BBN Technologies
>> > 10 Moulton Street
>> > Cambridge, MA 02138
>> > [email-masked]
>> >
>> >
>> > ------------------------------
>> >
>> > _______________________________________________
>> > dtn-interest mailing list
>> > [email-masked]
>> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >
>> >
>> > End of dtn-interest Digest, Vol 30, Issue 1
>> > *******************************************
>> >
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>

From: Phani Rohit <[email-masked]>
Date: Mon, 1 Mar 2010 12:46:43 -0500
To: "Chaudhari, Rohit K." <[email-masked]>, Rajesh Krishnan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

--0016e64806784b52de0480c0d612
Content-Type: text/plain; charset=ISO-8859-1

Hi Rajesh,

This is first Rohit, Who started the conversation of using DTN's in New York
subway stations. Let me address myself as  " PHANI ". [This is my pet name
and just to avoid future confusion]

As " Chaudhari, Rohit " pointed out establishment cost is definitely a
crucial factor. To add to this points i would say 'scalability' is the
another  most important factor to choose DTN.  DTN has greater and better
scope for scalability with respect to cost as well as the infrastructure. We
can achieve maximum results with DTN than 3G or other internet.

And for the second question, the sub way station scenario would be a perfect
application for multi hop DTN. Please see below for further explaination..

1. When a user in train 1 wants to send message to outside world but he will
not get in touch with the broker node sitting at next station for atleast
next 10 min.

2. but there is another train 'train 2' going in opposite direction which
can carry your bundle and drop in other station where it gets connectivity
in next 2-3 min

3. Train 1 -- > Train 2 ---> DTN Node 1 [Broker Node sitting at station] ---
> DTN Gateway [ Node 2 at same station, which has connectivity to the outer
world]...

4. so we can use the movement of trains for routing the bundles and
calculate minimum delay path and transfer the bundles...

5. Above mentioned is a simple scenario...even complex scenarios are
possible...

Please let me know if you need any further explaination

Regards,
Phani Rohit Mullangi (PhD)
University of Georgia
Athens GA

On Mon, Mar 1, 2010 at 11:01 AM, Chaudhari, Rohit K. <
[email-masked]> wrote:

> Hey Rajesh,
>
> The extension of 3G is also a great (and probably preferred) alternative
> since infrastructure is definitely more stable than queuing messages in the
> store-and-forward operations of DTN.  But the 3G coverage would vary network
> to network since some 3G providers do not have as extensive coverage.
>  Depending on the overall costs, DTN could be more cost efficient and be
> universal across all networks, I would presume, but I could be wrong here.
>  Even if 3G is expanded a more long-term goal with DTN could be greatly
> beneficial.  You do, however, bring up a valid point, but once again, cost
> is always a factor.
>
> -Rohit
>
> -----Original Message-----
> From: Rajesh Krishnan [mailto:[email-masked]]
> Sent: Monday, March 01, 2010 10:56 AM
> To: Chaudhari, Rohit K.
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse
>
> Rohit,
>
> This could be a useful service, but if all we did was extend 3G (or
> other Internet) coverage into the stations, will we get similar
> results?
> Is a multi-hop DTN necessary for this application? Endpoints can queue
> up messages till the next station where they connect to
> infrastructure.
>
> -Rajesh
>
>
> On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.
> <[email-masked]> wrote:
> > Hi all,
> >
> > My name is Rohit as well and I recently joined the DTN-interest mailing
> list this morning.  As the other Rohit suggested, I too have recently read
> about NYC subways.  Over 6 million people use the subway in NYC everyday and
> to think that cell phone communications within them is pretty much
> non-existent is pretty deplorable.  I know that at one point NYC wanted to
> redo the cell infrastructure in the subways which would cost them tens of
> millions of dollars, but they did also bring up the topic of DTN and using
> it commercially.  This is definitely something that could be explored in the
> future if a commercial angle seems appropriate.  Hope everyone is enjoying
> their day so far. Let me know what you guys think.
> >
> > Thanks,
> >
> > Rohit
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:
> [email-masked]] On Behalf Of
> [email-masked]
> > Sent: Monday, March 01, 2010 10:12 AM
> > To: [email-masked]
> > Subject: dtn-interest Digest, Vol 30, Issue 1
> >
> > Send dtn-interest mailing list submissions to
> >        [email-masked]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> > or, via email, send a message with subject or body 'help' to
> >        [email-masked]
> >
> > You can reach the person managing the list at
> >        [email-masked]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of dtn-interest digest..."
> >
> >
> > Today's Topics:
> >
> >   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
> >   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
> >   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
> >   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
> >   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Sun, 28 Feb 2010 17:27:29 -0500
> > From: Rajesh Krishnan <[email-masked]>
> > Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
> > To: [email-masked]
> > Message-ID:
> >        <[email-masked]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > I started implementing RFC5050 in Haskell, with a goal of fitting it
> > in less than 500 lines of code (which was roughly the size of the
> > Xmonad tiling window manager in 2007).
> > Clearly I had underestimated the challenge and did not get very far.
> > I figured I might as well set this free and move on.
> >
> > http://www.rajesh-krishnan.com/repos
> >
> > -Rajesh
> >
> > P.S.:  SDNV is a good exercise for a first course in functional
> > programming.   One that may cause CS students to pay attention to
> > DTN/BP as a side benefit.  :)
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Mon, 1 Mar 2010 00:10:33 -0500
> > From: Phani Rohit <[email-masked]>
> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >        discourse
> > To: Rajesh Krishnan <[email-masked]>
> > Cc: [email-masked]
> > Message-ID:
> >        <[email-masked]>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hi All,
> >
> > I am posting for the first time in this research group. Please excuse me
> if
> > my idea does not make sense. I have an idea for using DTN's in day to day
> > life. I don't know its commercial value.
> >
> > Recently I visited New York City, one of the busiest and happening place.
> > The moment you get in to sub way station the communication with the world
> is
> > lost. so  why can't any body have a simple DTN deployment like bunch of
> > broker nodes sitting at the opening of each station and route the bundles
> > via moving trains and deliver it to outer world. A simple app in this
> > scenario would be SMS application running on DTN or chat client.
> >
> > Please let me know if this make sense  or if you need any further
> > explanation.
> >
> > Thanks,
> > Rohit
> >
> >
> > On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan <[email-masked]
> >wrote:
> >
> >> Hi Brenton,
> >>
> >> Interesting game ideas.
> >>
> >> >From time to time, as my professional life has demanded, I have tried
> >> to use or work with BP.   I will happily be the fellow who is going to
> >> use BP, but the fact of the matter is I have not created or found a
> >> deployment/application that I can use in my daily life.
> >>
> >> There are several possible vectors that can achieve critical mass for
> >> DTN/BP:
> >>    - seeding into future-oriented systems (which some Government
> >> agencies have done), hoping it will grow big in a few decades
> >>    - a new application or a content overlay  that is generally
> >> useful, that happens to use BP, and grows popular rapidly  [ our
> >> current discussion ]
> >>    - through regulation or acquisition policy (may be as successful
> >> as GOSIP and Ada :)
> >>    - through education
> >>
> >> One idea was to see if it makes sense to explore BP in place of
> >> packetbb as a mechanism to gateway between diverse MANETs (require
> >> this as acquisition policy); one problem there is MANETs are still
> >> looking for their killer commercial application too.   As 3G/4G
> >> coverage increases, the need for multi-hop DTN routing will be
> >> increasingly pushed to challenging regimes of space, underground,
> >> underwater, etc.   There will be niche terrestrial opportunities
> >> (reindeer nets) and opportunities in virtual overlays (for distributed
> >> algorithm purists).
> >>
> >> Regardless of whether BP achieves population inversion or not (either
> >> over application overlay protocols or  Layer 2/3 encapsulations),
> >> important lessons can be learned from achieving critical mass around
> >> the BP.   Without critical mass, many of the ideas generated for ATM
> >> research would not have been; some of those ideas (or the competition
> >> they created) transformed IP networks.
> >>
> >> During one of my earlier briefings to the NSF FIND folks to explore
> >> synergies, I found they (i) wanted freedom from any constraints, BP or
> >>  otherwise, OR (ii) wanted critical mass such as that provided by
> >> TCP/IP and 802.11 in order to justify living with the constraints.
> >> There was some concern expressed around the ramp up time and perceived
> >> complexity of the BP.  In any case, I had failed to convince them of
> >> the enormous opportunity that was available in the middle ground --
> >> between clean slate and retrofit -- for novel routing and naming
> >> research.   BP offers a near clean slate, the benefits of an existing
> >> research community that provides the nucleus, and a good metadata
> >> extension block, especially for routing, naming, content-networking,
> >> and context/location-aware computing.  I have not given up hope;  BP
> >> on NSF GENI would be a good way to keep DTN/BP more relevant to the
> >> mainstream networking community.
> >>
> >> On the other hand, when I spoke to folks who do commercialization,
> >> their question to me was what is one thing you can do with the BP
> >> today  that they cannot hire programmers to do over other popular
> >> Internet-based technologies.  They can do meter reading, elevator net,
> >> email or content delivery to remote facilities using custom
> >> applications that are disruption-tolerant, and without buying into the
> >> full DTN/BP program.    Clearly they do not care about technical
> >> features, elegance, or potential for transformation provided by the
> >> DTN architecture.   Disruptive uses of the BP in settings would be
> >> interesting in order to exercise non-traditional routing and rich
> >> naming;  otherwise, the question of why not do it with SOAP (or
> >> alternative for which I can hire low-cost programmers) will persist?
> >> There need to see value additions that can be monetized in the short
> >> term.
> >>
> >> While all of the applications you mention will exercise the BP, all of
> >> them can be expeditiously done on an iPhone/Droid and can take
> >> advantage of remote servers.
> >> Regardless, the playing you suggest is better than the theorizing I
> >> provide above.
> >>
> >> Best Regards,
> >> Rajesh
> >>
> >> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <[email-masked]>
> >> wrote:
> >> > Hi Rajesh,
> >> >        Why is it always some other poor fellow who is going to use BP?
>  I
> >> > think we should be trying to think of ways to use it ourselves in our
> >> > daily lives.  I feel like there are a lot of possibilities.  Even
> though
> >> > access to expensive (3G, wimax) infrastructure is increasing, access
> to
> >> > cheap infrastructure (open wifi APs) is getting more restrictive.
>  Lots
> >> > of communication I do is pretty local, and BP (and associated
> >> > technologies) is a very robust tool for that sort of thing.
> >> >
> >> >        One thing people at our lab have been talking about is trying
> to
> >> > organize some sort of BP-based activity at the IETF.  Not a
> >> > disconnectathon that focuses specifically on technical
> interoperability,
> >> > but something that gives people a motivation to bring a handset or
> >> > laptop with a BPA on it and play with it during those boring sessions
> >> > they don't really care about.
> >> >
> >> > Some ideas we have had:
> >> > - bundle scavenger hunt.  There are bundles that can be found with
> >> > varying degrees of difficulty.  You get points for receiving them.
> >> > - bundle trivia.  Like the bundle scavenger hunt, but you would have
> to
> >> > send responses to some EID.
> >> > - bundle mad libs.  I don't quite understand this one, but people were
> >> > excited about it.
> >> > - bundle capture the flag.  OK, I'll stop.
> >> >
> >> > Stupid idea?
> >> > Already been done?
> >> >
> >> > Thanks,
> >> > Brenton
> >> >
> >> >
> >> >
> >> > Rajesh Krishnan wrote:
> >> >> In think in Parikh et al.'s application, DTN was useful to let chat
> >> >> participants catch up on the conversation they missed while they were
> >> >> temporarily disconnected; these are environments where end-to-end
> >> >> access to one server cannot be assured.
> >> >>
> >> >> The sailboat-based email delivery is definitely interesting.
> >> >>
> >> >> Best Regards,
> >> >> Rajesh
> >> >>
> >> >>
> >> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
> >> >> <[email-masked]> wrote:
> >> >>>> What I find strange is that the DTN community isn't trying to run
> >> email
> >> >>>> and chat over BP.  Those are natural applications for DTN, but yet
> >> >>>> there's not (to my knowledge) a release of an MTA, jabber client,
> >> jabber
> >> >>>> server, etc., that uses BP, and I don't hear anyone talking about
> >> having
> >> >>>> problems running those programs on the global dbone.
> >> >>>>
> >> >>>> Is anyone trying to use BP to do anything other than tests?
> >> >>> I can't see how a realtime application like jabber would be
> something
> >> >>> DTN would address; surely disconnected jabber is email, no?
> >> >>>
> >> >>> One natural application for DTN is providing email service to
> >> >>> sailboats on the gulf coast of British Columbia.
> >> >>>
> >> >>> The stretch of water up the Strait from Vancouver to the north end
> of
> >> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes of
> >> >>> cellular connectivity.  In almost every marina, email access is
> found
> >> >>> by subscription only to services such as BBX.  There is no access
> >> >>> outside of the pay-per-mail marina wifi access points.
> >> >>>
> >> >>> There is no hope of running land-based network backhaul into most of
> >> >>> the locations sailors would park in.  A BP-based email network is a
> >> >>> likely option for people on the coast living away from land-based
> >> >>> infrastructure.
> >> >>>
> >> >>> --lyndon
> >> >>>
> >> >>>
> >> >>
> >> >> _______________________________________________
> >> >> dtn-interest mailing list
> >> >> [email-masked]
> >> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >>
> >> >
> >> > _______________________________________________
> >> > dtn-interest mailing list
> >> > [email-masked]
> >> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >> >
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >>
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Mon, 01 Mar 2010 09:02:54 -0500
> > From: Greg Troxel <[email-masked]>
> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >        discourse
> > To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
> > Cc: [email-masked]
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset="us-ascii"
> >
> >
> > "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:
> >
> >> I can't see how a realtime application like jabber would be something
> >> DTN would address; surely disconnected jabber is email, no?
> >
> > Disconnection can happen on many time scales.  If it's a few minutes,
> > it's still different than email, and you can still have presence
> > indications.
> >
> > Still, my real point is that until there's freely available code to plug
> > in alternate transports for things like pidgin, and enough dbone
> > infrastructure that people can actually use this, it's really hard to
> > know under what circumstances DTN will be really useful compared to what
> > we have now.
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: application/pgp-signature
> > Size: 194 bytes
> > Desc: not available
> > Url :
> http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Mon, 01 Mar 2010 10:08:10 -0500
> > From: Daniel Ellard <[email-masked]>
> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >        discourse
> > To: Brenton Walker <[email-masked]>
> > Cc: [email-masked]
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Brenton Walker wrote:
> >> Hi Rajesh,
> >>       Why is it always some other poor fellow who is going to use BP?
> >
> > We might *all* be that poor fellow at some point:
> >
> >
> http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007
> >
> > -Dan
> >
> > --
> > Daniel Ellard, Ph.D.
> > Senior Scientist, Network Research
> > BBN Technologies
> > 10 Moulton Street
> > Cambridge, MA 02138
> > [email-masked]
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Mon, 01 Mar 2010 10:12:07 -0500
> > From: Daniel Ellard <[email-masked]>
> > Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
> >        discourse
> > To: Brenton Walker <[email-masked]>
> > Cc: [email-masked]
> > Message-ID: <[email-masked]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Brenton Walker wrote:
> >> Hi Rajesh,
> >>       Why is it always some other poor fellow who is going to use BP?  I
> >> think we should be trying to think of ways to use it ourselves in our
> >> daily lives.  I feel like there are a lot of possibilities.  Even though
> >> access to expensive (3G, wimax) infrastructure is increasing, access to
> >> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
> >> of communication I do is pretty local, and BP (and associated
> >> technologies) is a very robust tool for that sort of thing.
> >
> > There's a group inside BBN who have been getting email and
> > web access (and maybe some other IP services) exclusively
> > via BP for a few months.  So far, so good.
> >
> >>       One thing people at our lab have been talking about is trying to
> >> organize some sort of BP-based activity at the IETF.  Not a
> >> disconnectathon that focuses specifically on technical interoperability,
> >> but something that gives people a motivation to bring a handset or
> >> laptop with a BPA on it and play with it during those boring sessions
> >> they don't really care about.
> >>
> >> Some ideas we have had:
> >> - bundle scavenger hunt.  There are bundles that can be found with
> >> varying degrees of difficulty.  You get points for receiving them.
> >> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
> >> send responses to some EID.
> >> - bundle mad libs.  I don't quite understand this one, but people were
> >> excited about it.
> >> - bundle capture the flag.  OK, I'll stop.
> >
> > It sounds like fun.  Lots of work to set up, but fun, if you
> > can find volunteers.
> >
> > And you need to find someone very honest to be in charge of
> > disrupting the network in a completely fair manner...  :-)
> >
> > -Dan
> >
> >
> > --
> > Daniel Ellard, Ph.D.
> > Senior Scientist, Network Research
> > BBN Technologies
> > 10 Moulton Street
> > Cambridge, MA 02138
> > [email-masked]
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
> >
> > End of dtn-interest Digest, Vol 30, Issue 1
> > *******************************************
> >
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>

--0016e64806784b52de0480c0d612
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Rajesh,<div><br></div><div>This is first Rohit, Who started the conversa=
tion of using DTN&#39;s in New York subway stations. Let me address myself =
as =A0&quot; PHANI &quot;. [This is my pet name and just to avoid future co=
nfusion]</div>

<div><br></div><div>As &quot; Chaudhari, Rohit &quot; pointed out=A0establi=
shment=A0cost is definitely a crucial factor. To add to this points i would=
 say &#39;scalability&#39; is the another =A0most important factor to choos=
e DTN. =A0DTN has greater and better scope for=A0scalability with respect t=
o cost as well as the=A0infrastructure. We can achieve maximum results with=
 DTN than 3G or other internet.</div>

<div><br></div><div>And for the second question, the sub way station scenar=
io would be a perfect application for multi hop DTN. Please see below for f=
urther explaination..</div><div><br></div><div>1. When a user in train 1 wa=
nts to send message to outside world but he will not get in touch with the =
broker node sitting at next=A0station for atleast next 10 min.</div>

<div><br></div><div>2. but there is another train &#39;train 2&#39; going i=
n opposite direction which can carry your bundle and drop in other station =
where it gets connectivity in next 2-3 min</div><div><br></div><div>3. Trai=
n 1 -- &gt; Train 2 ---&gt; DTN Node 1 [Broker Node sitting at station] ---=
 &gt; DTN Gateway [ Node 2 at same station, which has connectivity to the o=
uter world]...</div>

<div><br></div><div>4. so we can use the movement of trains for routing the=
 bundles and calculate minimum delay path and transfer the bundles...</div>=
<div><br></div><div>5. Above mentioned is a simple scenario...even complex =
scenarios are possible...</div>

<div><br></div><div>Please let me know if you need any further explaination=
</div><div><br></div><div>Regards,</div><div>Phani Rohit Mullangi (PhD)</di=
v><div>University of Georgia</div><div>Athens GA</div><div><br></div><div>

<br></div><div><br><br><div class=3D"gmail_quote">On Mon, Mar 1, 2010 at 11=
:01 AM, Chaudhari, Rohit K. <span dir=3D"ltr">&lt;<a href=3D"mailto:Rohit.C=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">

Hey Rajesh,<br>
<br>
The extension of 3G is also a great (and probably preferred) alternative si=
nce infrastructure is definitely more stable than queuing messages in the s=
tore-and-forward operations of DTN. =A0But the 3G coverage would vary netwo=
rk to network since some 3G providers do not have as extensive coverage. =
=A0Depending on the overall costs, DTN could be more cost efficient and be =
universal across all networks, I would presume, but I could be wrong here. =
=A0Even if 3G is expanded a more long-term goal with DTN could be greatly b=
eneficial. =A0You do, however, bring up a valid point, but once again, cost=
 is always a factor.<br>

<font color=3D"#888888"><br>
-Rohit<br>
</font><div><div></div><div class=3D"h5"><br>
-----Original Message-----<br>
From: Rajesh Krishnan [mailto:<a href=3D"mailto:[email-masked]">rjsh=
[email-masked]</a>]<br>
Sent: Monday, March 01, 2010 10:56 AM<br>
To: Chaudhari, Rohit K.<br>
Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a>; <a href=3D"=
mailto:[email-masked]">[email-masked]</a><b=
r>
Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of discourse=
<br>
<br>
Rohit,<br>
<br>
This could be a useful service, but if all we did was extend 3G (or<br>
other Internet) coverage into the stations, will we get similar<br>
results?<br>
Is a multi-hop DTN necessary for this application? Endpoints can queue<br>
up messages till the next station where they connect to<br>
infrastructure.<br>
<br>
-Rajesh<br>
<br>
<br>
On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.<br>
&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
u</a>&gt; wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; My name is Rohit as well and I recently joined the DTN-interest mailin=
g list this morning. =A0As the other Rohit suggested, I too have recently r=
ead about NYC subways. =A0Over 6 million people use the subway in NYC every=
day and to think that cell phone communications within them is pretty much =
non-existent is pretty deplorable. =A0I know that at one point NYC wanted t=
o redo the cell infrastructure in the subways which would cost them tens of=
 millions of dollars, but they did also bring up the topic of DTN and using=
 it commercially. =A0This is definitely something that could be explored in=
 the future if a commercial angle seems appropriate. =A0Hope everyone is en=
joying their day so far. Let me know what you guys think.<br>

&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Rohit<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:[email-masked].=
net">[email-masked]</a> [mailto:<a href=
=3D"mailto:[email-masked]">dtn-interest-=
[email-masked]</a>] On Behalf Of <a href=3D"mailto:dt=
[email-masked]">dtn-interest-request@maill=
ists.intel-research.net</a><br>

&gt; Sent: Monday, March 01, 2010 10:12 AM<br>
&gt; To: <a href=3D"mailto:[email-masked]">dtn-i=
[email-masked]</a><br>
&gt; Subject: dtn-interest Digest, Vol 30, Issue 1<br>
&gt;<br>
&gt; Send dtn-interest mailing list submissions to<br>
&gt; =A0 =A0 =A0 =A0<a href=3D"mailto:[email-masked]=
.net">[email-masked]</a><br>
&gt;<br>
&gt; To subscribe or unsubscribe via the World Wide Web, visit<br>
&gt; =A0 =A0 =A0 =A0<a href=3D"http://maillists.intel-research.net/mailman/=
listinfo/dtn-interest" target=3D"_blank">http://maillists.intel-research.ne=
t/mailman/listinfo/dtn-interest</a><br>
&gt; or, via email, send a message with subject or body &#39;help&#39; to<b=
r>
&gt; =A0 =A0 =A0 =A0<a href=3D"mailto:[email-masked]=
research.net">[email-masked]</a><br>
&gt;<br>
&gt; You can reach the person managing the list at<br>
&gt; =A0 =A0 =A0 =A0<a href=3D"mailto:[email-masked]=
search.net">[email-masked]</a><br>
&gt;<br>
&gt; When replying, please edit your Subject line so it is more specific<br=
>
&gt; than &quot;Re: Contents of dtn-interest digest...&quot;<br>
&gt;<br>
&gt;<br>
&gt; Today&#39;s Topics:<br>
&gt;<br>
&gt; =A0 1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)<br>
&gt; =A0 2. Re: DTNRG: let&#39;s elevate the level of discourse (Phani Rohi=
t)<br>
&gt; =A0 3. Re: DTNRG: let&#39;s elevate the level of discourse (Greg Troxe=
l)<br>
&gt; =A0 4. Re: DTNRG: let&#39;s elevate the level of discourse (Daniel Ell=
ard)<br>
&gt; =A0 5. Re: DTNRG: let&#39;s elevate the level of discourse (Daniel Ell=
ard)<br>
&gt;<br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
<br>
&gt;<br>
&gt; Message: 1<br>
&gt; Date: Sun, 28 Feb 2010 17:27:29 -0500<br>
&gt; From: Rajesh Krishnan &lt;<a href=3D"mailto:[email-masked]">rjs=
[email-masked]</a>&gt;<br>
&gt; Subject: [dtn-interest] sketch of RFC5050 portions in Haskell<br>
&gt; To: <a href=3D"mailto:[email-masked]">dtn-interest@mai=
lman.dtnrg.org</a><br>
&gt; Message-ID:<br>
&gt; =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:ebcd90ee1002281427h3132144q6b873a=
[email-masked]">ebcd90ee1002281427h3132144q6b873a9099846dbc@mail=
.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;<br>
&gt; I started implementing RFC5050 in Haskell, with a goal of fitting it<b=
r>
&gt; in less than 500 lines of code (which was roughly the size of the<br>
&gt; Xmonad tiling window manager in 2007).<br>
&gt; Clearly I had underestimated the challenge and did not get very far.<b=
r>
&gt; I figured I might as well set this free and move on.<br>
&gt;<br>
&gt; <a href=3D"http://www.rajesh-krishnan.com/repos" target=3D"_blank">htt=
p://www.rajesh-krishnan.com/repos</a><br>
&gt;<br>
&gt; -Rajesh<br>
&gt;<br>
&gt; P.S.: =A0SDNV is a good exercise for a first course in functional<br>
&gt; programming. =A0 One that may cause CS students to pay attention to<br=
>
&gt; DTN/BP as a side benefit. =A0:)<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; Message: 2<br>
&gt; Date: Mon, 1 Mar 2010 00:10:33 -0500<br>
&gt; From: Phani Rohit &lt;<a href=3D"mailto:[email-masked]">mprohit@gma=
il.com</a>&gt;<br>
&gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of<br>
&gt; =A0 =A0 =A0 =A0discourse<br>
&gt; To: Rajesh Krishnan &lt;<a href=3D"mailto:[email-masked]">rjsh.=
[email-masked]</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:[email-masked]">dtn-interest@mai=
lman.dtnrg.org</a><br>
&gt; Message-ID:<br>
&gt; =A0 =A0 =A0 =A0&lt;<a href=3D"mailto:38f37aa41002282110m4946139etee6a4=
[email-masked]">38f37aa41002282110m4946139etee6a45e14296016c@ma=
il.gmail.com</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3D&quot;iso-8859-1&quot;<br>
&gt;<br>
&gt; Hi All,<br>
&gt;<br>
&gt; I am posting for the first time in this research group. Please excuse =
me if<br>
&gt; my idea does not make sense. I have an idea for using DTN&#39;s in day=
 to day<br>
&gt; life. I don&#39;t know its commercial value.<br>
&gt;<br>
&gt; Recently I visited New York City, one of the busiest and happening pla=
ce.<br>
&gt; The moment you get in to sub way station the communication with the wo=
rld is<br>
&gt; lost. so =A0why can&#39;t any body have a simple DTN deployment like b=
unch of<br>
&gt; broker nodes sitting at the opening of each station and route the bund=
les<br>
&gt; via moving trains and deliver it to outer world. A simple app in this<=
br>
&gt; scenario would be SMS application running on DTN or chat client.<br>
&gt;<br>
&gt; Please let me know if this make sense =A0or if you need any further<br=
>
&gt; explanation.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Rohit<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan &lt;<a href=3D"mailto=
:[email-masked]">[email-masked]</a>&gt;wrote:<br>
&gt;<br>
&gt;&gt; Hi Brenton,<br>
&gt;&gt;<br>
&gt;&gt; Interesting game ideas.<br>
&gt;&gt;<br>
&gt;&gt; &gt;From time to time, as my professional life has demanded, I hav=
e tried<br>
&gt;&gt; to use or work with BP. =A0 I will happily be the fellow who is go=
ing to<br>
&gt;&gt; use BP, but the fact of the matter is I have not created or found =
a<br>
&gt;&gt; deployment/application that I can use in my daily life.<br>
&gt;&gt;<br>
&gt;&gt; There are several possible vectors that can achieve critical mass =
for<br>
&gt;&gt; DTN/BP:<br>
&gt;&gt; =A0 =A0- seeding into future-oriented systems (which some Governme=
nt<br>
&gt;&gt; agencies have done), hoping it will grow big in a few decades<br>
&gt;&gt; =A0 =A0- a new application or a content overlay =A0that is general=
ly<br>
&gt;&gt; useful, that happens to use BP, and grows popular rapidly =A0[ our=
<br>
&gt;&gt; current discussion ]<br>
&gt;&gt; =A0 =A0- through regulation or acquisition policy (may be as succe=
ssful<br>
&gt;&gt; as GOSIP and Ada :)<br>
&gt;&gt; =A0 =A0- through education<br>
&gt;&gt;<br>
&gt;&gt; One idea was to see if it makes sense to explore BP in place of<br=
>
&gt;&gt; packetbb as a mechanism to gateway between diverse MANETs (require=
<br>
&gt;&gt; this as acquisition policy); one problem there is MANETs are still=
<br>
&gt;&gt; looking for their killer commercial application too. =A0 As 3G/4G<=
br>
&gt;&gt; coverage increases, the need for multi-hop DTN routing will be<br>
&gt;&gt; increasingly pushed to challenging regimes of space, underground,<=
br>
&gt;&gt; underwater, etc. =A0 There will be niche terrestrial opportunities=
<br>
&gt;&gt; (reindeer nets) and opportunities in virtual overlays (for distrib=
uted<br>
&gt;&gt; algorithm purists).<br>
&gt;&gt;<br>
&gt;&gt; Regardless of whether BP achieves population inversion or not (eit=
her<br>
&gt;&gt; over application overlay protocols or =A0Layer 2/3 encapsulations)=
,<br>
&gt;&gt; important lessons can be learned from achieving critical mass arou=
nd<br>
&gt;&gt; the BP. =A0 Without critical mass, many of the ideas generated for=
 ATM<br>
&gt;&gt; research would not have been; some of those ideas (or the competit=
ion<br>
&gt;&gt; they created) transformed IP networks.<br>
&gt;&gt;<br>
&gt;&gt; During one of my earlier briefings to the NSF FIND folks to explor=
e<br>
&gt;&gt; synergies, I found they (i) wanted freedom from any constraints, B=
P or<br>
&gt;&gt; =A0otherwise, OR (ii) wanted critical mass such as that provided b=
y<br>
&gt;&gt; TCP/IP and 802.11 in order to justify living with the constraints.=
<br>
&gt;&gt; There was some concern expressed around the ramp up time and perce=
ived<br>
&gt;&gt; complexity of the BP. =A0In any case, I had failed to convince the=
m of<br>
&gt;&gt; the enormous opportunity that was available in the middle ground -=
-<br>
&gt;&gt; between clean slate and retrofit -- for novel routing and naming<b=
r>
&gt;&gt; research. =A0 BP offers a near clean slate, the benefits of an exi=
sting<br>
&gt;&gt; research community that provides the nucleus, and a good metadata<=
br>
&gt;&gt; extension block, especially for routing, naming, content-networkin=
g,<br>
&gt;&gt; and context/location-aware computing. =A0I have not given up hope;=
 =A0BP<br>
&gt;&gt; on NSF GENI would be a good way to keep DTN/BP more relevant to th=
e<br>
&gt;&gt; mainstream networking community.<br>
&gt;&gt;<br>
&gt;&gt; On the other hand, when I spoke to folks who do commercialization,=
<br>
&gt;&gt; their question to me was what is one thing you can do with the BP<=
br>
&gt;&gt; today =A0that they cannot hire programmers to do over other popula=
r<br>
&gt;&gt; Internet-based technologies. =A0They can do meter reading, elevato=
r net,<br>
&gt;&gt; email or content delivery to remote facilities using custom<br>
&gt;&gt; applications that are disruption-tolerant, and without buying into=
 the<br>
&gt;&gt; full DTN/BP program. =A0 =A0Clearly they do not care about technic=
al<br>
&gt;&gt; features, elegance, or potential for transformation provided by th=
e<br>
&gt;&gt; DTN architecture. =A0 Disruptive uses of the BP in settings would =
be<br>
&gt;&gt; interesting in order to exercise non-traditional routing and rich<=
br>
&gt;&gt; naming; =A0otherwise, the question of why not do it with SOAP (or<=
br>
&gt;&gt; alternative for which I can hire low-cost programmers) will persis=
t?<br>
&gt;&gt; There need to see value additions that can be monetized in the sho=
rt<br>
&gt;&gt; term.<br>
&gt;&gt;<br>
&gt;&gt; While all of the applications you mention will exercise the BP, al=
l of<br>
&gt;&gt; them can be expeditiously done on an iPhone/Droid and can take<br>
&gt;&gt; advantage of remote servers.<br>
&gt;&gt; Regardless, the playing you suggest is better than the theorizing =
I<br>
&gt;&gt; provide above.<br>
&gt;&gt;<br>
&gt;&gt; Best Regards,<br>
&gt;&gt; Rajesh<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker &lt;<a href=3D"ma=
ilto:[email-masked]">[email-masked]</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hi Rajesh,<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0Why is it always some other poor fellow who is=
 going to use BP? =A0I<br>
&gt;&gt; &gt; think we should be trying to think of ways to use it ourselve=
s in our<br>
&gt;&gt; &gt; daily lives. =A0I feel like there are a lot of possibilities.=
 =A0Even though<br>
&gt;&gt; &gt; access to expensive (3G, wimax) infrastructure is increasing,=
 access to<br>
&gt;&gt; &gt; cheap infrastructure (open wifi APs) is getting more restrict=
ive. =A0Lots<br>
&gt;&gt; &gt; of communication I do is pretty local, and BP (and associated=
<br>
&gt;&gt; &gt; technologies) is a very robust tool for that sort of thing.<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; =A0 =A0 =A0 =A0One thing people at our lab have been talking =
about is trying to<br>
&gt;&gt; &gt; organize some sort of BP-based activity at the IETF. =A0Not a=
<br>
&gt;&gt; &gt; disconnectathon that focuses specifically on technical intero=
perability,<br>
&gt;&gt; &gt; but something that gives people a motivation to bring a hands=
et or<br>
&gt;&gt; &gt; laptop with a BPA on it and play with it during those boring =
sessions<br>
&gt;&gt; &gt; they don&#39;t really care about.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Some ideas we have had:<br>
&gt;&gt; &gt; - bundle scavenger hunt. =A0There are bundles that can be fou=
nd with<br>
&gt;&gt; &gt; varying degrees of difficulty. =A0You get points for receivin=
g them.<br>
&gt;&gt; &gt; - bundle trivia. =A0Like the bundle scavenger hunt, but you w=
ould have to<br>
&gt;&gt; &gt; send responses to some EID.<br>
&gt;&gt; &gt; - bundle mad libs. =A0I don&#39;t quite understand this one, =
but people were<br>
&gt;&gt; &gt; excited about it.<br>
&gt;&gt; &gt; - bundle capture the flag. =A0OK, I&#39;ll stop.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Stupid idea?<br>
&gt;&gt; &gt; Already been done?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt; Brenton<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Rajesh Krishnan wrote:<br>
&gt;&gt; &gt;&gt; In think in Parikh et al.&#39;s application, DTN was usef=
ul to let chat<br>
&gt;&gt; &gt;&gt; participants catch up on the conversation they missed whi=
le they were<br>
&gt;&gt; &gt;&gt; temporarily disconnected; these are environments where en=
d-to-end<br>
&gt;&gt; &gt;&gt; access to one server cannot be assured.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; The sailboat-based email delivery is definitely interesti=
ng.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Best Regards,<br>
&gt;&gt; &gt;&gt; Rajesh<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM=
/VE7TFX)<br>
&gt;&gt; &gt;&gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
a</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;&gt;&gt; What I find strange is that the DTN community isn=
&#39;t trying to run<br>
&gt;&gt; email<br>
&gt;&gt; &gt;&gt;&gt;&gt; and chat over BP. =A0Those are natural applicatio=
ns for DTN, but yet<br>
&gt;&gt; &gt;&gt;&gt;&gt; there&#39;s not (to my knowledge) a release of an=
 MTA, jabber client,<br>
&gt;&gt; jabber<br>
&gt;&gt; &gt;&gt;&gt;&gt; server, etc., that uses BP, and I don&#39;t hear =
anyone talking about<br>
&gt;&gt; having<br>
&gt;&gt; &gt;&gt;&gt;&gt; problems running those programs on the global dbo=
ne.<br>
&gt;&gt; &gt;&gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;&gt; Is anyone trying to use BP to do anything other t=
han tests?<br>
&gt;&gt; &gt;&gt;&gt; I can&#39;t see how a realtime application like jabbe=
r would be something<br>
&gt;&gt; &gt;&gt;&gt; DTN would address; surely disconnected jabber is emai=
l, no?<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; One natural application for DTN is providing email se=
rvice to<br>
&gt;&gt; &gt;&gt;&gt; sailboats on the gulf coast of British Columbia.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; The stretch of water up the Strait from Vancouver to =
the north end of<br>
&gt;&gt; &gt;&gt;&gt; Vancouver Is. is a patchwork of fjords, islets, and b=
lack holes of<br>
&gt;&gt; &gt;&gt;&gt; cellular connectivity. =A0In almost every marina, ema=
il access is found<br>
&gt;&gt; &gt;&gt;&gt; by subscription only to services such as BBX. =A0Ther=
e is no access<br>
&gt;&gt; &gt;&gt;&gt; outside of the pay-per-mail marina wifi access points=
.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; There is no hope of running land-based network backha=
ul into most of<br>
&gt;&gt; &gt;&gt;&gt; the locations sailors would park in. =A0A BP-based em=
ail network is a<br>
&gt;&gt; &gt;&gt;&gt; likely option for people on the coast living away fro=
m land-based<br>
&gt;&gt; &gt;&gt;&gt; infrastructure.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; --lyndon<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; _______________________________________________<br>
&gt;&gt; &gt;&gt; dtn-interest mailing list<br>
&gt;&gt; &gt;&gt; <a href=3D"mailto:[email-masked]=
et">[email-masked]</a><br>
&gt;&gt; &gt;&gt; <a href=3D"http://maillists.intel-research.net/mailman/li=
stinfo/dtn-interest" target=3D"_blank">http://maillists.intel-research.net/=
mailman/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; dtn-interest mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:[email-masked]">=
[email-masked]</a><br>
&gt;&gt; &gt; <a href=3D"http://maillists.intel-research.net/mailman/listin=
fo/dtn-interest" target=3D"_blank">http://maillists.intel-research.net/mail=
man/listinfo/dtn-interest</a><br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dtn-interest mailing list<br>
&gt;&gt; <a href=3D"mailto:[email-masked]">dtn-i=
[email-masked]</a><br>
&gt;&gt; <a href=3D"http://maillists.intel-research.net/mailman/listinfo/dt=
n-interest" target=3D"_blank">http://maillists.intel-research.net/mailman/l=
istinfo/dtn-interest</a><br>
&gt;&gt;<br>
&gt; -------------- next part --------------<br>
&gt; An HTML attachment was scrubbed...<br>
&gt; URL: <a href=3D"http://maillists.intel-research.net/pipermail/dtn-inte=
rest/attachments/20100301/5528783a/attachment-0001.html" target=3D"_blank">=
http://maillists.intel-research.net/pipermail/dtn-interest/attachments/2010=
0301/5528783a/attachment-0001.html</a><br>

&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; Message: 3<br>
&gt; Date: Mon, 01 Mar 2010 09:02:54 -0500<br>
&gt; From: Greg Troxel &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt;<br>
&gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of<br>
&gt; =A0 =A0 =A0 =A0discourse<br>
&gt; To: &quot;Lyndon Nerenberg \(VE6BBM\/VE7TFX\)&quot; &lt;<a href=3D"mai=
lto:[email-masked]">[email-masked]</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:[email-masked]">dtn-interest@mai=
lman.dtnrg.org</a><br>
&gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]">rm=
[email-masked]</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3D&quot;us-ascii&quot;<br>
&gt;<br>
&gt;<br>
&gt; &quot;Lyndon Nerenberg (VE6BBM/VE7TFX)&quot; =A0&lt;<a href=3D"mailto:=
[email-masked]">[email-masked]</a>&gt; writes:<br>
&gt;<br>
&gt;&gt; I can&#39;t see how a realtime application like jabber would be so=
mething<br>
&gt;&gt; DTN would address; surely disconnected jabber is email, no?<br>
&gt;<br>
&gt; Disconnection can happen on many time scales. =A0If it&#39;s a few min=
utes,<br>
&gt; it&#39;s still different than email, and you can still have presence<b=
r>
&gt; indications.<br>
&gt;<br>
&gt; Still, my real point is that until there&#39;s freely available code t=
o plug<br>
&gt; in alternate transports for things like pidgin, and enough dbone<br>
&gt; infrastructure that people can actually use this, it&#39;s really hard=
 to<br>
&gt; know under what circumstances DTN will be really useful compared to wh=
at<br>
&gt; we have now.<br>
&gt; -------------- next part --------------<br>
&gt; A non-text attachment was scrubbed...<br>
&gt; Name: not available<br>
&gt; Type: application/pgp-signature<br>
&gt; Size: 194 bytes<br>
&gt; Desc: not available<br>
&gt; Url : <a href=3D"http://maillists.intel-research.net/pipermail/dtn-int=
erest/attachments/20100301/2b1662d0/attachment-0001.bin" target=3D"_blank">=
http://maillists.intel-research.net/pipermail/dtn-interest/attachments/2010=
0301/2b1662d0/attachment-0001.bin</a><br>

&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; Message: 4<br>
&gt; Date: Mon, 01 Mar 2010 10:08:10 -0500<br>
&gt; From: Daniel Ellard &lt;<a href=3D"mailto:[email-masked]">dellard@bbn=
.com</a>&gt;<br>
&gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of<br>
&gt; =A0 =A0 =A0 =A0discourse<br>
&gt; To: Brenton Walker &lt;<a href=3D"mailto:[email-masked]">brenton@=
cs.wisc.edu</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:[email-masked]">dtn-interest@mai=
lman.dtnrg.org</a><br>
&gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]">4B8BD85A.2=
[email-masked]</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;<br>
&gt; Brenton Walker wrote:<br>
&gt;&gt; Hi Rajesh,<br>
&gt;&gt; =A0 =A0 =A0 Why is it always some other poor fellow who is going t=
o use BP?<br>
&gt;<br>
&gt; We might *all* be that poor fellow at some point:<br>
&gt;<br>
&gt; <a href=3D"http://www.npr.org/templates/story/story.php?storyId=3D1241=
25001&amp;ft=3D1&amp;f=3D1007" target=3D"_blank">http://www.npr.org/templat=
es/story/story.php?storyId=3D124125001&amp;ft=3D1&amp;f=3D1007</a><br>
&gt;<br>
&gt; -Dan<br>
&gt;<br>
&gt; --<br>
&gt; Daniel Ellard, Ph.D.<br>
&gt; Senior Scientist, Network Research<br>
&gt; BBN Technologies<br>
&gt; 10 Moulton Street<br>
&gt; Cambridge, MA 02138<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; Message: 5<br>
&gt; Date: Mon, 01 Mar 2010 10:12:07 -0500<br>
&gt; From: Daniel Ellard &lt;<a href=3D"mailto:[email-masked]">dellard@bbn=
.com</a>&gt;<br>
&gt; Subject: Re: [dtn-interest] DTNRG: let&#39;s elevate the level of<br>
&gt; =A0 =A0 =A0 =A0discourse<br>
&gt; To: Brenton Walker &lt;<a href=3D"mailto:[email-masked]">brenton@=
cs.wisc.edu</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:[email-masked]">dtn-interest@mai=
lman.dtnrg.org</a><br>
&gt; Message-ID: &lt;<a href=3D"mailto:[email-masked]">4B8BD947.3=
[email-masked]</a>&gt;<br>
&gt; Content-Type: text/plain; charset=3DISO-8859-1<br>
&gt;<br>
&gt; Brenton Walker wrote:<br>
&gt;&gt; Hi Rajesh,<br>
&gt;&gt; =A0 =A0 =A0 Why is it always some other poor fellow who is going t=
o use BP? =A0I<br>
&gt;&gt; think we should be trying to think of ways to use it ourselves in =
our<br>
&gt;&gt; daily lives. =A0I feel like there are a lot of possibilities. =A0E=
ven though<br>
&gt;&gt; access to expensive (3G, wimax) infrastructure is increasing, acce=
ss to<br>
&gt;&gt; cheap infrastructure (open wifi APs) is getting more restrictive. =
=A0Lots<br>
&gt;&gt; of communication I do is pretty local, and BP (and associated<br>
&gt;&gt; technologies) is a very robust tool for that sort of thing.<br>
&gt;<br>
&gt; There&#39;s a group inside BBN who have been getting email and<br>
&gt; web access (and maybe some other IP services) exclusively<br>
&gt; via BP for a few months. =A0So far, so good.<br>
&gt;<br>
&gt;&gt; =A0 =A0 =A0 One thing people at our lab have been talking about is=
 trying to<br>
&gt;&gt; organize some sort of BP-based activity at the IETF. =A0Not a<br>
&gt;&gt; disconnectathon that focuses specifically on technical interoperab=
ility,<br>
&gt;&gt; but something that gives people a motivation to bring a handset or=
<br>
&gt;&gt; laptop with a BPA on it and play with it during those boring sessi=
ons<br>
&gt;&gt; they don&#39;t really care about.<br>
&gt;&gt;<br>
&gt;&gt; Some ideas we have had:<br>
&gt;&gt; - bundle scavenger hunt. =A0There are bundles that can be found wi=
th<br>
&gt;&gt; varying degrees of difficulty. =A0You get points for receiving the=
m.<br>
&gt;&gt; - bundle trivia. =A0Like the bundle scavenger hunt, but you would =
have to<br>
&gt;&gt; send responses to some EID.<br>
&gt;&gt; - bundle mad libs. =A0I don&#39;t quite understand this one, but p=
eople were<br>
&gt;&gt; excited about it.<br>
&gt;&gt; - bundle capture the flag. =A0OK, I&#39;ll stop.<br>
&gt;<br>
&gt; It sounds like fun. =A0Lots of work to set up, but fun, if you<br>
&gt; can find volunteers.<br>
&gt;<br>
&gt; And you need to find someone very honest to be in charge of<br>
&gt; disrupting the network in a completely fair manner... =A0:-)<br>
&gt;<br>
&gt; -Dan<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Daniel Ellard, Ph.D.<br>
&gt; Senior Scientist, Network Research<br>
&gt; BBN Technologies<br>
&gt; 10 Moulton Street<br>
&gt; Cambridge, MA 02138<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dtn-interest mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">dtn-inter=
[email-masked]</a><br>
&gt; <a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-in=
terest" target=3D"_blank">http://maillists.intel-research.net/mailman/listi=
nfo/dtn-interest</a><br>
&gt;<br>
&gt;<br>
&gt; End of dtn-interest Digest, Vol 30, Issue 1<br>
&gt; *******************************************<br>
&gt;<br>
<br>
_______________________________________________<br>
dtn-interest mailing list<br>
<a href=3D"mailto:[email-masked]">dtn-interest@m=
aillists.intel-research.net</a><br>
<a href=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interes=
t" target=3D"_blank">http://maillists.intel-research.net/mailman/listinfo/d=
tn-interest</a><br>
</div></div></blockquote></div><br></div>

--0016e64806784b52de0480c0d612--

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Brenton Walker <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 1 Mar 2010 09:39:16 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] New BP protocol version

> -----Original Message-----
> From: [email-masked] [mailto:dtn-
> [email-masked]] On Behalf Of Brenton Walker
> Sent: Sunday, February 28, 2010 8:13 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] New BP protocol version
> 
> Hi Scott,
> 
> 
> Burleigh, Scott C (313B) wrote:
> > Brenton, on the first of your two points: the approach I proposed only
> supplemented the information in the primary block, overriding nothing.
> 
> Of course you would know better what the intention of the RFC5050
> authors was :-).  I can only work based on my best understanding of what
> the docs say and what I've read on this list since I got involved in the
> area.  So here is my understanding: that the primary purpose of the
> lifetime field is for bundle expiry.

Yes.

> From the doc:
>    Lifetime:   The lifetime field is an SDNV that indicates the time at
>       which the bundle's payload will no longer be useful, encoded as a
>       number of seconds past the creation time.  When the current time
>       is greater than the creation time plus the lifetime, bundle nodes
>       need no longer retain or forward the bundle; the bundle may be
>       deleted from the network.
> That will still be the default interpretation of the field in your
> proposal, right?  So an extension header that takes away that function
> and replaces it with some other criterion is overriding the field.

Not at all.  As I wrote, the Bundle Age field (the only field in the extension block; supplemental data) would simply be used as the value of "current time" in making bundle expiration decisions when creation timestamp time is zero.  Every word of RFC5050 section 5.5 would remain fully in effect.  (If it didn't, the extension would be non-compliant.)  The only thing that you might claim this extension overrides is the implementation-specific manner in which "the current time" is determined, i.e., it would override the clock.  But nothing in the spec.

> >   And the logic was really very simple, wasn't it?  In what way was it
> more complex than adding and testing additional fields and flags in the
> primary block, as the reltime draft proposes?
> 
> I think both are more complex than they need to be.  It would be
> simplest if both AT and RT nodes processed the header in the same way.
> I've been arguing is that an RT lifetime can support all cases.  People
> question that, which is fine, but if that is possible it /is/ less
> complex.  That is why I found your 2nd proposal, to move all expiry
> criteria to extension headers, compelling.
> 
> > Is it just that it requires parsing an additional extension block?
> Your implementation already has to have some sort of general mechanism
> for parsing and processing extension blocks, though, in order to be
> conformant, so I don't see how one more would add significantly to the
> complexity of the code.
> 
> No, it is not just that it requires parsing an additional extension block.
> 
> 
> > In any case, I don't think any of us would argue that complexity should
> always be avoided.  Complexity is a cost that has to be traded off against
> benefit, like any other.  The benefit in this case may be a community
> benefit rather than one that accrues specifically to your deployments, but
> that's what open protocol development is all about: we all accept design
> compromises.  There's plenty about RFC5050 that isn't especially well-
> suited to space flight operations.  We can use it anyway.
> 
> Yes, definitely.  I am arguing against what I consider unnecessary
> complexity.
> 
> 
> > As to your other point: your suggestion that determining the age of a
> bundle by somehow figuring out the signal propagation delay at every hop,
> in whatever manner can be devised for each individual convergence-layer
> channel, and aggregating all those delays and all queuing delays -- and
> counting on every other node in the end-to-end path having done so as well,
> without error -- might be "more elegant" than merely sampling a clock is
> intriguing.  Can you say a little more about this?  I can see where you
> might have no alternative in an environment where you can't count on clock
> accuracy, but I can't think of any way it would be preferable if you have
> an accurate clock to use instead.
> 
> I see it as more elegant in the sense that prop delay is a property of
> the lower layers.  If nodes do have access to accurate time, computing
> prop delay can be handled in a pretty uniform way.  In outer space
> applications I am assuming you can compute the prop delay based on
> distance.  I'm also assuming that you have to do this sort of
> computation already to figure the appropriate lifetime.  Is that wrong?
>  In nodes without AT you may not be able to compute prop delay.  But
> those nodes don't have AT either, so you are not loosing anything.
> 
> I'm not saying you could do it without any error, but I do expect the
> error would be negligible relative to bundle lifetime.

Okay, I think we have descended into arguing over the meanings of words, a sure sign that any continuation of this thread ought to be taken off-list.  We clearly don't agree on what terms like "override" and "elegant" and "technical argument" mean.

Scott

From: "Chaudhari, Rohit K." <[email-masked]>
To: Rajesh Krishnan <[email-masked]>
Date: Mon, 1 Mar 2010 11:01:09 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Hey Rajesh,

The extension of 3G is also a great (and probably preferred) alternative since infrastructure is definitely more stable than queuing messages in the store-and-forward operations of DTN.  But the 3G coverage would vary network to network since some 3G providers do not have as extensive coverage.  Depending on the overall costs, DTN could be more cost efficient and be universal across all networks, I would presume, but I could be wrong here.  Even if 3G is expanded a more long-term goal with DTN could be greatly beneficial.  You do, however, bring up a valid point, but once again, cost is always a factor.

-Rohit

-----Original Message-----
From: Rajesh Krishnan [mailto:[email-masked]]
Sent: Monday, March 01, 2010 10:56 AM
To: Chaudhari, Rohit K.
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Rohit,

This could be a useful service, but if all we did was extend 3G (or
other Internet) coverage into the stations, will we get similar
results?
Is a multi-hop DTN necessary for this application? Endpoints can queue
up messages till the next station where they connect to
infrastructure.

-Rajesh

On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.
<[email-masked]> wrote:
> Hi all,
>
> My name is Rohit as well and I recently joined the DTN-interest mailing list this morning.  As the other Rohit suggested, I too have recently read about NYC subways.  Over 6 million people use the subway in NYC everyday and to think that cell phone communications within them is pretty much non-existent is pretty deplorable.  I know that at one point NYC wanted to redo the cell infrastructure in the subways which would cost them tens of millions of dollars, but they did also bring up the topic of DTN and using it commercially.  This is definitely something that could be explored in the future if a commercial angle seems appropriate.  Hope everyone is enjoying their day so far. Let me know what you guys think.
>
> Thanks,
>
> Rohit
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, March 01, 2010 10:12 AM
> To: [email-masked]
> Subject: dtn-interest Digest, Vol 30, Issue 1
>
> Send dtn-interest mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dtn-interest digest..."
>
>
> Today's Topics:
>
>   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
>   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
>   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
>   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Feb 2010 17:27:29 -0500
> From: Rajesh Krishnan <[email-masked]>
> Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
> To: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I started implementing RFC5050 in Haskell, with a goal of fitting it
> in less than 500 lines of code (which was roughly the size of the
> Xmonad tiling window manager in 2007).
> Clearly I had underestimated the challenge and did not get very far.
> I figured I might as well set this free and move on.
>
> http://www.rajesh-krishnan.com/repos
>
> -Rajesh
>
> P.S.:  SDNV is a good exercise for a first course in functional
> programming.   One that may cause CS students to pay attention to
> DTN/BP as a side benefit.  :)
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 1 Mar 2010 00:10:33 -0500
> From: Phani Rohit <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Rajesh Krishnan <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi All,
>
> I am posting for the first time in this research group. Please excuse me if
> my idea does not make sense. I have an idea for using DTN's in day to day
> life. I don't know its commercial value.
>
> Recently I visited New York City, one of the busiest and happening place.
> The moment you get in to sub way station the communication with the world is
> lost. so  why can't any body have a simple DTN deployment like bunch of
> broker nodes sitting at the opening of each station and route the bundles
> via moving trains and deliver it to outer world. A simple app in this
> scenario would be SMS application running on DTN or chat client.
>
> Please let me know if this make sense  or if you need any further
> explanation.
>
> Thanks,
> Rohit
>
>
> On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan <[email-masked]>wrote:
>
>> Hi Brenton,
>>
>> Interesting game ideas.
>>
>> >From time to time, as my professional life has demanded, I have tried
>> to use or work with BP.   I will happily be the fellow who is going to
>> use BP, but the fact of the matter is I have not created or found a
>> deployment/application that I can use in my daily life.
>>
>> There are several possible vectors that can achieve critical mass for
>> DTN/BP:
>>    - seeding into future-oriented systems (which some Government
>> agencies have done), hoping it will grow big in a few decades
>>    - a new application or a content overlay  that is generally
>> useful, that happens to use BP, and grows popular rapidly  [ our
>> current discussion ]
>>    - through regulation or acquisition policy (may be as successful
>> as GOSIP and Ada :)
>>    - through education
>>
>> One idea was to see if it makes sense to explore BP in place of
>> packetbb as a mechanism to gateway between diverse MANETs (require
>> this as acquisition policy); one problem there is MANETs are still
>> looking for their killer commercial application too.   As 3G/4G
>> coverage increases, the need for multi-hop DTN routing will be
>> increasingly pushed to challenging regimes of space, underground,
>> underwater, etc.   There will be niche terrestrial opportunities
>> (reindeer nets) and opportunities in virtual overlays (for distributed
>> algorithm purists).
>>
>> Regardless of whether BP achieves population inversion or not (either
>> over application overlay protocols or  Layer 2/3 encapsulations),
>> important lessons can be learned from achieving critical mass around
>> the BP.   Without critical mass, many of the ideas generated for ATM
>> research would not have been; some of those ideas (or the competition
>> they created) transformed IP networks.
>>
>> During one of my earlier briefings to the NSF FIND folks to explore
>> synergies, I found they (i) wanted freedom from any constraints, BP or
>>  otherwise, OR (ii) wanted critical mass such as that provided by
>> TCP/IP and 802.11 in order to justify living with the constraints.
>> There was some concern expressed around the ramp up time and perceived
>> complexity of the BP.  In any case, I had failed to convince them of
>> the enormous opportunity that was available in the middle ground --
>> between clean slate and retrofit -- for novel routing and naming
>> research.   BP offers a near clean slate, the benefits of an existing
>> research community that provides the nucleus, and a good metadata
>> extension block, especially for routing, naming, content-networking,
>> and context/location-aware computing.  I have not given up hope;  BP
>> on NSF GENI would be a good way to keep DTN/BP more relevant to the
>> mainstream networking community.
>>
>> On the other hand, when I spoke to folks who do commercialization,
>> their question to me was what is one thing you can do with the BP
>> today  that they cannot hire programmers to do over other popular
>> Internet-based technologies.  They can do meter reading, elevator net,
>> email or content delivery to remote facilities using custom
>> applications that are disruption-tolerant, and without buying into the
>> full DTN/BP program.    Clearly they do not care about technical
>> features, elegance, or potential for transformation provided by the
>> DTN architecture.   Disruptive uses of the BP in settings would be
>> interesting in order to exercise non-traditional routing and rich
>> naming;  otherwise, the question of why not do it with SOAP (or
>> alternative for which I can hire low-cost programmers) will persist?
>> There need to see value additions that can be monetized in the short
>> term.
>>
>> While all of the applications you mention will exercise the BP, all of
>> them can be expeditiously done on an iPhone/Droid and can take
>> advantage of remote servers.
>> Regardless, the playing you suggest is better than the theorizing I
>> provide above.
>>
>> Best Regards,
>> Rajesh
>>
>> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <[email-masked]>
>> wrote:
>> > Hi Rajesh,
>> >        Why is it always some other poor fellow who is going to use BP?  I
>> > think we should be trying to think of ways to use it ourselves in our
>> > daily lives.  I feel like there are a lot of possibilities.  Even though
>> > access to expensive (3G, wimax) infrastructure is increasing, access to
>> > cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
>> > of communication I do is pretty local, and BP (and associated
>> > technologies) is a very robust tool for that sort of thing.
>> >
>> >        One thing people at our lab have been talking about is trying to
>> > organize some sort of BP-based activity at the IETF.  Not a
>> > disconnectathon that focuses specifically on technical interoperability,
>> > but something that gives people a motivation to bring a handset or
>> > laptop with a BPA on it and play with it during those boring sessions
>> > they don't really care about.
>> >
>> > Some ideas we have had:
>> > - bundle scavenger hunt.  There are bundles that can be found with
>> > varying degrees of difficulty.  You get points for receiving them.
>> > - bundle trivia.  Like the bundle scavenger hunt, but you would have to
>> > send responses to some EID.
>> > - bundle mad libs.  I don't quite understand this one, but people were
>> > excited about it.
>> > - bundle capture the flag.  OK, I'll stop.
>> >
>> > Stupid idea?
>> > Already been done?
>> >
>> > Thanks,
>> > Brenton
>> >
>> >
>> >
>> > Rajesh Krishnan wrote:
>> >> In think in Parikh et al.'s application, DTN was useful to let chat
>> >> participants catch up on the conversation they missed while they were
>> >> temporarily disconnected; these are environments where end-to-end
>> >> access to one server cannot be assured.
>> >>
>> >> The sailboat-based email delivery is definitely interesting.
>> >>
>> >> Best Regards,
>> >> Rajesh
>> >>
>> >>
>> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
>> >> <[email-masked]> wrote:
>> >>>> What I find strange is that the DTN community isn't trying to run
>> email
>> >>>> and chat over BP.  Those are natural applications for DTN, but yet
>> >>>> there's not (to my knowledge) a release of an MTA, jabber client,
>> jabber
>> >>>> server, etc., that uses BP, and I don't hear anyone talking about
>> having
>> >>>> problems running those programs on the global dbone.
>> >>>>
>> >>>> Is anyone trying to use BP to do anything other than tests?
>> >>> I can't see how a realtime application like jabber would be something
>> >>> DTN would address; surely disconnected jabber is email, no?
>> >>>
>> >>> One natural application for DTN is providing email service to
>> >>> sailboats on the gulf coast of British Columbia.
>> >>>
>> >>> The stretch of water up the Strait from Vancouver to the north end of
>> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes of
>> >>> cellular connectivity.  In almost every marina, email access is found
>> >>> by subscription only to services such as BBX.  There is no access
>> >>> outside of the pay-per-mail marina wifi access points.
>> >>>
>> >>> There is no hope of running land-based network backhaul into most of
>> >>> the locations sailors would park in.  A BP-based email network is a
>> >>> likely option for people on the coast living away from land-based
>> >>> infrastructure.
>> >>>
>> >>> --lyndon
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> dtn-interest mailing list
>> >> [email-masked]
>> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >>
>> >
>> > _______________________________________________
>> > dtn-interest mailing list
>> > [email-masked]
>> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 01 Mar 2010 09:02:54 -0500
> From: Greg Troxel <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:
>
>> I can't see how a realtime application like jabber would be something
>> DTN would address; surely disconnected jabber is email, no?
>
> Disconnection can happen on many time scales.  If it's a few minutes,
> it's still different than email, and you can still have presence
> indications.
>
> Still, my real point is that until there's freely available code to plug
> in alternate transports for things like pidgin, and enough dbone
> infrastructure that people can actually use this, it's really hard to
> know under what circumstances DTN will be really useful compared to what
> we have now.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 194 bytes
> Desc: not available
> Url : http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Mon, 01 Mar 2010 10:08:10 -0500
> From: Daniel Ellard <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Brenton Walker <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Brenton Walker wrote:
>> Hi Rajesh,
>>       Why is it always some other poor fellow who is going to use BP?
>
> We might *all* be that poor fellow at some point:
>
> http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007
>
> -Dan
>
> --
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 01 Mar 2010 10:12:07 -0500
> From: Daniel Ellard <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Brenton Walker <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Brenton Walker wrote:
>> Hi Rajesh,
>>       Why is it always some other poor fellow who is going to use BP?  I
>> think we should be trying to think of ways to use it ourselves in our
>> daily lives.  I feel like there are a lot of possibilities.  Even though
>> access to expensive (3G, wimax) infrastructure is increasing, access to
>> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
>> of communication I do is pretty local, and BP (and associated
>> technologies) is a very robust tool for that sort of thing.
>
> There's a group inside BBN who have been getting email and
> web access (and maybe some other IP services) exclusively
> via BP for a few months.  So far, so good.
>
>>       One thing people at our lab have been talking about is trying to
>> organize some sort of BP-based activity at the IETF.  Not a
>> disconnectathon that focuses specifically on technical interoperability,
>> but something that gives people a motivation to bring a handset or
>> laptop with a BPA on it and play with it during those boring sessions
>> they don't really care about.
>>
>> Some ideas we have had:
>> - bundle scavenger hunt.  There are bundles that can be found with
>> varying degrees of difficulty.  You get points for receiving them.
>> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
>> send responses to some EID.
>> - bundle mad libs.  I don't quite understand this one, but people were
>> excited about it.
>> - bundle capture the flag.  OK, I'll stop.
>
> It sounds like fun.  Lots of work to set up, but fun, if you
> can find volunteers.
>
> And you need to find someone very honest to be in charge of
> disrupting the network in a completely fair manner...  :-)
>
> -Dan
>
>
> --
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
>
>
> ------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> End of dtn-interest Digest, Vol 30, Issue 1
> *******************************************
>

Date: Mon, 1 Mar 2010 10:56:00 -0500
From: Rajesh Krishnan <[email-masked]>
To: "Chaudhari, Rohit K." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Rohit,

This could be a useful service, but if all we did was extend 3G (or
other Internet) coverage into the stations, will we get similar
results?
Is a multi-hop DTN necessary for this application? Endpoints can queue
up messages till the next station where they connect to
infrastructure.

-Rajesh

On Mon, Mar 1, 2010 at 10:40 AM, Chaudhari, Rohit K.
<[email-masked]> wrote:
> Hi all,
>
> My name is Rohit as well and I recently joined the DTN-interest mailing list this morning.  As the other Rohit suggested, I too have recently read about NYC subways.  Over 6 million people use the subway in NYC everyday and to think that cell phone communications within them is pretty much non-existent is pretty deplorable.  I know that at one point NYC wanted to redo the cell infrastructure in the subways which would cost them tens of millions of dollars, but they did also bring up the topic of DTN and using it commercially.  This is definitely something that could be explored in the future if a commercial angle seems appropriate.  Hope everyone is enjoying their day so far. Let me know what you guys think.
>
> Thanks,
>
> Rohit
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, March 01, 2010 10:12 AM
> To: [email-masked]
> Subject: dtn-interest Digest, Vol 30, Issue 1
>
> Send dtn-interest mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dtn-interest digest..."
>
>
> Today's Topics:
>
>   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
>   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
>   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
>   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Feb 2010 17:27:29 -0500
> From: Rajesh Krishnan <[email-masked]>
> Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
> To: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I started implementing RFC5050 in Haskell, with a goal of fitting it
> in less than 500 lines of code (which was roughly the size of the
> Xmonad tiling window manager in 2007).
> Clearly I had underestimated the challenge and did not get very far.
> I figured I might as well set this free and move on.
>
> http://www.rajesh-krishnan.com/repos
>
> -Rajesh
>
> P.S.:  SDNV is a good exercise for a first course in functional
> programming.   One that may cause CS students to pay attention to
> DTN/BP as a side benefit.  :)
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 1 Mar 2010 00:10:33 -0500
> From: Phani Rohit <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Rajesh Krishnan <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi All,
>
> I am posting for the first time in this research group. Please excuse me if
> my idea does not make sense. I have an idea for using DTN's in day to day
> life. I don't know its commercial value.
>
> Recently I visited New York City, one of the busiest and happening place.
> The moment you get in to sub way station the communication with the world is
> lost. so  why can't any body have a simple DTN deployment like bunch of
> broker nodes sitting at the opening of each station and route the bundles
> via moving trains and deliver it to outer world. A simple app in this
> scenario would be SMS application running on DTN or chat client.
>
> Please let me know if this make sense  or if you need any further
> explanation.
>
> Thanks,
> Rohit
>
>
> On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan <[email-masked]>wrote:
>
>> Hi Brenton,
>>
>> Interesting game ideas.
>>
>> >From time to time, as my professional life has demanded, I have tried
>> to use or work with BP.   I will happily be the fellow who is going to
>> use BP, but the fact of the matter is I have not created or found a
>> deployment/application that I can use in my daily life.
>>
>> There are several possible vectors that can achieve critical mass for
>> DTN/BP:
>>    - seeding into future-oriented systems (which some Government
>> agencies have done), hoping it will grow big in a few decades
>>    - a new application or a content overlay  that is generally
>> useful, that happens to use BP, and grows popular rapidly  [ our
>> current discussion ]
>>    - through regulation or acquisition policy (may be as successful
>> as GOSIP and Ada :)
>>    - through education
>>
>> One idea was to see if it makes sense to explore BP in place of
>> packetbb as a mechanism to gateway between diverse MANETs (require
>> this as acquisition policy); one problem there is MANETs are still
>> looking for their killer commercial application too.   As 3G/4G
>> coverage increases, the need for multi-hop DTN routing will be
>> increasingly pushed to challenging regimes of space, underground,
>> underwater, etc.   There will be niche terrestrial opportunities
>> (reindeer nets) and opportunities in virtual overlays (for distributed
>> algorithm purists).
>>
>> Regardless of whether BP achieves population inversion or not (either
>> over application overlay protocols or  Layer 2/3 encapsulations),
>> important lessons can be learned from achieving critical mass around
>> the BP.   Without critical mass, many of the ideas generated for ATM
>> research would not have been; some of those ideas (or the competition
>> they created) transformed IP networks.
>>
>> During one of my earlier briefings to the NSF FIND folks to explore
>> synergies, I found they (i) wanted freedom from any constraints, BP or
>>  otherwise, OR (ii) wanted critical mass such as that provided by
>> TCP/IP and 802.11 in order to justify living with the constraints.
>> There was some concern expressed around the ramp up time and perceived
>> complexity of the BP.  In any case, I had failed to convince them of
>> the enormous opportunity that was available in the middle ground --
>> between clean slate and retrofit -- for novel routing and naming
>> research.   BP offers a near clean slate, the benefits of an existing
>> research community that provides the nucleus, and a good metadata
>> extension block, especially for routing, naming, content-networking,
>> and context/location-aware computing.  I have not given up hope;  BP
>> on NSF GENI would be a good way to keep DTN/BP more relevant to the
>> mainstream networking community.
>>
>> On the other hand, when I spoke to folks who do commercialization,
>> their question to me was what is one thing you can do with the BP
>> today  that they cannot hire programmers to do over other popular
>> Internet-based technologies.  They can do meter reading, elevator net,
>> email or content delivery to remote facilities using custom
>> applications that are disruption-tolerant, and without buying into the
>> full DTN/BP program.    Clearly they do not care about technical
>> features, elegance, or potential for transformation provided by the
>> DTN architecture.   Disruptive uses of the BP in settings would be
>> interesting in order to exercise non-traditional routing and rich
>> naming;  otherwise, the question of why not do it with SOAP (or
>> alternative for which I can hire low-cost programmers) will persist?
>> There need to see value additions that can be monetized in the short
>> term.
>>
>> While all of the applications you mention will exercise the BP, all of
>> them can be expeditiously done on an iPhone/Droid and can take
>> advantage of remote servers.
>> Regardless, the playing you suggest is better than the theorizing I
>> provide above.
>>
>> Best Regards,
>> Rajesh
>>
>> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <[email-masked]>
>> wrote:
>> > Hi Rajesh,
>> >        Why is it always some other poor fellow who is going to use BP?  I
>> > think we should be trying to think of ways to use it ourselves in our
>> > daily lives.  I feel like there are a lot of possibilities.  Even though
>> > access to expensive (3G, wimax) infrastructure is increasing, access to
>> > cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
>> > of communication I do is pretty local, and BP (and associated
>> > technologies) is a very robust tool for that sort of thing.
>> >
>> >        One thing people at our lab have been talking about is trying to
>> > organize some sort of BP-based activity at the IETF.  Not a
>> > disconnectathon that focuses specifically on technical interoperability,
>> > but something that gives people a motivation to bring a handset or
>> > laptop with a BPA on it and play with it during those boring sessions
>> > they don't really care about.
>> >
>> > Some ideas we have had:
>> > - bundle scavenger hunt.  There are bundles that can be found with
>> > varying degrees of difficulty.  You get points for receiving them.
>> > - bundle trivia.  Like the bundle scavenger hunt, but you would have to
>> > send responses to some EID.
>> > - bundle mad libs.  I don't quite understand this one, but people were
>> > excited about it.
>> > - bundle capture the flag.  OK, I'll stop.
>> >
>> > Stupid idea?
>> > Already been done?
>> >
>> > Thanks,
>> > Brenton
>> >
>> >
>> >
>> > Rajesh Krishnan wrote:
>> >> In think in Parikh et al.'s application, DTN was useful to let chat
>> >> participants catch up on the conversation they missed while they were
>> >> temporarily disconnected; these are environments where end-to-end
>> >> access to one server cannot be assured.
>> >>
>> >> The sailboat-based email delivery is definitely interesting.
>> >>
>> >> Best Regards,
>> >> Rajesh
>> >>
>> >>
>> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
>> >> <[email-masked]> wrote:
>> >>>> What I find strange is that the DTN community isn't trying to run
>> email
>> >>>> and chat over BP.  Those are natural applications for DTN, but yet
>> >>>> there's not (to my knowledge) a release of an MTA, jabber client,
>> jabber
>> >>>> server, etc., that uses BP, and I don't hear anyone talking about
>> having
>> >>>> problems running those programs on the global dbone.
>> >>>>
>> >>>> Is anyone trying to use BP to do anything other than tests?
>> >>> I can't see how a realtime application like jabber would be something
>> >>> DTN would address; surely disconnected jabber is email, no?
>> >>>
>> >>> One natural application for DTN is providing email service to
>> >>> sailboats on the gulf coast of British Columbia.
>> >>>
>> >>> The stretch of water up the Strait from Vancouver to the north end of
>> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes of
>> >>> cellular connectivity.  In almost every marina, email access is found
>> >>> by subscription only to services such as BBX.  There is no access
>> >>> outside of the pay-per-mail marina wifi access points.
>> >>>
>> >>> There is no hope of running land-based network backhaul into most of
>> >>> the locations sailors would park in.  A BP-based email network is a
>> >>> likely option for people on the coast living away from land-based
>> >>> infrastructure.
>> >>>
>> >>> --lyndon
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> dtn-interest mailing list
>> >> [email-masked]
>> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >>
>> >
>> > _______________________________________________
>> > dtn-interest mailing list
>> > [email-masked]
>> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>> >
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 01 Mar 2010 09:02:54 -0500
> From: Greg Troxel <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
>
> "Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:
>
>> I can't see how a realtime application like jabber would be something
>> DTN would address; surely disconnected jabber is email, no?
>
> Disconnection can happen on many time scales.  If it's a few minutes,
> it's still different than email, and you can still have presence
> indications.
>
> Still, my real point is that until there's freely available code to plug
> in alternate transports for things like pidgin, and enough dbone
> infrastructure that people can actually use this, it's really hard to
> know under what circumstances DTN will be really useful compared to what
> we have now.
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 194 bytes
> Desc: not available
> Url : http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin
>
> ------------------------------
>
> Message: 4
> Date: Mon, 01 Mar 2010 10:08:10 -0500
> From: Daniel Ellard <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Brenton Walker <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Brenton Walker wrote:
>> Hi Rajesh,
>>       Why is it always some other poor fellow who is going to use BP?
>
> We might *all* be that poor fellow at some point:
>
> http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007
>
> -Dan
>
> --
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 01 Mar 2010 10:12:07 -0500
> From: Daniel Ellard <[email-masked]>
> Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
>        discourse
> To: Brenton Walker <[email-masked]>
> Cc: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Brenton Walker wrote:
>> Hi Rajesh,
>>       Why is it always some other poor fellow who is going to use BP?  I
>> think we should be trying to think of ways to use it ourselves in our
>> daily lives.  I feel like there are a lot of possibilities.  Even though
>> access to expensive (3G, wimax) infrastructure is increasing, access to
>> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
>> of communication I do is pretty local, and BP (and associated
>> technologies) is a very robust tool for that sort of thing.
>
> There's a group inside BBN who have been getting email and
> web access (and maybe some other IP services) exclusively
> via BP for a few months.  So far, so good.
>
>>       One thing people at our lab have been talking about is trying to
>> organize some sort of BP-based activity at the IETF.  Not a
>> disconnectathon that focuses specifically on technical interoperability,
>> but something that gives people a motivation to bring a handset or
>> laptop with a BPA on it and play with it during those boring sessions
>> they don't really care about.
>>
>> Some ideas we have had:
>> - bundle scavenger hunt.  There are bundles that can be found with
>> varying degrees of difficulty.  You get points for receiving them.
>> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
>> send responses to some EID.
>> - bundle mad libs.  I don't quite understand this one, but people were
>> excited about it.
>> - bundle capture the flag.  OK, I'll stop.
>
> It sounds like fun.  Lots of work to set up, but fun, if you
> can find volunteers.
>
> And you need to find someone very honest to be in charge of
> disrupting the network in a completely fair manner...  :-)
>
> -Dan
>
>
> --
> Daniel Ellard, Ph.D.
> Senior Scientist, Network Research
> BBN Technologies
> 10 Moulton Street
> Cambridge, MA 02138
> [email-masked]
>
>
> ------------------------------
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
>
> End of dtn-interest Digest, Vol 30, Issue 1
> *******************************************
>

From: "Chaudhari, Rohit K." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 1 Mar 2010 10:40:07 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Hi all,

My name is Rohit as well and I recently joined the DTN-interest mailing list this morning.  As the other Rohit suggested, I too have recently read about NYC subways.  Over 6 million people use the subway in NYC everyday and to think that cell phone communications within them is pretty much non-existent is pretty deplorable.  I know that at one point NYC wanted to redo the cell infrastructure in the subways which would cost them tens of millions of dollars, but they did also bring up the topic of DTN and using it commercially.  This is definitely something that could be explored in the future if a commercial angle seems appropriate.  Hope everyone is enjoying their day so far. Let me know what you guys think.

Thanks,

Rohit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 01, 2010 10:12 AM
To: [email-masked]
Subject: dtn-interest Digest, Vol 30, Issue 1

Send dtn-interest mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        http://maillists.intel-research.net/mailman/listinfo/dtn-interest
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dtn-interest digest..."

Today's Topics:

   1. sketch of RFC5050 portions in Haskell (Rajesh Krishnan)
   2. Re: DTNRG: let's elevate the level of discourse (Phani Rohit)
   3. Re: DTNRG: let's elevate the level of discourse (Greg Troxel)
   4. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)
   5. Re: DTNRG: let's elevate the level of discourse (Daniel Ellard)

----------------------------------------------------------------------

Message: 1
Date: Sun, 28 Feb 2010 17:27:29 -0500
From: Rajesh Krishnan <[email-masked]>
Subject: [dtn-interest] sketch of RFC5050 portions in Haskell
To: [email-masked]
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

I started implementing RFC5050 in Haskell, with a goal of fitting it
in less than 500 lines of code (which was roughly the size of the
Xmonad tiling window manager in 2007).
Clearly I had underestimated the challenge and did not get very far.
I figured I might as well set this free and move on.

http://www.rajesh-krishnan.com/repos

-Rajesh

P.S.:  SDNV is a good exercise for a first course in functional
programming.   One that may cause CS students to pay attention to
DTN/BP as a side benefit.  :)

------------------------------

Message: 2
Date: Mon, 1 Mar 2010 00:10:33 -0500
From: Phani Rohit <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
        discourse
To: Rajesh Krishnan <[email-masked]>
Cc: [email-masked]
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi All,

I am posting for the first time in this research group. Please excuse me if
my idea does not make sense. I have an idea for using DTN's in day to day
life. I don't know its commercial value.

Recently I visited New York City, one of the busiest and happening place.
The moment you get in to sub way station the communication with the world is
lost. so  why can't any body have a simple DTN deployment like bunch of
broker nodes sitting at the opening of each station and route the bundles
via moving trains and deliver it to outer world. A simple app in this
scenario would be SMS application running on DTN or chat client.

Please let me know if this make sense  or if you need any further
explanation.

Thanks,
Rohit

On Sun, Feb 28, 2010 at 1:36 PM, Rajesh Krishnan <[email-masked]>wrote:

> Hi Brenton,
>
> Interesting game ideas.
>
> >From time to time, as my professional life has demanded, I have tried
> to use or work with BP.   I will happily be the fellow who is going to
> use BP, but the fact of the matter is I have not created or found a
> deployment/application that I can use in my daily life.
>
> There are several possible vectors that can achieve critical mass for
> DTN/BP:
>    - seeding into future-oriented systems (which some Government
> agencies have done), hoping it will grow big in a few decades
>    - a new application or a content overlay  that is generally
> useful, that happens to use BP, and grows popular rapidly  [ our
> current discussion ]
>    - through regulation or acquisition policy (may be as successful
> as GOSIP and Ada :)
>    - through education
>
> One idea was to see if it makes sense to explore BP in place of
> packetbb as a mechanism to gateway between diverse MANETs (require
> this as acquisition policy); one problem there is MANETs are still
> looking for their killer commercial application too.   As 3G/4G
> coverage increases, the need for multi-hop DTN routing will be
> increasingly pushed to challenging regimes of space, underground,
> underwater, etc.   There will be niche terrestrial opportunities
> (reindeer nets) and opportunities in virtual overlays (for distributed
> algorithm purists).
>
> Regardless of whether BP achieves population inversion or not (either
> over application overlay protocols or  Layer 2/3 encapsulations),
> important lessons can be learned from achieving critical mass around
> the BP.   Without critical mass, many of the ideas generated for ATM
> research would not have been; some of those ideas (or the competition
> they created) transformed IP networks.
>
> During one of my earlier briefings to the NSF FIND folks to explore
> synergies, I found they (i) wanted freedom from any constraints, BP or
>  otherwise, OR (ii) wanted critical mass such as that provided by
> TCP/IP and 802.11 in order to justify living with the constraints.
> There was some concern expressed around the ramp up time and perceived
> complexity of the BP.  In any case, I had failed to convince them of
> the enormous opportunity that was available in the middle ground --
> between clean slate and retrofit -- for novel routing and naming
> research.   BP offers a near clean slate, the benefits of an existing
> research community that provides the nucleus, and a good metadata
> extension block, especially for routing, naming, content-networking,
> and context/location-aware computing.  I have not given up hope;  BP
> on NSF GENI would be a good way to keep DTN/BP more relevant to the
> mainstream networking community.
>
> On the other hand, when I spoke to folks who do commercialization,
> their question to me was what is one thing you can do with the BP
> today  that they cannot hire programmers to do over other popular
> Internet-based technologies.  They can do meter reading, elevator net,
> email or content delivery to remote facilities using custom
> applications that are disruption-tolerant, and without buying into the
> full DTN/BP program.    Clearly they do not care about technical
> features, elegance, or potential for transformation provided by the
> DTN architecture.   Disruptive uses of the BP in settings would be
> interesting in order to exercise non-traditional routing and rich
> naming;  otherwise, the question of why not do it with SOAP (or
> alternative for which I can hire low-cost programmers) will persist?
> There need to see value additions that can be monetized in the short
> term.
>
> While all of the applications you mention will exercise the BP, all of
> them can be expeditiously done on an iPhone/Droid and can take
> advantage of remote servers.
> Regardless, the playing you suggest is better than the theorizing I
> provide above.
>
> Best Regards,
> Rajesh
>
> On Sun, Feb 28, 2010 at 11:51 AM, Brenton Walker <[email-masked]>
> wrote:
> > Hi Rajesh,
> >        Why is it always some other poor fellow who is going to use BP?  I
> > think we should be trying to think of ways to use it ourselves in our
> > daily lives.  I feel like there are a lot of possibilities.  Even though
> > access to expensive (3G, wimax) infrastructure is increasing, access to
> > cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
> > of communication I do is pretty local, and BP (and associated
> > technologies) is a very robust tool for that sort of thing.
> >
> >        One thing people at our lab have been talking about is trying to
> > organize some sort of BP-based activity at the IETF.  Not a
> > disconnectathon that focuses specifically on technical interoperability,
> > but something that gives people a motivation to bring a handset or
> > laptop with a BPA on it and play with it during those boring sessions
> > they don't really care about.
> >
> > Some ideas we have had:
> > - bundle scavenger hunt.  There are bundles that can be found with
> > varying degrees of difficulty.  You get points for receiving them.
> > - bundle trivia.  Like the bundle scavenger hunt, but you would have to
> > send responses to some EID.
> > - bundle mad libs.  I don't quite understand this one, but people were
> > excited about it.
> > - bundle capture the flag.  OK, I'll stop.
> >
> > Stupid idea?
> > Already been done?
> >
> > Thanks,
> > Brenton
> >
> >
> >
> > Rajesh Krishnan wrote:
> >> In think in Parikh et al.'s application, DTN was useful to let chat
> >> participants catch up on the conversation they missed while they were
> >> temporarily disconnected; these are environments where end-to-end
> >> access to one server cannot be assured.
> >>
> >> The sailboat-based email delivery is definitely interesting.
> >>
> >> Best Regards,
> >> Rajesh
> >>
> >>
> >> On Sun, Feb 28, 2010 at 4:10 AM, Lyndon Nerenberg (VE6BBM/VE7TFX)
> >> <[email-masked]> wrote:
> >>>> What I find strange is that the DTN community isn't trying to run
> email
> >>>> and chat over BP.  Those are natural applications for DTN, but yet
> >>>> there's not (to my knowledge) a release of an MTA, jabber client,
> jabber
> >>>> server, etc., that uses BP, and I don't hear anyone talking about
> having
> >>>> problems running those programs on the global dbone.
> >>>>
> >>>> Is anyone trying to use BP to do anything other than tests?
> >>> I can't see how a realtime application like jabber would be something
> >>> DTN would address; surely disconnected jabber is email, no?
> >>>
> >>> One natural application for DTN is providing email service to
> >>> sailboats on the gulf coast of British Columbia.
> >>>
> >>> The stretch of water up the Strait from Vancouver to the north end of
> >>> Vancouver Is. is a patchwork of fjords, islets, and black holes of
> >>> cellular connectivity.  In almost every marina, email access is found
> >>> by subscription only to services such as BBX.  There is no access
> >>> outside of the pay-per-mail marina wifi access points.
> >>>
> >>> There is no hope of running land-based network backhaul into most of
> >>> the locations sailors would park in.  A BP-based email network is a
> >>> likely option for people on the coast living away from land-based
> >>> infrastructure.
> >>>
> >>> --lyndon
> >>>
> >>>
> >>
> >> _______________________________________________
> >> dtn-interest mailing list
> >> [email-masked]
> >> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >>
> >
> > _______________________________________________
> > dtn-interest mailing list
> > [email-masked]
> > http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> >
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/5528783a/attachment-0001.html

------------------------------

Message: 3
Date: Mon, 01 Mar 2010 09:02:54 -0500
From: Greg Troxel <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
        discourse
To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

"Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:

> I can't see how a realtime application like jabber would be something
> DTN would address; surely disconnected jabber is email, no?

Disconnection can happen on many time scales.  If it's a few minutes,
it's still different than email, and you can still have presence
indications.

Still, my real point is that until there's freely available code to plug
in alternate transports for things like pidgin, and enough dbone
infrastructure that people can actually use this, it's really hard to
know under what circumstances DTN will be really useful compared to what
we have now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://maillists.intel-research.net/pipermail/dtn-interest/attachments/20100301/2b1662d0/attachment-0001.bin

------------------------------

Message: 4
Date: Mon, 01 Mar 2010 10:08:10 -0500
From: Daniel Ellard <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
        discourse
To: Brenton Walker <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Brenton Walker wrote:
> Hi Rajesh,
>       Why is it always some other poor fellow who is going to use BP?

We might *all* be that poor fellow at some point:

http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007

-Dan

--
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

------------------------------

Message: 5
Date: Mon, 01 Mar 2010 10:12:07 -0500
From: Daniel Ellard <[email-masked]>
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of
        discourse
To: Brenton Walker <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Brenton Walker wrote:
> Hi Rajesh,
>       Why is it always some other poor fellow who is going to use BP?  I
> think we should be trying to think of ways to use it ourselves in our
> daily lives.  I feel like there are a lot of possibilities.  Even though
> access to expensive (3G, wimax) infrastructure is increasing, access to
> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
> of communication I do is pretty local, and BP (and associated
> technologies) is a very robust tool for that sort of thing.

There's a group inside BBN who have been getting email and
web access (and maybe some other IP services) exclusively
via BP for a few months.  So far, so good.

>       One thing people at our lab have been talking about is trying to
> organize some sort of BP-based activity at the IETF.  Not a
> disconnectathon that focuses specifically on technical interoperability,
> but something that gives people a motivation to bring a handset or
> laptop with a BPA on it and play with it during those boring sessions
> they don't really care about.
>
> Some ideas we have had:
> - bundle scavenger hunt.  There are bundles that can be found with
> varying degrees of difficulty.  You get points for receiving them.
> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
> send responses to some EID.
> - bundle mad libs.  I don't quite understand this one, but people were
> excited about it.
> - bundle capture the flag.  OK, I'll stop.

It sounds like fun.  Lots of work to set up, but fun, if you
can find volunteers.

And you need to find someone very honest to be in charge of
disrupting the network in a completely fair manner...  :-)

-Dan

--
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

------------------------------

_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

End of dtn-interest Digest, Vol 30, Issue 1
*******************************************

From: "Birrane, Edward J." <[email-masked]>
To: Daniel Ellard <[email-masked]>
Date: Mon, 1 Mar 2010 10:23:42 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Propagation Delays

> (do I need to add a smiley here for the humor-impaired?)

Sorry for the response delay. On the bright side, I just started my outlook program for the week, so your e-mail is only 10 minutes old.  8)

I agree with Scott. If neither AT or RT is needed across the board, why don't we push them into extension blocks? 

My point is that for those who consider propagation delays, RT puts some really difficult requirements on the CLs. All CLs. It is at least as burdensome (IMO) as requiring some level of clock synchronization. If the only way to tackle this hard problem is exploiting knowledge of a particular network then I would push for this to be an extension block that is required in some domains and not in others. 

> Why should the receiver believe that the sender has a better
> clock than it does?  What should the receiver do when it
> receives messages from different senders with different
> effective ATs?

My apologies. I meant to write reference broadcast synchronization (RBS).  I didn't mean to imply something like NTP.  In RBS the clocks all exchange information and try to find a common ground. Extended to DTNs, the nodes that communicate the most would be the most in sync. 

Take a gander at:

Elson, J., Girod, L., and Estrin, D. 2002. Fine-grained network time synchronization using reference broadcasts. SIGOPS Oper. Syst. Rev. 36, SI (Dec. 2002), 147-163. DOI= http://doi.acm.org/10.1145/844128.844143

Frankly, the clock part isn't what makes this infeasible. Having the CLs model all of the propagation delays makes this difficult for general applicability.

> In the long run, skew diverges without bound.  You probably
> don't want to just keep adding more and more salt, or else
> the concept of bounding the lifetime at all becomes
> questionable.  Perhaps even optional...  So maybe this
> should go in an extension block also?

Agreed. Again, I was assuming some clock synchronization mechanism in the network that would bound things. There is a difference between maintaining perfect synchronization and maintaining reasonably bounded synchronization. 

A combination of RBS and error margins on the BPA clock might work well in some applications. It is at least worth some thought... If anyone wants to collaborate, please shoot me an e-mail.

-Ed

Date: Mon, 01 Mar 2010 10:12:07 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Brenton Walker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Brenton Walker wrote:
> Hi Rajesh,
> 	Why is it always some other poor fellow who is going to use BP?  I
> think we should be trying to think of ways to use it ourselves in our
> daily lives.  I feel like there are a lot of possibilities.  Even though
> access to expensive (3G, wimax) infrastructure is increasing, access to
> cheap infrastructure (open wifi APs) is getting more restrictive.  Lots
> of communication I do is pretty local, and BP (and associated
> technologies) is a very robust tool for that sort of thing.

There's a group inside BBN who have been getting email and
web access (and maybe some other IP services) exclusively
via BP for a few months.  So far, so good.

> 	One thing people at our lab have been talking about is trying to
> organize some sort of BP-based activity at the IETF.  Not a
> disconnectathon that focuses specifically on technical interoperability,
> but something that gives people a motivation to bring a handset or
> laptop with a BPA on it and play with it during those boring sessions
> they don't really care about.
> 
> Some ideas we have had:
> - bundle scavenger hunt.  There are bundles that can be found with
> varying degrees of difficulty.  You get points for receiving them.
> - bundle trivia.  Like the bundle scavenger hunt, but you would have to
> send responses to some EID.
> - bundle mad libs.  I don't quite understand this one, but people were
> excited about it.
> - bundle capture the flag.  OK, I'll stop.

It sounds like fun.  Lots of work to set up, but fun, if you
can find volunteers.

And you need to find someone very honest to be in charge of
disrupting the network in a completely fair manner...  :-)

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

Date: Mon, 01 Mar 2010 10:08:10 -0500
From: Daniel Ellard <[email-masked]>
Organization: BBN Technologies
To: Brenton Walker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

Brenton Walker wrote:
> Hi Rajesh,
> 	Why is it always some other poor fellow who is going to use BP?

We might *all* be that poor fellow at some point:

http://www.npr.org/templates/story/story.php?storyId=124125001&ft=1&f=1007

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
[email-masked]

From: Greg Troxel <[email-masked]>
To: "Lyndon Nerenberg \(VE6BBM\/VE7TFX\)" <[email-masked]>
Date: Mon, 01 Mar 2010 09:02:54 -0500
Cc: [email-masked]
Subject: Re: [dtn-interest] DTNRG: let's elevate the level of discourse

--=-=-=
Content-Transfer-Encoding: quoted-printable

"Lyndon Nerenberg (VE6BBM/VE7TFX)"  <[email-masked]> writes:

> I can't see how a realtime application like jabber would be something
> DTN would address; surely disconnected jabber is email, no?

Disconnection can happen on many time scales.  If it's a few minutes,
it's still different than email, and you can still have presence
indications.=20=20

Still, my real point is that until there's freely available code to plug
in alternate transports for things like pidgin, and enough dbone
infrastructure that people can actually use this, it's really hard to
know under what circumstances DTN will be really useful compared to what
we have now.

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--