Subject: [dtn-interest] [ACM/SIGMOBILE MobiOpp 2010]: Announcement and Call for Papers
From: Emilio Ancillotti <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sun, 30 Aug 2009 09:50:00 +0200
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

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

                      ANNOUNCEMENT and CALL FOR PAPERS

                  The Second ACM International Workshop on
                       Mobile Opportunistic Networking
                               MobiOpp  2010

                     February  22-23, 2010,  Pisa, Italy

                      http://cnd.iit.cnr.it/mobiopp2010

                         sponsored by ACM/SIGMOBILE

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

Opportunistic Networking is one of the emerging communication paradigms in
wireless mobile communications. Opportunistic networks are commonly 
defined as
a type of challenged networks where communication opportunities are based on
sporadic and intermittent contacts, disconnections and re-connections may
frequently occur, and the assumption on the existence of an end-to-end path
between the source and the destination is released. As compared to the 
legacy
MANETs, where an always-connected infrastructure-less network is assumed,
opportunistic networks are much closer to real pervasive networking 
scenarios,
where devices (with sensing capabilities) are carried while users move, 
and can
connect and disconnect continuously relying their communication chances on a
store-carry-and-forward approach. The aim of MobiOpp 2010 is to bring 
together
researchers working in this emerging area, thus also providing a 
reference event
for those working on self-organizing wireless mobile networks which usually
exploit the opportunistic communication paradigm. In this workshop we aim to
explore novel research issues related to all aspects of opportunistic 
networks.

Original contributions are solicited, being related to systems and protocols
design, development and analysis, in all areas of Opportunistic Networking.
Topics of interest include, but are not limited to:

  * Novel architectures
  * Routing protocols
  * Transport and reliability issues in opportunistic networks
  * Resource management techniques
  * Dissemination and replication techniques
  * Opportunistic networking in P2P systems
  * Social-aware opportunisitc networking
  * Middleware services in opportunistic networks
  * Opportunistic networking applications
  * Opportunistic networking in wireless sensor networks
  * Multimodal urban sensing
  * Security issues in opportunistic networks
  * Trust and cooperation in opportunistic networks
  * Mobility models for opportunistic networks
  * Tools and techniques for designing, analyzing and building 
opportunistic networks
  * Opportunistic networks testbeds and measurements
  * Opportunistic networks performance modeling

The workshop proceedings will be published by ACM. Extended versions of 
workshop
selected papers will be considered for possible fast track publication 
in the
Computer Communications Journal (Elsevier)

Important dates
--------------------

  Papers submission deadline:  November 1, 2009
  Acceptance Notification: December 22, 2009

  Camera Ready deadline: January 22, 2010

  Workshop dates: February 22-23, 2010

ORGANIZING COMMITTEE

General Chair

  Sergio Palazzo, University of Catania, Italy

Program Co-Chairs

  Tracy Camp, Colorado School of Mines, USA

  Marco Conti, IIT-CNR, Italy

Steering Committee

  Marco Conti, IIT-CNR, Italy

  Jon Crowcroft, University of Cambridge, UK

  Serge Fdida, Univ. Pierre et Marie Curie, France

  Mario Gerla, UCLA, USA

  Sergio Palazzo, University of Catania, Italy

  Mani Srivastava, UCLA, USA

-- 
============================================================
Ing. Emilio Ancillotti, PhD
   Pervasive Computing & Networking Lab. (PerLab)
   Institute for Informatics and Telematics (IIT)
   National Research Council (CNR)
      Via G. Moruzzi, 1    ||    voice:    +39 050 315 2437
      56124 Pisa, Italy    ||    fax:    +39 050 315 2113
                           ||    mobile:    +39 328 2963760
============================================================

From: Lloyd Wood <[email-masked]>
To: DTN interest <[email-masked]>
Date: Sat, 29 Aug 2009 22:10:32 +0100
Cc: Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Pigeon Post transfers files on USB

http://entertainment.slashdot.org/story/09/08/29/1934251/Pigeon-Protocol-Finds-a-Practical-Purpose?art_pos=3

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

From: "Fall, Kevin" <[email-masked]>
To: dtn interest <[email-masked]>
Date: Fri, 28 Aug 2009 10:43:16 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [dtn-interest] FW: NSF -- Open Call for Participation in Future Internet Architectures Summit

--_004_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_
Content-Type: multipart/alternative;
	boundary="_000_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_"

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

This may well be of interest to this group...

-          Kevin

From: Znati, Taieb B. [mailto:[email-masked]]
Sent: Friday, August 28, 2009 10:27 AM
To: Fall, Kevin
Subject: NSF -- Open Call for Participation in Future Internet Architecture=
s Summit

Call for Participants

Future Internet Architectures

Summit

October 12-15, 2009

Waterview Conference Center
Arlington, VA

Closing date for submission of Expressions of Interest (EoI):
 4pm, Submitter's Local Time, September 16, 2009

This is an open call, so please alert and distribute this call to experts w=
ho may be interested in participating in the Summit

The Directorate for Computer and Information Science and Engineering (CISE)=
 has a long-standing commitment to support groundbreaking research in netwo=
rk science and engineering.   CISE is particularly interested in stimulatin=
g the multidisciplinary exploration of Future Internet architectures that a=
re informed not only by technological opportunities and challenges, but als=
o by the legal, ethical and other societal dimensions of their use, conside=
ring factors such as security, privacy, trust, openness, and economic viabi=
lity.

In FY 2010, CISE plans to establish several (2-4) multi-million dollar, mul=
tidisciplinary research projects aimed at the exploration of overarching Fu=
ture Internet architectures, with a specific focus on the coalescence or in=
tegration of promising research outcomes already demonstrated by the resear=
ch community, as well as new concepts and ideas that are only now emerging.=
   To help the community design Future Internet architectures and to guide =
NSF in the development of an associated call for proposals, CISE will host =
a Future Internet Architectures Summit on October 12-15, 2009 in Arlington,=
 VA.  Participation in the Summit will be by invitation only.
The majority of Summit participants will be researchers with scientific exp=
ertise and/or interest in Future Internet architectures, including, but not=
 limited to, those with expertise in the computing domain, including networ=
king and communications, security, and privacy, in the social and economic =
sciences, and in engineering, as well as application developers.  At the Su=
mmit, participants will interact with each other to define compelling Futur=
e Internet architectures whose properties are responsive to societal priori=
ties and needs, and which capitalize on ongoing advances in networking tech=
nologies and systems.  The Summit will also include professional facilitato=
rs and mentors with Internet and other relevant expertise whose roles are t=
o both nurture creative scientific thinking in this highly collaborative en=
vironment and to provide real-time feedback to the Summit participants.  NS=
F and other agency program officials will also attend the event.
If you are a researcher interested in participating in the Summit, you must=
 submit an Expression of Interest.  You will find the submission instructio=
ns and a description of the Summit participant selection process at  http:/=
/www.nsf.gov/cise/news/2009_app_fut_intrnt_summit.cfm. Please note that Exp=
ressions of Interest must be submitted by 4pm submitter's local time on Sep=
tember 16, 2009.

If you are one of the approximately 120 researchers selected to attend, CIS=
E will support permissible costs associated with: travel to the Summit, acc=
ommodations, and Summit meals. However, you will be responsible for meeting=
 the incidental costs you incur while travelling to or participating in the=
 event.
For more information about CISE's interest in Future Internet architectures=
, please see the webcast of the CISE Future Internet Architecture Informati=
on Meeting available at: http://www.visualwebcaster.com/event.asp?id=3D6094=
7.
For more information about current research funded by the CISE Future Inter=
net Design (FIND) effort, visit www.nets-find.net<http://www.nets-find.net/=
>, and for more information about CISE Cross-Cutting Programs, please visit=
 http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=3D13451&org=3DCISE&from=3D=
home.

For further information, advice or queries regarding the format of the Summ=
it or about other Summit operational matters, please contact:
Dr. Darleen Fisher or Dr. Victor Frost
CNS/CISE Room 1175
National Science Foundation
4201 Wilson Boulevard
Arlington
VA 22230
Phone: 703 292 8950
Email: [email-masked]<mailto:[email-masked]> or [email-masked]<mailto:=
[email-masked]>

Sincerely yours,

Taieb Znati, Director
Division of Computer and Network Systems

--_000_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_
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:m=3D"http://schema=
s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html=
40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title> </title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
@font-face
	{font-family:Verdana;
	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:10.0pt;
	font-family:"Verdana","sans-serif";}
h3
	{mso-style-priority:9;
	mso-style-link:"Heading 3 Char";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:0in;
	page-break-after:avoid;
	font-size:10.0pt;
	font-family:"Verdana","sans-serif";}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{mso-style-priority:99;
	mso-style-link:"Footer Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Verdana","sans-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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Verdana","sans-serif";}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 3";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
span.FooterChar
	{mso-style-name:"Footer Char";
	mso-style-priority:99;
	mso-style-link:Footer;
	font-family:"Verdana","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
p.default, li.default, div.default
	{mso-style-name:default;
	margin:0in;
	margin-bottom:.0001pt;
	text-autospace:none;
	font-size:12.0pt;
	font-family:"Arial","sans-serif";
	color:black;}
span.EmailStyle23
	{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:595.3pt 841.9pt;
	margin:.9in .9in .9in .9in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1302689025;
	mso-list-type:hybrid;
	mso-list-template-ids:2046479010 -276398010 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>This may well be of interest to this group&#8230;<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=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D'font-size:11.0pt;font-family:=
"Calibri","sans-serif";
color:#1F497D'>Kevin<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>

<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-family:"Tahoma","sans-serif"'>F=
rom:</span></b><span
style=3D'font-family:"Tahoma","sans-serif"'> Znati, Taieb B.
[mailto:[email-masked]] <br>
<b>Sent:</b> Friday, August 28, 2009 10:27 AM<br>
<b>To:</b> Fall, Kevin<br>
<b>Subject:</b> NSF -- Open Call for Participation in Future Internet
Architectures Summit<o:p></o:p></span></p>

</div>

</div>

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

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-family:"Arial","sans-=
serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lang=
=3DEN-GB
style=3D'font-size:8.5pt;font-family:"Arial","sans-serif"'><img width=3D137
height=3D137 id=3D"_x0000_i1025" src=3D"cid:[email-masked]"
hspace=3D10 vspace=3D10 alt=3D"9KB NSF logo in color, .jpg format"></span><=
span
lang=3DEN-GB style=3D'font-family:"Arial","sans-serif"'><o:p></o:p></span><=
/p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-family:"Arial","sans-=
serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span lang=
=3DEN-GB
style=3D'font-size:14.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:=
p></span></p>

<p class=3Ddefault align=3Dcenter style=3D'text-align:center'><b><span lang=
=3DEN-GB
style=3D'font-size:18.0pt;color:windowtext'><o:p>&nbsp;</o:p></span></b></p=
>

<p class=3Ddefault align=3Dcenter style=3D'text-align:center'><b><span lang=
=3DEN-GB
style=3D'font-size:18.0pt;color:windowtext'>Call for Participants <o:p></o:=
p></span></b></p>

<p class=3Ddefault align=3Dcenter style=3D'text-align:center'><b><span lang=
=3DEN-GB
style=3D'font-size:18.0pt;color:windowtext'>Future Internet Architectures<o=
:p></o:p></span></b></p>

<p class=3Ddefault align=3Dcenter style=3D'text-align:center'><b><span lang=
=3DEN-GB
style=3D'font-size:18.0pt;color:windowtext'>Summit<o:p></o:p></span></b></p=
>

<p class=3Ddefault align=3Dcenter style=3D'text-align:center'><b><span lang=
=3DEN-GB
style=3D'font-size:14.0pt;color:red'>October 12-15, 2009<o:p></o:p></span><=
/b></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-family:"Arial","sans-=
serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'>Waterview
Conference Center<o:p></o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'>Arlington,
VA<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-autospace:none'><spa=
n
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><b><span lang=3DEN-GB style=3D'font-size:11.0pt;font-f=
amily:
"Arial","sans-serif"'>Closing date for submission of Expressions of Interes=
t
(EoI):<o:p></o:p></span></b></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'>&nbsp;<b><span
style=3D'color:red'>4pm, Submitter&#8217;s Local Time</span></b><span style=
=3D'color:
red'>,</span> <b><span style=3D'color:red'>September 16, 2009<o:p></o:p></s=
pan></b></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><b><span lang=3DEN-GB style=3D'font-size:11.0pt;font-f=
amily:
"Arial","sans-serif"'>This is an open call, so please alert and distribute =
this
call to experts who may be interested in participating in the Summit<o:p></=
o:p></span></b></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-bottom:6.0pt;text-align=
:center;
text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'text-align:justify;text-autospace:none'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>Th=
e
Directorate for Computer and Information Science and Engineering (CISE) has=
 a
long-standing commitment to support groundbreaking research in network scie=
nce
and engineering.&nbsp;&nbsp; CISE is particularly interested in stimulating=
 the
multidisciplinary exploration of Future Internet architectures that are
informed not only by technological opportunities and challenges, but also b=
y
the legal, ethical and other societal dimensions of their use,</span><span
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'> considering fa=
ctors
such as security, privacy, trust, openness, and economic viability</span><s=
pan
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>. =
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'text-align:justify;text-autospace:none'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify;text-i=
ndent:
.5in;text-autospace:none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font=
-family:
"Arial","sans-serif"'>In FY 2010, CISE plans to establish several (2-4)
multi-million dollar, multidisciplinary research projects aimed at the
exploration of overarching Future Internet architectures, with a specific f=
ocus
on the coalescence or integration of promising research outcomes already
demonstrated by the research community, as well as new concepts and ideas t=
hat
are only now emerging.&nbsp;&nbsp; To help the community design Future Inte=
rnet
architectures and to guide NSF in the development of an associated call for
proposals, CISE will host a Future Internet Architectures Summit on October
12-15, 2009 in Arlington, VA.&nbsp; Participation in the Summit will be by
invitation only.&nbsp; <span style=3D'color:#231F20'><o:p></o:p></span></sp=
an></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify;text-a=
utospace:
none'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","san=
s-serif"'>The
majority of Summit participants will be researchers with scientific experti=
se and/or
interest in Future Internet architectures, including, but not limited to, t=
hose
with expertise in the computing domain, including networking and
communications, security, and privacy, in the social and economic sciences,=
 and
in engineering, as well as application developers.&nbsp; </span><span
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>At the Summit,
participants will interact with each other to define compelling Future Inte=
rnet
architectures whose properties are responsive to societal priorities and ne=
eds,
and which capitalize on ongoing advances in networking technologies and
systems.&nbsp; </span><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fam=
ily:
"Arial","sans-serif"'>The Summit will also include professional facilitator=
s
and mentors with Internet and other relevant expertise whose roles are to b=
oth
nurture creative scientific thinking in this highly collaborative environme=
nt
and to provide real-time feedback to the Summit participants.&nbsp; NSF and
other agency program officials will also attend the event.&nbsp; <span
style=3D'color:red'>&nbsp;</span><span style=3D'color:#231F20'><o:p></o:p><=
/span></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>If=
 you are
a researcher interested in participating in the Summit, you must submit an
Expression of Interest.&nbsp; You will find the submission instructions and=
 a
description of the Summit participant selection process at &nbsp;</span><sp=
an
lang=3DEN-GB style=3D'color:#1F497D'><a
href=3D"http://www.nsf.gov/cise/news/2009_app_fut_intrnt_summit.cfm"
title=3D"http://www.nsf.gov/cise/news/2009_app_fut_intrnt_summit.cfm">http:=
//www.nsf.gov/cise/news/2009_app_fut_intrnt_summit.cfm</a>.
</span><span lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sa=
ns-serif"'>Please
note that Expressions of Interest must be submitted by <b><span
style=3D'color:red'>4pm submitter&#8217;s local time on September 16, 2009<=
/span>.</b>&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>&n=
bsp;<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify;text-i=
ndent:
.5in'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","san=
s-serif"'>If
you are one of the approximately 120 researchers selected to attend, CISE w=
ill
support permissible costs associated with: travel to the Summit,
accommodations, and Summit meals. However, you will be responsible for meet=
ing
the incidental costs you incur while travelling to or participating in the
event.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-indent:.5in'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>Fo=
r more
information about CISE&#8217;s interest in Future Internet architectures, p=
lease see
the webcast of the CISE Future Internet Architecture Information Meeting
available at: </span><span lang=3DEN-GB style=3D'font-family:"Arial","sans-=
serif";
color:blue'><a href=3D"http://www.visualwebcaster.com/event.asp?id=3D60947"=
>http://www.visualwebcaster.com/event.asp?id=3D60947</a></span><span
lang=3DEN-GB style=3D'font-family:"Arial","sans-serif"'>.</span><span lang=
=3DEN-GB
style=3D'font-size:9.0pt;font-family:"Arial","sans-serif"'> </span><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-indent:.5in'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>Fo=
r more information
about current research funded by the CISE Future Internet Design (FIND) eff=
ort,
visit </span><span lang=3DEN-GB style=3D'font-family:"Arial","sans-serif"'>=
<a
href=3D"http://www.nets-find.net/">www.nets-find.net</a></span><span lang=
=3DEN-GB
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>, and for more
information about CISE Cross-Cutting Programs, please visit </span><span
lang=3DEN-GB style=3D'font-family:"Arial","sans-serif"'><a
href=3D"http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=3D13451&amp;org=3DC=
ISE&amp;from=3Dhome">http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=3D1345=
1&amp;org=3DCISE&amp;from=3Dhome</a>.</span><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt'><span lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:=
p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:6.0pt;text-align:justify;text-i=
ndent:
.5in'><span lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","san=
s-serif"'>For
further information, advice or queries regarding the format of the Summit o=
r
about other Summit operational matters, please contact:<b><u><o:p></o:p></u=
></b></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span lang=3DEN-GB style=
=3D'font-size:
11.0pt;font-family:"Arial","sans-serif"'>Dr. Darleen Fisher or Dr. Victor
Frost&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in;text-align:justify'><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>CN=
S/CISE
Room
1175&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span style=3D'font-size:1=
1.0pt;
font-family:"Arial","sans-serif"'>National Science Foundation</span><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span style=3D'font-size:1=
1.0pt;
font-family:"Arial","sans-serif"'>4201 Wilson Boulevard</span><span lang=3D=
EN-GB
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'><o=
:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span lang=3DFR style=3D'f=
ont-size:
11.0pt;font-family:"Arial","sans-serif"'>Arlington&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><span lang=3DFR style=3D'f=
ont-size:
11.0pt;font-family:"Arial","sans-serif"'>VA
22230&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><b><span lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>Phone: </span><=
/b><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>70=
3 292
8950<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><b><span lang=3DEN-GB
style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'>Email:</span></=
b><span
lang=3DEN-GB style=3D'font-size:11.0pt;font-family:"Arial","sans-serif"'> <=
a
href=3D"mailto:[email-masked]">[email-masked]</a> or <a
href=3D"mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:11.0pt;font-fami=
ly:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'>Sincerely
yours,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'>Taieb
Znati, Director<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-size:11.0pt;font-family:=
"Arial","sans-serif"'>Division
of Computer and Network Systems<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-family:"Arial","sans-=
serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-GB><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

--_000_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_--

--_004_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=4712;
	creation-date="Fri, 28 Aug 2009 10:26:00 GMT";
	modification-date="Fri, 28 Aug 2009 10:26:00 GMT"
Content-ID: <[email-masked]>
Content-Location: image001.jpg
Content-Transfer-Encoding: base64

--_004_02968BB921677D479DAB47F25B73122301540E4B3Aorsmsx504amrc_--

Date: Fri, 28 Aug 2009 17:52:24 +0200
From: Emilio Ancillotti <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: [dtn-interest] [ACM/SIGMOBILE MobiOpp 2010]: Announcement and Call for Papers

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

                      ANNOUNCEMENT and CALL FOR PAPERS

                  The Second ACM International Workshop on
                       Mobile Opportunistic Networking
                               MobiOpp  2010

                     February  22-23, 2010,  Pisa, Italy

                      http://cnd.iit.cnr.it/mobiopp2010

                         sponsored by ACM/SIGMOBILE

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

Opportunistic Networking is one of the emerging communication paradigms in
wireless mobile communications. Opportunistic networks are commonly 
defined as
a type of challenged networks where communication opportunities are based on
sporadic and intermittent contacts, disconnections and re-connections may
frequently occur, and the assumption on the existence of an end-to-end path
between the source and the destination is released. As compared to the 
legacy
MANETs, where an always-connected infrastructure-less network is assumed,
opportunistic networks are much closer to real pervasive networking 
scenarios,
where devices (with sensing capabilities) are carried while users move, 
and can
connect and disconnect continuously relying their communication chances on a
store-carry-and-forward approach. The aim of MobiOpp 2010 is to bring 
together
researchers working in this emerging area, thus also providing a 
reference event
for those working on self-organizing wireless mobile networks which usually
exploit the opportunistic communication paradigm. In this workshop we aim to
explore novel research issues related to all aspects of opportunistic 
networks.

Original contributions are solicited, being related to systems and protocols
design, development and analysis, in all areas of Opportunistic Networking.
Topics of interest include, but are not limited to:

  * Novel architectures
  * Routing protocols
  * Transport and reliability issues in opportunistic networks
  * Resource management techniques
  * Dissemination and replication techniques
  * Opportunistic networking in P2P systems
  * Social-aware opportunisitc networking
  * Middleware services in opportunistic networks
  * Opportunistic networking applications
  * Opportunistic networking in wireless sensor networks
  * Multimodal urban sensing
  * Security issues in opportunistic networks
  * Trust and cooperation in opportunistic networks
  * Mobility models for opportunistic networks
  * Tools and techniques for designing, analyzing and building 
opportunistic networks
  * Opportunistic networks testbeds and measurements
  * Opportunistic networks performance modeling

The workshop proceedings will be published by ACM. Extended versions of 
workshop
selected papers will be considered for possible fast track publication 
in the
Computer Communications Journal (Elsevier)

Important dates
--------------------

  Papers submission deadline:  November 1, 2009
  Acceptance Notification: December 22, 2009

  Camera Ready deadline: January 22, 2010

  Workshop dates: February 22-23, 2010

ORGANIZING COMMITTEE

General Chair

  Sergio Palazzo, University of Catania, Italy

Program Co-Chairs

  Tracy Camp, Colorado School of Mines, USA

  Marco Conti, IIT-CNR, Italy

Steering Committee

  Marco Conti, IIT-CNR, Italy

  Jon Crowcroft, University of Cambridge, UK

  Serge Fdida, Univ. Pierre et Marie Curie, France

  Mario Gerla, UCLA, USA

  Sergio Palazzo, University of Catania, Italy

  Mani Srivastava, UCLA, USA

-- 
============================================================
Ing. Emilio Ancillotti, PhD
   Pervasive Computing & Networking Lab. (PerLab)
   Institute for Informatics and Telematics (IIT)
   National Research Council (CNR)
      Via G. Moruzzi, 1    ||    voice:    +39 050 315 2437
      56124 Pisa, Italy    ||    fax:    +39 050 315 2113
                           ||    mobile:    +39 328 2963760
============================================================

From: Lloyd Wood <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Thu, 27 Aug 2009 17:11:02 +0100
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: [dtn-interest] Stockholm minutes was Re: Administrivia: (Was: Re: Delay tolerant networking and absolute timing)

Well, the webpage still says 8 August.

28 August would be tomorrow. I see that a draft set of minutes has  
been quietly posted:
http://www.ietf.org/proceedings/75/minutes/DTNRG.txt
and I've copied it below for list member attention and review.

The comment
"see DTNRG-4 slide set for per-draft info"
needs to be enlarged with Stephen's comments made at the time to the  
mike on the bundle checksum draft:
- that that draft really belonged in the first 'ready for last call'  
set, not the second 'earlier days' set.
- that Stephen had yet to read the latest version of that draft  
(published in May).

thanks,

L.

ETF 75 DTNRG Meeting Minutes [Aug 25; additions possible]
Stockholm, Sweden
31-Jul-2009

IAB Review
	Fall presented review of DTNRG to the IAB on 30-July-2009
	slides are included on meeting tracker

Doc update
	5 RFCs published (4838, 5050, 5325-5327)
	14 "live" (dtnrg) drafts
	4 non expired author drafts
	see DTNRG-4 slide set for per-draft info

Disconnectathon (Ivancic; NASA)
	Interoperability testing took place in terminal room and with other
	participants including NASA, Ohio U, BBN, Trinity, [N4C EU Project]
	implementations: Spindle (BBN), DTN2 (Intel, others), ION (NASA)
	convergence layers: UDP, TCP
	mostly static routing
	some bundles get stuck
	platforms: iPhone, various Linux, Symbian
	used dynamic DNS updates (on Internet) for coordination

Neighbor Discovery (BBN)
	draft-irtf-dtnrg-ipnd-00 (implemented by BBN)
		(UDP/IP specific)
	enumerated or unknown
	possibly across multiple IP hops

Intentional Naming (Prithwish Basu, BBN)
	ref: MIT Intentional Naming (1999)
	think queries in name structure
	progressive resolution
	scalability concerns if aggregation hard
	multiple routing schemes
	see draft-pbasu-dtnrg-naming-00.txt

Network Management (Ivancic)
	draft-ivancic-dtnrg-network-management-reqs-00
		want more comments
	related
		draft-cole-netconf-robust-config-01.txt
		draft-ietf-opsawg-operations-and-management-08.txt
	logging tool

Hermes: DT Bulk Xfers on the Internet (Laoutaris, Telefonica)
	[big] bulk data transfer (e.g. FedEx)
	see http://hermes.tid.es/hermes
	reasons for big data - science data, data mining, dist production,  
etc..
	goal: use excess capacity (at a good time) for DT bulk data xfers
	expensive networks (like CERN LHC)
		FedEx could be ~20x cheaper
		(today xfer is 27TByte/day)
	approach: water-filling technique over time
		requires in network storage

	discussion as to if FedEx costs will remain over time
		(e.g. as storage density goes up... it is on faster curve)

BBN Discussions of possible Extensions to BP (Leland)
	relative timestamps, hops to live, more CoS bits

   Discussion on Timing

	DTN bundle protocol includes absolute time
	some issues:
		getting the right time
		keeping the right time
		setting the wrong time
	discussion of how hard getting the time really is
		we have watches after all
	resistance by (e.g. some customers) from BBN to set time

	[most time spent here]

    Hops to live

    	motivated by routing loops
	(discussion that bundle ts wasn't designed to avoid this)

	also concern that IP-style TTL gives no info regarding
		hops traveled so far

    CoS bits

	want to map IP ToS bits into DTN CoS but not enough bits

	discussion: but DTN BP isn't designed just to carry IP, so is the need
		really compelling?

Other issues:
	if a WG on DTN subject matter is desired
	having another meeting at IETF 76 seems supported

On 7 Aug 2009, at 06:26, Stephen Farrell wrote:

> Thanks for your help Lloyd.
>
> [email-masked] wrote:
>> According to
>> https://datatracker.ietf.org/meeting/75/materials.html
>> the deadline for minutes is 8 August 2009 - ie tomorrow.
>
> Actually, according to Wanda, the deadline for proceedings
> submissions is 28th Aug so I guess there's a typo on that
> web page.
>
>> (I see material has been uploaded as ppt, which gives the IETF
>> difficulties in rendering to html pages - pdf is simpler and
>> preferable.)
>
> Yes. Feel free to offer help to the tools folks who've
> automated that process.
>
> Stephen.
>
>>
>> btw, the missing proceedings of IETF 73, including discussion
>> of two in-space tests, are now only available from:
>> http://www4.ietf.org/proceedings/08nov/agenda/DTNRG.html
>> now that the IETF website has been redesigned.
>> Replace www3 with www4 in each link on that page to get each
>> presentation.
>>
>> L.
>>
>> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] on behalf of
>> Stephen Farrell
>> Sent: Fri 2009-08-07 4:17
>> To: Henning Rogge
>> Cc: [email-masked]
>> Subject: Re: [dtn-interest] Delay tolerant networking and absolute  
>> timing
>>
>>
>> Hi Henning,
>>
>> Thanks for re-starting the discussion! (BTW, I'll post minutes  
>> soonish
>> but am travelling this week.)
>>

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Mon, 17 Aug 2009 00:18:35 +0100
From: Stephen Farrell <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

Hi Andrew,

Andrew Sullivan wrote:
> On Fri, Aug 07, 2009 at 04:17:08AM +0100, Stephen Farrell wrote:
> 
>> - Do that while remaining interoperable with RFC 5050 and so that
>>   existing code needs as little change as possible (ideally none)
> 
> I'm always sympathetic to this line of thinking, but surely in the
> case of experimental RFCs it has to be a low-priority consideration,
> no?  

Well, there should certainly be a lower barrier-to-entry for changes
compared to e.g. SMTP, but nonetheless we shouldn't ignore the effort
that was required to get RFC 5050 done, nor folks currently doing
experiments where compatibility is important (e.g. things that might
traverse dtnbone nodes) so there is properly (IMO) some reluctance
to accept incompatible changes, esp. where there's an option to do
something that's not incompatible.

> If there really is a problem with absolute timestamps, I'd think
> that changing them radically before moving from experimental to some
> other track would be the right moment.

I do agree that if/when the BP were to be put on the standards track
that at that point we should most likely rev the protocol version and
take the opportunity to make whatever changes are warranted. But
that'd almost certainly not be a problem for this RG given that an IETF
WG would likely be required for a standards track BP.

S.

> 
> A
> 

From: Peter Lovell <[email-masked]>
To: Lloyd Wood <[email-masked]>, Scott Burleigh <[email-masked]>
Date: Sun, 16 Aug 2009 19:01:03 -0400
Cc: [email-masked]
Subject: [dtn-interest] Re(2): Delay tolerant networking and absolute timing

On Sat, Aug 15, 2009, Lloyd Wood <[email-masked]> wrote:

>
>On 14 Aug 2009, at 16:02, Burleigh, Scott C (313B) wrote:
>
>> I think Andrew is exactly right: when we move BP to some other track
>> we need to resolve this question (and possibly a few others) and
>> make any necessary radical changes at that time.
>
>That is not what Andrew said below. Andrew said that the time for
>making these changes is while the status is experimental - before
>moving to some other status.
>
>In other words, right now.

Very true, Lloyd.

And that's what Scott said as he closed his comment ...

On Fri, Aug 14, 2009, Burleigh, Scott C (313B)
<[email-masked]> wrote:

>Let's get some experience with some of these ideas so that when we move
>to the next track we've got something concrete to talk about.

I'm getting a sense of violent agreement on this one.

Regards.....Peter

From: Lloyd Wood <[email-masked]>
To: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Sat, 15 Aug 2009 15:11:50 +0100
Cc: "[email-masked]" <[email-masked]>, Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

On 14 Aug 2009, at 16:02, Burleigh, Scott C (313B) wrote:

> I think Andrew is exactly right: when we move BP to some other track  
> we need to resolve this question (and possibly a few others) and  
> make any necessary radical changes at that time.

That is not what Andrew said below. Andrew said that the time for  
making these changes is while the status is experimental - before  
moving to some other status.

In other words, right now.

>
> Meanwhile, I think the existing RFC is loose enough to enable some  
> serious experimentation with alternatives long before we get to that  
> point.  For example, one could:
>
> -  Set the creation timestamp time of the bundle to some constant  
> time that is far in the future (e.g., 1 January 2020) so that  
> conformant implementations with accurate clocks will never expire  
> the bundle.  (Conversely, locally declare "the current time" to be  
> zero so as never to expire any bundles issued by conformant  
> implementations with accurate clocks.)
>
> -  Increment the creation timestamp sequence number continuously, so  
> that the concatenation of source EID and creation timestamp  
> continues to be a bundle identifier that can be used for custody  
> transfer, fragment reassembly, etc.
>
> -  Design an experimental extension block that contains the age of  
> the bundle in seconds.  Implementations that understand the  
> experimental extension block will update that figure as the bundle  
> makes its way through the network, destroying the bundle when its  
> age exceeds its lifetime.  Those that don't will process the bundle  
> according to whatever block processing control flags are set in the  
> block.
>
> -  Write this up in an I-D, implement it, run with it, and report on  
> your experience at the IETF meetings.
>
> I believe this would be well within compliance with RFC 5050 and  
> would interoperate with existing conformant implementations.  No  
> problem destroying a bundle on a basis other than absolute time  
> expiration: a bundle that's destined for the node that receives it  
> will simply be delivered (no expiration issue), while one that is to  
> be forwarded can always be deemed unforwardable ("forwarding  
> contraindicated") for any reason whatsoever and thereupon deleted.
>
> Let's get some experience with some of these ideas so that when we  
> move to the next track we've got something concrete to talk about.
>
> Scott
> ________________________________________
> From: [email-masked] [[email-masked] 
> ] On Behalf Of Andrew Sullivan [[email-masked]]
> Sent: Friday, August 14, 2009 4:01 AM
> To: [email-masked]
> Subject: Re: [dtn-interest] Delay tolerant networking and absolute  
> timing
>
> On Fri, Aug 07, 2009 at 04:17:08AM +0100, Stephen Farrell wrote:
>
>> - Do that while remaining interoperable with RFC 5050 and so that
>> existing code needs as little change as possible (ideally none)
>
> I'm always sympathetic to this line of thinking, but surely in the
> case of experimental RFCs it has to be a low-priority consideration,
> no?  If there really is a problem with absolute timestamps, I'd think
> that changing them radically before moving from experimental to some
> other track would be the right moment.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> 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 work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

Date: Fri, 14 Aug 2009 14:04:02 -0400
From: Aaron Falk <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] [Fwd: Copyrights and the IRTF and Independent Stream]

Forwarding to all active IRTF RG mail lists because this issue affects
the publication rights for IDs and RFCs developed within the IRTF. 
Information about IRTF RFCs can be found in
http://tools.ietf.org/html/draft-irtf-rfcs-03.  Please direct comments
to the RFC-interest list (coordinates below).

--aaron
  IRTF Chair

-------- Original Message --------
Subject: 	[rfc-i] Copyrights and the IRTF and Independent Stream
Date: 	Thu, 13 Aug 2009 18:59:42 +0200
From: 	Olaf Kolkman <[email-masked]>
To: 	RFC Interest <[email-masked]>

Dear Colleagues,

This mail is about rights in RFCs and Internet drafts. The topic draws
context, and uses terminology from:
RFC 4844: The RFC Series and RFC Editor
RFC 4846: Independent Submissions to the RFC Editor
RFC 5378: Rights Contributors Provide to the IETF Trust
RFC 5377: Advice to the Trustees of the IETF Trust on Rights to Be
Granted in IETF Documents

First some administrational notes.

This mail serves as setting a baseline for a public discussion and is
based on a few (virtual and real-life) hallway discussions. The goal
of this discussion is to make sure all issues are brought to the table
and the stream maintainers and the Trust are aware of the communities
opinions. I see my role as an IAB member that is driving the
discussion, and mildly moderating it. In the end it is the role of the
IAB to see that an appropriate stream dependent process has been
followed and that the streams do not interact inapropriatly. So in
that sense this discussion informs the IAB too.

Although this mail is sent to multiple lists I would like to urge folk
to discuss the issues on the rfc-interest list:
   http://www.rfc-editor.org/mailman/listinfo/rfc-interest

Without further ado.

As you may know RFCs are published from different streams. With
respect to the incoming and outgoing rights only the rights of the
IETF stream documents are well defined. And currently the IAB has
chosen to have IAB documents fall under this regime too. The situation
is less clear for Independent and IRTF Stream documents: all existing
provisions are targeted specifically towards IETF Contributions (in
the narrow context defined by RFC5378). Besides, currently and in the
context of copyrights, Internet Drafts (I-Ds) are seen as IETF
contributions.

Maintainers of the Independent and IRTF stream would like to have
documents from their streams published with full rights to make
derivative works or make no derivative works whatsoever, and require
attribution in both cases.

There are two strategies to make this work:

1. Allow I-Ds and RFCs for the IAB, IRTF, and Independent stream to be
published with a Creative Commons license added.

A rough outline of one of the ideas that is floating around ist that
all contributions that are intended to become an RFC or are an IETF
contribution (in the sense of RFC 5378 definition) will continue to
have the 5378 license terms as defined by the trust. Since 5378 is
non-exclusive authors may add a creative commons license if they'd
like to. Care should be taken that those licenses would not be applied
to IETF contributions, as that could lead to 'spoofed standard-track
RFCs'

2. Have the trust manage the rights for the IAB, IRTF, and Independent
streams RFCs and I-Ds.

Both strategies may require that at the moment Internet Drafts is
published as an RFC it is clear on which stream they are intended to
be published, with which rights, and that the authors have appropriate
authority to grant/sublicense those rights.

In both cases we want to avoid that IETF contributions (I-Ds and
RFCs, although it is not clear whether this is a strong requirement
for I-Ds) are published with a license policy that would circumvent the
Trust's control over the outgoing rights.

A tactic/straw-man to implement (2) is as follows:

    i) Treat all I-Ds as or similar to IETF contributions (this way
       there is no doubt about the Trust having all necessary rights,
       see BCP78 section 5.3). There seem to be two paths to proceed:

        i.1) The stream controllers choose to apply the RFC5378 rules.
        	    This possibility is offered in section 4 of 5378 and the
  	    IAB stream chooses to apply the rules through its
	    declaration in section 11.

        i.2) The streams write a stream specific "Rights contributors
             provide to the IETF trust" document.

     ii) Have the stream controllers request  the IETF Trust to create
         license(s) for non IETF-Stream RFCs that grant for (full|no)
	derivative rights, attribution required. (document this
	request in an RFC).

    iii) Ask the trust to develop language that can be put on an I-D
         with which the author can request (full|no) derivative rights
         if/when the I-D is published on a specific non-IETF stream
	document. This sort of text would serve as an indication of
	consent with wide licensing and could be included as
	boilerplate material together with an indication of intended
	stream (as in draft-iab-streams-headers- boileplates).

There are some pros and cons to this scheme that we need to identify
in public discussion, hence this mail.

During the hallway discussion, I've seen the following arguments and
identified the following open questions. I don't claim completeness.

- The Trust is not well equiped to hold non-IETF documents. Mainly
   because it requires the interperetation that all documents are IETF
   Documents.

   Is this interpretation based on language in the Trust agreement or
   on the definition of IETF Documents in the context of BCP78?

   Or, is the trust well suited, and does implementation only need some
   boilerplate changes?

- IETF Stream RFCs need to be protected by limited derivative rights
   so that the IETF keeps ownership over its Standards and can maintain
   those.

   Suppose a I-D with full derivative rights is posted (either because
   the author has published it with Creative Commons, or because the
   Trust allows full derivative rights for stream specific I-Ds) would
   narrowing down the rights by publication as an IETF stream RFC cause
   any problems?

Feedback welcome,

--Olaf Kolkman

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 14 Aug 2009 08:02:54 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

I think Andrew is exactly right: when we move BP to some other track we need to resolve this question (and possibly a few others) and make any necessary radical changes at that time.

Meanwhile, I think the existing RFC is loose enough to enable some serious experimentation with alternatives long before we get to that point.  For example, one could:

-  Set the creation timestamp time of the bundle to some constant time that is far in the future (e.g., 1 January 2020) so that conformant implementations with accurate clocks will never expire the bundle.  (Conversely, locally declare "the current time" to be zero so as never to expire any bundles issued by conformant implementations with accurate clocks.)

-  Increment the creation timestamp sequence number continuously, so that the concatenation of source EID and creation timestamp continues to be a bundle identifier that can be used for custody transfer, fragment reassembly, etc.

-  Design an experimental extension block that contains the age of the bundle in seconds.  Implementations that understand the experimental extension block will update that figure as the bundle makes its way through the network, destroying the bundle when its age exceeds its lifetime.  Those that don't will process the bundle according to whatever block processing control flags are set in the block.

-  Write this up in an I-D, implement it, run with it, and report on your experience at the IETF meetings.

I believe this would be well within compliance with RFC 5050 and would interoperate with existing conformant implementations.  No problem destroying a bundle on a basis other than absolute time expiration: a bundle that's destined for the node that receives it will simply be delivered (no expiration issue), while one that is to be forwarded can always be deemed unforwardable ("forwarding contraindicated") for any reason whatsoever and thereupon deleted.

Let's get some experience with some of these ideas so that when we move to the next track we've got something concrete to talk about.

Scott
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Andrew Sullivan [[email-masked]]
Sent: Friday, August 14, 2009 4:01 AM
To: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

On Fri, Aug 07, 2009 at 04:17:08AM +0100, Stephen Farrell wrote:

> - Do that while remaining interoperable with RFC 5050 and so that
>   existing code needs as little change as possible (ideally none)

I'm always sympathetic to this line of thinking, but surely in the
case of experimental RFCs it has to be a low-priority consideration,
no?  If there really is a problem with absolute timestamps, I'd think
that changing them radically before moving from experimental to some
other track would be the right moment.

A

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

Date: Fri, 14 Aug 2009 07:01:27 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

On Fri, Aug 07, 2009 at 04:17:08AM +0100, Stephen Farrell wrote:

> - Do that while remaining interoperable with RFC 5050 and so that
>   existing code needs as little change as possible (ideally none)

I'm always sympathetic to this line of thinking, but surely in the
case of experimental RFCs it has to be a low-priority consideration,
no?  If there really is a problem with absolute timestamps, I'd think
that changing them radically before moving from experimental to some
other track would be the right moment.

A

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

Date: Thu, 13 Aug 2009 15:02:41 -0700
From: Doug Otis <[email-masked]>
To: Kevin Fall <[email-masked]>
Cc: Kurtis Heimerl <[email-masked]>, dtn-users mailing list <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] [dtn-users] Time question.

On 8/13/09 9:49 AM, Kevin Fall wrote:
> Well, I figured we would be getting back to this discussion :)...
> cross-posting to dtn-interest
>
> A few things-
>
> The original purpose of wallclock time in bundles was to figure out
> when they could be dropped.  This had nothing to do with routing/loop
> detection or directly to DoS attacks, but was instead a thing the data
> originator could set in a bundle, intermediaries could figure out if
> dropping it was ok, and recipients could ascertain how old the
> information was when received (like you do in e-mail... an important
> bit of info imho). It is thus important for "data centric" networking.

Setting time on servers has been an area where things go wrong, such as 
using the wrong timezone.  When systems are recovering from a major 
crash, or where the accuracy of time is unknown, a means to indicate 
that absolute time is "uncertain" can simplify recovery attempts at 
interpolating what the correct time might be from successful 
interchanges purporting to be set to absolute time.

> Sync'd time is a basis for the setting the bundle origination
> timestamp, but also has many other benefits (like supporting routing
> protocols that require scheduling [a defined requirement for dtn],
> comparable logs, and as the basis for better security, network
> management operations, distributed ordering, etc).   Further, we
> assumed that the propagation delay for delivery can be very large and
> unknown... from space DTNs to USB sticks.  And contrary to another
> point raised, there are quite reasonable reasons why a USB stick acts
> as a way to distribute data {although whether its a "link" or "node"
> is an interesting discussion I have brought up a few times}.  So, the
> system by definition was assumed sync'd, so having a timestamp with
> sync'd time is not a big deal.

View the USB memory stick question in a OLPC environment where system 
time may not be initially trustworthy.  A USB memory stick will not be 
able to operate on the network without aid of a processor.  It would 
seem better to consider the memory stick to represent a data packet 
where time needs to be handled based upon assertions made when it was 
written, such as the time and whether the time should be considered 
accurate.

> In parallel to above, it was deemed considered reasonable to believe
> most systems could have clocks in approximate sync, and I at least
> believe this still to be true.  We may need to argue what
> 'approximate' means, but a few minutes in the worst possible case.  I
> would argue that if you can't get a system sync'd to within a few
> minutes (as people can with their watches, or oscillators can be once
> set from time to time), you have other problems.   Reasonable people
> may disagree.  And yes, there are some systems that may never be able
> to get a clock right yet should be able to talk bundles.  As I have
> said, I believe those are (should be) exceptional cases.

Humans will always introduce a need to make exceptions.  Humans are not 
machines, and even machines do not always have an inherent sense of time.

> "Exceptional" means that there should be ways of providing time sync
> within the DTN context (by supporting protocols if necessary) for
> almost all devices.  For those that simply can't get the time ever
> [still waiting to see one of those...] there should be a way to
> indicate that bundles they originate are using a totally local notion
> of time.  Perhaps there should also be a way of re-writing or
> augmenting bundles sent by such nodes with a best approximate
> originating timestamp (e.g., set by its nearest neighbor if delivered
> over a relatively low latency link).  Said yet another way, I think
> the capabilities of the current timestamp remain important and
> reasonable.

When delays are large, waiting to establish sync might cause a 
significant connectivity loss.  Being able to say "Treat a best guess at 
"absolute" time as being "relative" time, where handling expiry then 
uses incremental adjustments based upon reception and transmission 
deltas added to this "relative" time.

A system that believes that its time is correct should be able to 
convert relative time to absolute time, and relative expiry to absolute 
expiry based upon what the relative time adjustments (reception to 
transmission local times) would have allowed.

> That said, as I mentioned in Stockholm, I don't think we will ever
> bottom-out on this topic until we commit it to text in a document...
> "considerations on time for DTN" or the like.  And I would suggest we
> need to understand the following things:
>
> 1. what the range of time-impoverished devices behaviors are
> 	(e.g., boots with no time?  can't ever get the time?  doesn't have an
> oscillator?  crappy oscillator?)

  a) Not trusting operators to set time correctly.

  b) System crashes where time becomes uncertain.

  c) Systems detecting too many packet expirations.

> 2. what capabilities are sacrificed and enabled if the type of timing
> were changed this will likely be thought-provoking. For example, it
> isimportant to me that a bundle can be essentially "written on the wall"
> and picked up later. Said another way, I believe bundles need to be able
> to be written to storage for long periods of time (like in USB stick)
> and extracted later.

Writing a bundle should include "reception local time" of when bundles 
are received.  When a bundle is retransmitted, the difference between 
the "reception local time" and the "transmission local time" could be 
added to the "relative" time held in the bundle.  When the adjustment to 
"relative" time exceeds expiry time, the bundle would be dropped.

When a memory stick written by a system is unsure of the absolute time, 
then the unknown time between writing and reading of the memory stick 
could deduct some estimate from its "reception local time".

> I have some concerns about how any relative timer would work with this,
 > but my ears are open.
>
> Who's interested in such a doc?
>
>
> - K
>
>
> On Aug 13, 2009, at Aug 139:16 AMPDT, Ivancic, William D. (GRC-RHN0)
> wrote:
>
>>> On Behalf Of Kurtis Heimerl
>>> Sent: Thursday, August 13, 2009 11:51 AM
>>> To: Daniel Ellard
>>> Cc: dtn-users mailing list
>>> Subject: Re: [dtn-users] Time question.
>>
>> "My overarching point is that DTNs are supposed to put connectivity
>> over performance,"
>>
>> Kurtis, I am confused. Can you explain what you mean by the above
>> statement?
>>
>> My view of DTNs is that they are design to allow communication in
>> environments where disconnection is the norm with periods of
>> connectivity.  For some systems, those periods of connectivity are
>> know (such as in a space backbone) and for others it may be somewhat
>> known (such as a bus data-mule that has a fairly predictable
>> schedule) and for some systems connectivity may be extremely
>> sporadic and opportunistic.
>>
>> My view is the DTNs such as "Bundling" are design to optimize store-
>> and-forward resource allocation (storage, bandwidth and transmission)
>>
>>
>> "and a lot of these metrics are doing the opposite."
>>
>> Which metrics are you referring to?
>>
>>
>> "If we put a lot of these problems into E2E semantics and just focus
>> on how to avoid DOS (which directly impacts
>> connectivity) we'll be on more stable ground."
>>
>> Again, I am not clear what you are driving at above.  Are you saying
>> that we  may be mixing to much application with transport?  Can you
>> clarify.
>>
>>
>> Thanks,
>>
>> -- Will
>>
>>
>>
>>
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: Kevin Fall <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 13 Aug 2009 09:49:37 -0700
Cc: Kurtis Heimerl <[email-masked]>, dtn-users mailing list <[email-masked]>, [email-masked]
Subject: Re: [dtn-interest] [dtn-users] Time question.

Well, I figured we would be getting back to this discussion :)...  
cross-posting to dtn-interest

A few things-

The original purpose of wallclock time in bundles was to figure out  
when they could be dropped.  This had nothing to do with routing/loop  
detection or directly to DoS attacks, but was instead a thing the data  
originator could set in a bundle, intermediaries could figure out if  
dropping it was ok, and recipients could ascertain how old the  
information was when received (like you do in e-mail... an important  
bit of info imho). It is thus important for "data centric" networking.

Sync'd time is a basis for the setting the bundle origination  
timestamp, but also has many other benefits (like supporting routing  
protocols that require scheduling [a defined requirement for dtn],  
comparable logs, and as the basis for better security, network  
management operations, distributed ordering, etc).   Further, we  
assumed that the propagation delay for delivery can be very large and  
unknown... from space DTNs to USB sticks.  And contrary to another  
point raised, there are quite reasonable reasons why a USB stick acts  
as a way to distribute data {although whether its a "link" or "node"  
is an interesting discussion I have brought up a few times}.  So, the  
system by definition was assumed sync'd, so having a timestamp with  
sync'd time is not a big deal.

In parallel to above, it was deemed considered reasonable to believe  
most systems could have clocks in approximate sync, and I at least  
believe this still to be true.  We may need to argue what  
'approximate' means, but a few minutes in the worst possible case.  I  
would argue that if you can't get a system sync'd to within a few  
minutes (as people can with their watches, or oscillators can be once  
set from time to time), you have other problems.   Reasonable people  
may disagree.  And yes, there are some systems that may never be able  
to get a clock right yet should be able to talk bundles.  As I have  
said, I believe those are (should be) exceptional cases.   
"Exceptional" means that there should be ways of providing time sync  
within the DTN context (by supporting protocols if necessary) for  
almost all devices.  For those that simply can't get the time ever  
[still waiting to see one of those...] there should be a way to  
indicate that bundles they originate are using a totally local notion  
of time.  Perhaps there should also be a way of re-writing or  
augmenting bundles sent by such nodes with a best approximate  
originating timestamp (e.g., set by its nearest neighbor if delivered  
over a relatively low latency link).  Said yet another way, I think  
the capabilities of the current timestamp remain important and  
reasonable.

That said, as I mentioned in Stockholm, I don't think we will ever  
bottom-out on this topic until we commit it to text in a document...  
"considerations on time for DTN" or the like.  And I would suggest we  
need to understand the following things:

1. what the range of time-impoverished devices behaviors are
	(e.g., boots with no time?  can't ever get the time?  doesn't have an  
oscillator?  crappy oscillator?)

2. what capabilities are sacrificed and enabled if the type of timing  
were changed

	this will likely be thought-provoking.  For example, it is important  
to me that a bundle can
	be essentially "written on the wall" and picked up later.  Said  
another way, I believe bundles need
	to be able to be written to storage for long periods of time (like in  
USB stick) and extracted later.
	I have some concerns about how any relative timer would work with  
this, but my ears are open.

Who's interested in such a doc?

- K

On Aug 13, 2009, at Aug 139:16 AMPDT, Ivancic, William D. (GRC-RHN0)  
wrote:

>> On Behalf Of Kurtis Heimerl
>> Sent: Thursday, August 13, 2009 11:51 AM
>> To: Daniel Ellard
>> Cc: dtn-users mailing list
>> Subject: Re: [dtn-users] Time question.
>
> "My overarching point is that DTNs are supposed to put connectivity  
> over performance,"
>
> Kurtis, I am confused. Can you explain what you mean by the above  
> statement?
>
> My view of DTNs is that they are design to allow communication in  
> environments where disconnection is the norm with periods of  
> connectivity.  For some systems, those periods of connectivity are  
> know (such as in a space backbone) and for others it may be somewhat  
> known (such as a bus data-mule that has a fairly predictable  
> schedule) and for some systems connectivity may be extremely  
> sporadic and opportunistic.
>
> My view is the DTNs such as "Bundling" are design to optimize store- 
> and-forward resource allocation (storage, bandwidth and transmission)
>
>
> "and a lot of these metrics are doing the opposite."
>
> Which metrics are you referring to?
>
>
> "If we put a lot of these problems into E2E semantics and just focus  
> on how to avoid DOS (which directly impacts
> connectivity) we'll be on more stable ground."
>
> Again, I am not clear what you are driving at above.  Are you saying  
> that we  may be mixing to much application with transport?  Can you  
> clarify.
>
>
> Thanks,
>
> -- Will
>
>
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Wed, 12 Aug 2009 21:06:14 -0700
Subject: [dtn-interest] AWS import/export

(in case you haven't seen this yet)...

Store-carry-forward goes commercial:

http://aws.amazon.com/importexport/

- K

From: Kevin Fall <[email-masked]>
To: [email-masked]
Date: Wed, 12 Aug 2009 19:16:37 -0700
Subject: [dtn-interest] of possible interest

paper that will appear in SIGCOMM:

LIPSIN: Line Speed Publish/Subscribe Inter-Networking
Submitted by admin on Thu, 30/07/2009 - 09:48.
Author(s): Petri Jokela, András Zahemszky, Christian Esteve  
Rothenberg, Somaya Arianfar and Pekka Nikander
Abstract:

A large fraction of today’s Internet applications are internally  
publish/subscribe in nature; the current architecture makes it  
cumbersome and inept to support them. In essence, supporting efficient  
publish/subscribe requires data-oriented naming, efficient multicast,  
and in-network caching. Deployment of native IP-based multicast has  
failed, and overlay- based multicast systems are inherently  
inefficient. We surmise that scalable and efficient publish/subscribe  
will require substantial architectural changes, such as moving from  
endpoint-oriented systems to information-centric architectures.
In this paper, we propose a novel multicast forwarding fabric,  
suitable for large-scale topic-based publish/subscribe. Due to very  
simple forwarding decisions and small forwarding tables, the fabric  
may be more energy efficient than the currently used ones. To  
understand the limitations and potential, we provide efficiency and  
scalability analysis via simulations and early measurements from our  
two implementations. We show that the system scales up to metropolitan  
WAN sizes, and we discuss how to interconnect separate networks.

http://ccr.sigcomm.org/online/?q=node/491

- K

Date: Wed, 12 Aug 2009 15:43:05 +0300
From: Teemu <[email-masked]>
To: debora job <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] servlib error

Hi,

You could try getting it directly from the repository, which IIRC contains a
fix to that bug.

Cheers,
-Teemu

On 12.8.2009 14.40, "debora job" <[email-masked]> wrote:

> I've downloaded dtn-2.6.0 and oasys-1.3.0 from the DTN sourceforge
> site. I unzipped them into /home/mydir/dtn2 on my ubuntu 8.10 system.
> I compiled oasys ande after a typed
> cd dnt-2.6.0
> ./configure -C
> make
> 
> And after a while I get this:
> 
> make -w -C applib
> make[1]: Entrando no diretório `/home/no1/dtn-2.6.0/applib'
> make[1]: Nada a ser feito para `all'.
> make[1]: Saindo do diretório `/home/no1/dtn-2.6.0/applib'
> make -w -C servlib
> make[1]: Entrando no diretório `/home/no1/dtn-2.6.0/servlib'
> g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "bundling/SequenceID.o
> bundling/SequenceID.E"  -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -I.. -I.. -I/home/no1/oasys-1.3.0/include
> -I/home/no1/oasys-1.3.0/include/oasys/ext -I../servlib
> -I/usr/include/tcl8.4  -Wall -W -Wcast-align  -c
> bundling/SequenceID.cc -o bundling/SequenceID.o
> In file included from bundling/SequenceID.cc:22:
> ../oasys/util/SafeRange.h:35: erro: expected `)' before Œoffset¹
> ../oasys/util/SafeRange.h:36: erro: Œsize_t¹ does not name a type
> ../oasys/util/SafeRange.h:39: erro: Œsize_t¹ has not been declared
> ../oasys/util/SafeRange.h:42: erro: declaration of Œoperator[]¹ as
> non-function
> ../oasys/util/SafeRange.h:42: erro: expected Œ;¹ before Œ(¹ token
> In file included from /usr/include/c++/4.2/i486-linux-gnu/bits/c++io.h:43,
>                  from /usr/include/c++/4.2/iosfwd:46,
>                  from /usr/include/c++/4.2/ios:43,
>                  from /usr/include/c++/4.2/ostream:45,
>                  from /usr/include/c++/4.2/iostream:45,
>                  from ../oasys/util/../debug/Log.h:94,
>                  from ../oasys/util/StringAppender.h:22,
>                  from bundling/SequenceID.cc:23:
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `;'
> before end of line
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `}'
> before end of line
> In file included from bundling/SequenceID.cc:22:
> ../oasys/util/SafeRange.h: In constructor
> Œoasys::SafeRange<_Type>::SafeRange(_Type*, int)¹:
> ../oasys/util/SafeRange.h:40: erro: class Œoasys::SafeRange<_Type>¹
> does not have any field named Œarray_¹
> ../oasys/util/SafeRange.h:40: erro: class Œoasys::SafeRange<_Type>¹
> does not have any field named Œsize_¹
> In file included from /usr/include/c++/4.2/i486-linux-gnu/bits/c++io.h:43,
>                  from /usr/include/c++/4.2/iosfwd:46,
>                  from /usr/include/c++/4.2/ios:43,
>                  from /usr/include/c++/4.2/ostream:45,
>                  from /usr/include/c++/4.2/iostream:45,
>                  from ../oasys/util/../debug/Log.h:94,
>                  from ../oasys/util/StringAppender.h:22,
>                  from bundling/SequenceID.cc:23:
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h: At global scope:
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected
> unqualified-id before end of line
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `}'
> before end of line
> /usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected
> declaration before end of line
> make[1]: ** [bundling/SequenceID.o] Erro 1
> make[1]: Saindo do diretório `/home/no1/dtn-2.6.0/servlib'
> make: ** [servlib] Erro 2
> 
> Can I help me?
>  Thanks
> Debora Job
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Wed, 12 Aug 2009 08:40:03 -0300
From: debora job <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] servlib error

I've downloaded dtn-2.6.0 and oasys-1.3.0 from the DTN sourceforge
site. I unzipped them into /home/mydir/dtn2 on my ubuntu 8.10 system.
I compiled oasys ande after a typed
cd dnt-2.6.0
./configure -C
make

And after a while I get this:

make -w -C applib
make[1]: Entrando no diretório `/home/no1/dtn-2.6.0/applib'
make[1]: Nada a ser feito para `all'.
make[1]: Saindo do diretório `/home/no1/dtn-2.6.0/applib'
make -w -C servlib
make[1]: Entrando no diretório `/home/no1/dtn-2.6.0/servlib'
g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "bundling/SequenceID.o
bundling/SequenceID.E"  -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I.. -I.. -I/home/no1/oasys-1.3.0/include
-I/home/no1/oasys-1.3.0/include/oasys/ext -I../servlib
-I/usr/include/tcl8.4  -Wall -W -Wcast-align  -c
bundling/SequenceID.cc -o bundling/SequenceID.o
In file included from bundling/SequenceID.cc:22:
../oasys/util/SafeRange.h:35: erro: expected `)' before ‘offset’
../oasys/util/SafeRange.h:36: erro: ‘size_t’ does not name a type
../oasys/util/SafeRange.h:39: erro: ‘size_t’ has not been declared
../oasys/util/SafeRange.h:42: erro: declaration of ‘operator[]’ as non-function
../oasys/util/SafeRange.h:42: erro: expected ‘;’ before ‘(’ token
In file included from /usr/include/c++/4.2/i486-linux-gnu/bits/c++io.h:43,
                 from /usr/include/c++/4.2/iosfwd:46,
                 from /usr/include/c++/4.2/ios:43,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iostream:45,
                 from ../oasys/util/../debug/Log.h:94,
                 from ../oasys/util/StringAppender.h:22,
                 from bundling/SequenceID.cc:23:
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `;'
before end of line
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `}'
before end of line
In file included from bundling/SequenceID.cc:22:
../oasys/util/SafeRange.h: In constructor
‘oasys::SafeRange<_Type>::SafeRange(_Type*, int)’:
../oasys/util/SafeRange.h:40: erro: class ‘oasys::SafeRange<_Type>’
does not have any field named ‘array_’
../oasys/util/SafeRange.h:40: erro: class ‘oasys::SafeRange<_Type>’
does not have any field named ‘size_’
In file included from /usr/include/c++/4.2/i486-linux-gnu/bits/c++io.h:43,
                 from /usr/include/c++/4.2/iosfwd:46,
                 from /usr/include/c++/4.2/ios:43,
                 from /usr/include/c++/4.2/ostream:45,
                 from /usr/include/c++/4.2/iostream:45,
                 from ../oasys/util/../debug/Log.h:94,
                 from ../oasys/util/StringAppender.h:22,
                 from bundling/SequenceID.cc:23:
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h: At global scope:
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected
unqualified-id before end of line
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected `}'
before end of line
/usr/include/c++/4.2/i486-linux-gnu/bits/gthr.h:33: erro: expected
declaration before end of line
make[1]: ** [bundling/SequenceID.o] Erro 1
make[1]: Saindo do diretório `/home/no1/dtn-2.6.0/servlib'
make: ** [servlib] Erro 2

Can I help me?
 Thanks
Debora Job

From: "Rositca Goleva" <[email-masked]>
To: Lloyd Wood <[email-masked]>, "Michael R. Davis" <[email-masked]>
Date: Sat, 8 Aug 2009 22:52:59 +0300
Cc: [email-masked]
Subject: Re: [dtn-interest] FW: DTN News via DISA (UNCLASSIFIED)

Hi,

IS-14 is Intelsat satellite that is geostationary. 

Iridium is former global mobile telephony project and is set on the network of 
satellites that are not geostationary.

Kind greetings!

Rossy.

On Sat, 8 Aug 2009 13:54:53 +0100, Lloyd Wood wrote
> Iridium isn't geostationary.
> IS-14 is an Intelsat satellite.
> http://www.cisco.com/go/iris
> 
> On 8 Aug 2009, at 08:46, Michael R. Davis wrote:
> 
> > Some interesting DTN news being passed around DISA.
> > Mike - mrdvt92
> >
> >> Classification: UNCLASSIFIED
> >> Caveats: NONE
> >>
> >> DTN Internet Begins Transmitting From ISS.
> >>
> >>
> >> The AP (7/7) reports,
> >> "Researchers at the University  of Colorado are working
> >> with NASA to extend the Internet to outer space to help an
> >> expected growing
> >> number spaceships communicate with each other and with
> >> Earth." The
> >> Disruption-Tolerant Networking (DTN) "sends messages
> >> in bundles, streamlining
> >> the current, cumbersome point-to-point system that requires
> >> manual scheduling
> >> and programing to send information." The system was
> >> "installed on a
> >> payload sent to the International Space Station in May,
> >> said Kevin Gifford of
> >> Boulder's BioServe Space Technologies."
> >>
> >>
> >>
> >> New Scientist (7/7, Courtland)
> >> notes that the DTN payload at the station "recently
> >> sent down its first
> >> science data – images of crystals formed by metal
> >> salts in free-fall. ...
> >> Its new capability has already speeded up the transfer of
> >> data back to Earth by
> >> about four times, says...Gifford." According to the
> >> article, DTN could
> >> also "alleviate traffic on NASA's Deep Space
> >> Network...that is in need of
> >> refurbishment." NASA plans to have the system
> >> completed by 2011. "The
> >> ISS will act as a testing platform to perfect the protocol
> >> and help iron out
> >> any bugs."
> >>
> >>
> >> Internet Router Will Be Tested
> >> On Iridium Satellite. IDG News
> >> Service (7/7, Lawson)
> >> reports Cisco "is about to enter a new frontier,
> >> sending one into
> >> geostationary orbit on a satellite. It's the first big
> >> step in a US Defense
> >> Department-led initiative, called Internet Routers In Space
> >> (IRIS), that could
> >> eventually make it easier and less expensive to get
> >> high-speed Internet access
> >> where wires and cables don't reach." The system
> >> will be tested for over a
> >> year aboard Iriduim's IS-14 satellite scheduled to be
> >> launched by the end of
> >> the year. "Cisco believes the router will have a
> >> throughput of about
> >> 100Mbps once in space, a small figure for Earth-based
> >> routers, unprecedented in
> >> orbit." Satellite consultant Mark Chartrand stated
> >> that there is
> >> "real interest" in the system. "Armed forces
> >> need low-latency
> >> communications within war zones that are hard to predict,
> >> he said. Also, a
> >> routed network of satellites could continue operating even
> >> if Earth stations
> >> were destroyed."
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
Rossitza Ivanova Goleva, 
Assistant-Professor, Member of IEEE 
Chair of Bulgaria Section of IEEE 
Department of Communication Networks
Faculty of Telecommunications
Technical University of Sofia 
Kl. Ohridski blvd. 8 
Sofia, 1756, Bulgaria 
Phone (+359 2) 965 3251 Office 
(+359 887) 99 19 19 Mobile 
(+359 895) 590 240 Mobile
Email [email-masked] 
[email-masked]
http://telecom.tu-sofia.bg 
Face meetings in room 1449
Monday 13:30-15:30
Thursday 10:30-12:30

________________________________________________
Inflex + NOD32 + SpamAssassin
Installed on mailserver for domain @tu-sofia.bg
Queries to: [email-masked]

From: Lloyd Wood <[email-masked]>
To: "Michael R. Davis" <[email-masked]>
Date: Sat, 8 Aug 2009 13:54:53 +0100
Cc: [email-masked], Lloyd Wood <[email-masked]>
Subject: Re: [dtn-interest] FW: DTN News via DISA (UNCLASSIFIED)

Iridium isn't geostationary.
IS-14 is an Intelsat satellite.
http://www.cisco.com/go/iris

On 8 Aug 2009, at 08:46, Michael R. Davis wrote:

> Some interesting DTN news being passed around DISA.
> Mike - mrdvt92
>
>> Classification: UNCLASSIFIED
>> Caveats: NONE
>>
>> DTN Internet Begins Transmitting From ISS.
>>
>>
>> The AP (7/7) reports,
>> "Researchers at the University  of Colorado are working
>> with NASA to extend the Internet to outer space to help an
>> expected growing
>> number spaceships communicate with each other and with
>> Earth." The
>> Disruption-Tolerant Networking (DTN) "sends messages
>> in bundles, streamlining
>> the current, cumbersome point-to-point system that requires
>> manual scheduling
>> and programing to send information." The system was
>> "installed on a
>> payload sent to the International Space Station in May,
>> said Kevin Gifford of
>> Boulder's BioServe Space Technologies."
>>
>>
>>
>> New Scientist (7/7, Courtland)
>> notes that the DTN payload at the station "recently
>> sent down its first
>> science data – images of crystals formed by metal
>> salts in free-fall. ...
>> Its new capability has already speeded up the transfer of
>> data back to Earth by
>> about four times, says...Gifford." According to the
>> article, DTN could
>> also "alleviate traffic on NASA's Deep Space
>> Network...that is in need of
>> refurbishment." NASA plans to have the system
>> completed by 2011. "The
>> ISS will act as a testing platform to perfect the protocol
>> and help iron out
>> any bugs."
>>
>>
>> Internet Router Will Be Tested
>> On Iridium Satellite. IDG News
>> Service (7/7, Lawson)
>> reports Cisco "is about to enter a new frontier,
>> sending one into
>> geostationary orbit on a satellite. It's the first big
>> step in a US Defense
>> Department-led initiative, called Internet Routers In Space
>> (IRIS), that could
>> eventually make it easier and less expensive to get
>> high-speed Internet access
>> where wires and cables don't reach." The system
>> will be tested for over a
>> year aboard Iriduim's IS-14 satellite scheduled to be
>> launched by the end of
>> the year. "Cisco believes the router will have a
>> throughput of about
>> 100Mbps once in space, a small figure for Earth-based
>> routers, unprecedented in
>> orbit." Satellite consultant Mark Chartrand stated
>> that there is
>> "real interest" in the system. "Armed forces
>> need low-latency
>> communications within war zones that are hard to predict,
>> he said. Also, a
>> routed network of satellites could continue operating even
>> if Earth stations
>> were destroyed."

Date: Sat, 8 Aug 2009 00:46:50 -0700 (PDT)
From: "Michael R. Davis" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] FW: DTN News via DISA (UNCLASSIFIED)

Some interesting DTN news being passed around DISA.
Mike - mrdvt92

> Classification: UNCLASSIFIED
> Caveats: NONE 
> 
> DTN Internet Begins Transmitting From ISS.
> 
> 
> The AP (7/7) reports,
> "Researchers at the University  of Colorado are working
> with NASA to extend the Internet to outer space to help an
> expected growing
> number spaceships communicate with each other and with
> Earth." The
> Disruption-Tolerant Networking (DTN) "sends messages
> in bundles, streamlining
> the current, cumbersome point-to-point system that requires
> manual scheduling
> and programing to send information." The system was
> "installed on a
> payload sent to the International Space Station in May,
> said Kevin Gifford of
> Boulder's BioServe Space Technologies."
>  
> 
> Â Â Â Â Â Â Â 
> New Scientist (7/7, Courtland)
> notes that the DTN payload at the station "recently
> sent down its first
> science data â€“ images of crystals formed by metal
> salts in free-fall. ...
> Its new capability has already speeded up the transfer of
> data back to Earth by
> about four times, says...Gifford." According to the
> article, DTN could
> also "alleviate traffic on NASA's Deep Space
> Network...that is in need of
> refurbishment." NASA plans to have the system
> completed by 2011. "The
> ISS will act as a testing platform to perfect the protocol
> and help iron out
> any bugs."  
> 
> Â Â Â Â Â Â Â 
> Internet Router Will Be Tested
> On Iridium Satellite. IDG News
> Service (7/7, Lawson)
> reports Cisco "is about to enter a new frontier,
> sending one into
> geostationary orbit on a satellite. It's the first big
> step in a US Defense
> Department-led initiative, called Internet Routers In Space
> (IRIS), that could
> eventually make it easier and less expensive to get
> high-speed Internet access
> where wires and cables don't reach." The system
> will be tested for over a
> year aboard Iriduim's IS-14 satellite scheduled to be
> launched by the end of
> the year. "Cisco believes the router will have a
> throughput of about
> 100Mbps once in space, a small figure for Earth-based
> routers, unprecedented in
> orbit." Satellite consultant Mark Chartrand stated
> that there is
> "real interest" in the system. "Armed forces
> need low-latency
> communications within war zones that are hard to predict,
> he said. Also, a
> routed network of satellites could continue operating even
> if Earth stations
> were destroyed." 
> 

      

Date: Fri, 07 Aug 2009 11:11:14 -0700
From: Doug Otis <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

On 8/6/09 9:53 PM, [email-masked] wrote:
> It would be useful for each bundle to add a 'received at time
> t/sent at time t1' extension block, to allow retroactive discovery
> of nodes that don't know that their clock is off (and possibly
> some sort of management clock correction?) Hey, works for email.

Rather than depending upon a time standard, adopt a definition for the 
bit 6 flag to indicate expiry is based upon accumulated transit time. 
As such, each node that recognizes the meaning of this flag will advance 
the time value as a measure of transit time.

The expiry time would be a one's complement of the number of seconds 
allotted for transit.  The failure mode for node that don't understand 
the meaning of the bit 6 flag would be that expiry would never occur.

Perhaps a solution for this problem could be to initiate the transit 
time with the normal epoch time and add this time with the allotted 
transit time to generate the one's complement expiry time.  At least a 
node that did not understand what bit 6 meant, might have default limits 
to override what might otherwise appear as a bogus expiry limit.

-Doug

Date: Fri, 07 Aug 2009 06:26:04 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [dtn-interest] Administrivia: (Was: Re: Delay tolerant networking and absolute timing)

Thanks for your help Lloyd.

[email-masked] wrote:
> According to
> https://datatracker.ietf.org/meeting/75/materials.html
> the deadline for minutes is 8 August 2009 - ie tomorrow.

Actually, according to Wanda, the deadline for proceedings
submissions is 28th Aug so I guess there's a typo on that
web page.

> (I see material has been uploaded as ppt, which gives the IETF
> difficulties in rendering to html pages - pdf is simpler and
> preferable.)

Yes. Feel free to offer help to the tools folks who've
automated that process.

Stephen.

> 
> btw, the missing proceedings of IETF 73, including discussion
> of two in-space tests, are now only available from:
> http://www4.ietf.org/proceedings/08nov/agenda/DTNRG.html
> now that the IETF website has been redesigned.
> Replace www3 with www4 in each link on that page to get each
> presentation.
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
> 
> 
> 
> -----Original Message-----
> From: [email-masked] on behalf of
> Stephen Farrell
> Sent: Fri 2009-08-07 4:17
> To: Henning Rogge
> Cc: [email-masked]
> Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing
> 
> 
> Hi Henning,
> 
> Thanks for re-starting the discussion! (BTW, I'll post minutes soonish
> but am travelling this week.)
> 

Content-class: urn:content-classes:message
Date: Fri, 7 Aug 2009 05:53:14 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA171B.7043CBC6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It would be useful for each bundle to add a 'received at time
t/sent at time t1' extension block, to allow retroactive discovery
of nodes that don't know that their clock is off (and possibly
some sort of management clock correction?) Hey, works for email.

There are likely spoofing possibilities - just like email.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Stephen Farrell
Sent: Fri 2009-08-07 4:17
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute =
timing
=20

Hi Henning,

Thanks for re-starting the discussion! (BTW, I'll post minutes soonish
but am travelling this week.)

>From my p-o-v there are two things I'd like to see:

- Add a capability to handle nodes with no (good enough) clock to
  the bundle protocol
- Do that while remaining interoperable with RFC 5050 and so that
  existing code needs as little change as possible (ideally none)

The first thing that occurs to me is that the node with no clock
can put in some kind of (hopefully) unique number in the timestamp
field and then add a (new, TBD) extension block that basically says
"the timestamp is rubbish, but please forward this anyway". It could
be that the first hop that does have a clock and supports the
new extension block should add yet another extension block
that says "saw this first at time t" so that subsequent nodes
could then expire the bundle if necessary.

However, I've not thought it out in detail, so there're probably
holes galore.

Cheers,
Stephen.

Henning Rogge wrote:
> Hello,
>=20
> I have visited the workinggroup meeting in Stockholm and would like to =
start a=20
> discussion about absolute timestamps in DTN (the last presentation =
mentioned=20
> the possibility to adapt DTN to relative timestamps).
>=20
> Absolute timing can be a real pain in large networks with autonomous =
nodes.=20
> Many embedded devices lack a GPS receiver and manets/mesh networks =
cannot rely=20
> on a central time source like GSM or UMTS networks. Setting the time =
to a=20
> "roughly synchronized" value doesn't really scale well with network =
size. I=20
> just try to imagine an emergency response team after a tsunami which =
has so=20
> sync 500 nodes before they can start, especially if they are coming =
from 10=20
> different countries distributed over a few days.
>=20
> I think it would be a good idea to switch to relative timestamps where =
it is=20
> possible. If some parts of the protocol cannot work without absolute =
timing,=20
> each station could try to learn the time difference to all of it's =
neighbors=20
> (without sync the clocks), so it can translate incoming absolute =
timings into=20
> local time.
>=20
> What do you think about this ?
>=20
> Henning Rogge
>=20
> *************************************************
> Diplom-Informatiker Henning Rogge
> Forschungsgesellschaft f=FCr
> Angewandte Naturwissenschaften e. V. (FGAN)=20
> Neuenahrer Str. 20, 53343 Wachtberg, Germany
> Tel.: 0049 (0)228 9435-961
> Fax: 0049 (0)228 9435-685
> E-Mail: [email-masked]
> Web: www.fgan.de
> ************************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender =

> (Stellv.)
>=20
>=20
>=20
> =
------------------------------------------------------------------------
>=20
> _______________________________________________
> 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

------_=_NextPart_001_01CA171B.7043CBC6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Delay tolerant networking and absolute =
timing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>It would be useful for each bundle to add a 'received =
at time<BR>
t/sent at time t1' extension block, to allow retroactive discovery<BR>
of nodes that don't know that their clock is off (and possibly<BR>
some sort of management clock correction?) Hey, works for email.<BR>
<BR>
There are likely spoofing possibilities - just like email.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Stephen Farrell<BR>
Sent: Fri 2009-08-07 4:17<BR>
To: Henning Rogge<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] Delay tolerant networking and absolute =
timing<BR>
<BR>
<BR>
Hi Henning,<BR>
<BR>
Thanks for re-starting the discussion! (BTW, I'll post minutes =
soonish<BR>
but am travelling this week.)<BR>
<BR>
&gt;From my p-o-v there are two things I'd like to see:<BR>
<BR>
- Add a capability to handle nodes with no (good enough) clock to<BR>
&nbsp; the bundle protocol<BR>
- Do that while remaining interoperable with RFC 5050 and so that<BR>
&nbsp; existing code needs as little change as possible (ideally =
none)<BR>
<BR>
The first thing that occurs to me is that the node with no clock<BR>
can put in some kind of (hopefully) unique number in the timestamp<BR>
field and then add a (new, TBD) extension block that basically says<BR>
&quot;the timestamp is rubbish, but please forward this anyway&quot;. It =
could<BR>
be that the first hop that does have a clock and supports the<BR>
new extension block should add yet another extension block<BR>
that says &quot;saw this first at time t&quot; so that subsequent =
nodes<BR>
could then expire the bundle if necessary.<BR>
<BR>
However, I've not thought it out in detail, so there're probably<BR>
holes galore.<BR>
<BR>
Cheers,<BR>
Stephen.<BR>
<BR>
Henning Rogge wrote:<BR>
&gt; Hello,<BR>
&gt;<BR>
&gt; I have visited the workinggroup meeting in Stockholm and would like =
to start a<BR>
&gt; discussion about absolute timestamps in DTN (the last presentation =
mentioned<BR>
&gt; the possibility to adapt DTN to relative timestamps).<BR>
&gt;<BR>
&gt; Absolute timing can be a real pain in large networks with =
autonomous nodes.<BR>
&gt; Many embedded devices lack a GPS receiver and manets/mesh networks =
cannot rely<BR>
&gt; on a central time source like GSM or UMTS networks. Setting the =
time to a<BR>
&gt; &quot;roughly synchronized&quot; value doesn't really scale well =
with network size. I<BR>
&gt; just try to imagine an emergency response team after a tsunami =
which has so<BR>
&gt; sync 500 nodes before they can start, especially if they are coming =
from 10<BR>
&gt; different countries distributed over a few days.<BR>
&gt;<BR>
&gt; I think it would be a good idea to switch to relative timestamps =
where it is<BR>
&gt; possible. If some parts of the protocol cannot work without =
absolute timing,<BR>
&gt; each station could try to learn the time difference to all of it's =
neighbors<BR>
&gt; (without sync the clocks), so it can translate incoming absolute =
timings into<BR>
&gt; local time.<BR>
&gt;<BR>
&gt; What do you think about this ?<BR>
&gt;<BR>
&gt; Henning Rogge<BR>
&gt;<BR>
&gt; *************************************************<BR>
&gt; Diplom-Informatiker Henning Rogge<BR>
&gt; Forschungsgesellschaft f=FCr<BR>
&gt; Angewandte Naturwissenschaften e. V. (FGAN)<BR>
&gt; Neuenahrer Str. 20, 53343 Wachtberg, Germany<BR>
&gt; Tel.: 0049 (0)228 9435-961<BR>
&gt; Fax: 0049 (0)228 9435-685<BR>
&gt; E-Mail: [email-masked]<BR>
&gt; Web: www.fgan.de<BR>
&gt; ************************************************<BR>
&gt; Sitz der Gesellschaft: Bonn<BR>
&gt; Registergericht: Amtsgericht Bonn VR 2530<BR>
&gt; Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim =
Ender<BR>
&gt; (Stellv.)<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; =
------------------------------------------------------------------------<=
BR>
&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dtn-interest mailing list<BR>
&gt; [email-masked]<BR>
&gt; <A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
_______________________________________________<BR>
dtn-interest mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://maillists.intel-research.net/mailman/listinfo/dtn-interest=
">http://maillists.intel-research.net/mailman/listinfo/dtn-interest</A><B=
R>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA171B.7043CBC6--

Content-class: urn:content-classes:message
Date: Fri, 7 Aug 2009 05:53:06 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA171A.F4212FDD
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

According to
https://datatracker.ietf.org/meeting/75/materials.html
the deadline for minutes is 8 August 2009 - ie tomorrow.
(I see material has been uploaded as ppt, which gives the IETF
difficulties in rendering to html pages - pdf is simpler and
preferable.)

btw, the missing proceedings of IETF 73, including discussion
of two in-space tests, are now only available from:
http://www4.ietf.org/proceedings/08nov/agenda/DTNRG.html
now that the IETF website has been redesigned.
Replace www3 with www4 in each link on that page to get each
presentation.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of =
Stephen Farrell
Sent: Fri 2009-08-07 4:17
To: Henning Rogge
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute =
timing
=20

Hi Henning,

Thanks for re-starting the discussion! (BTW, I'll post minutes soonish
but am travelling this week.)

------_=_NextPart_001_01CA171A.F4212FDD
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>RE: [dtn-interest] Delay tolerant networking and absolute =
timing</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>According to<BR>
<A =
HREF=3D"https://datatracker.ietf.org/meeting/75/materials.html">https://d=
atatracker.ietf.org/meeting/75/materials.html</A><BR>
the deadline for minutes is 8 August 2009 - ie tomorrow.<BR>
(I see material has been uploaded as ppt, which gives the IETF<BR>
difficulties in rendering to html pages - pdf is simpler and<BR>
preferable.)<BR>
<BR>
btw, the missing proceedings of IETF 73, including discussion<BR>
of two in-space tests, are now only available from:<BR>
<A =
HREF=3D"http://www4.ietf.org/proceedings/08nov/agenda/DTNRG.html">http://=
www4.ietf.org/proceedings/08nov/agenda/DTNRG.html</A><BR>
now that the IETF website has been redesigned.<BR>
Replace www3 with www4 in each link on that page to get each<BR>
presentation.<BR>
<BR>
L.<BR>
<BR>
&lt;<A =
HREF=3D"http://www.ee.surrey.ac.uk/Personal/L.Wood/">http://www.ee.surrey=
.ac.uk/Personal/L.Wood/</A>&gt;&lt;[email-masked]&gt;<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Stephen Farrell<BR>
Sent: Fri 2009-08-07 4:17<BR>
To: Henning Rogge<BR>
Cc: [email-masked]<BR>
Subject: Re: [dtn-interest] Delay tolerant networking and absolute =
timing<BR>
<BR>
<BR>
Hi Henning,<BR>
<BR>
Thanks for re-starting the discussion! (BTW, I'll post minutes =
soonish<BR>
but am travelling this week.)<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CA171A.F4212FDD--

Date: Fri, 07 Aug 2009 04:17:08 +0100
From: Stephen Farrell <[email-masked]>
To: Henning Rogge <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Delay tolerant networking and absolute timing

Hi Henning,

Thanks for re-starting the discussion! (BTW, I'll post minutes soonish
but am travelling this week.)

>From my p-o-v there are two things I'd like to see:

- Add a capability to handle nodes with no (good enough) clock to
  the bundle protocol
- Do that while remaining interoperable with RFC 5050 and so that
  existing code needs as little change as possible (ideally none)

The first thing that occurs to me is that the node with no clock
can put in some kind of (hopefully) unique number in the timestamp
field and then add a (new, TBD) extension block that basically says
"the timestamp is rubbish, but please forward this anyway". It could
be that the first hop that does have a clock and supports the
new extension block should add yet another extension block
that says "saw this first at time t" so that subsequent nodes
could then expire the bundle if necessary.

However, I've not thought it out in detail, so there're probably
holes galore.

Cheers,
Stephen.

Henning Rogge wrote:
> Hello,
> 
> I have visited the workinggroup meeting in Stockholm and would like to start a 
> discussion about absolute timestamps in DTN (the last presentation mentioned 
> the possibility to adapt DTN to relative timestamps).
> 
> Absolute timing can be a real pain in large networks with autonomous nodes. 
> Many embedded devices lack a GPS receiver and manets/mesh networks cannot rely 
> on a central time source like GSM or UMTS networks. Setting the time to a 
> "roughly synchronized" value doesn't really scale well with network size. I 
> just try to imagine an emergency response team after a tsunami which has so 
> sync 500 nodes before they can start, especially if they are coming from 10 
> different countries distributed over a few days.
> 
> I think it would be a good idea to switch to relative timestamps where it is 
> possible. If some parts of the protocol cannot work without absolute timing, 
> each station could try to learn the time difference to all of it's neighbors 
> (without sync the clocks), so it can translate incoming absolute timings into 
> local time.
> 
> What do you think about this ?
> 
> Henning Rogge
> 
> *************************************************
> Diplom-Informatiker Henning Rogge
> Forschungsgesellschaft für
> Angewandte Naturwissenschaften e. V. (FGAN) 
> Neuenahrer Str. 20, 53343 Wachtberg, Germany
> Tel.: 0049 (0)228 9435-961
> Fax: 0049 (0)228 9435-685
> E-Mail: [email-masked]
> Web: www.fgan.de
> ************************************************
> Sitz der Gesellschaft: Bonn
> Registergericht: Amtsgericht Bonn VR 2530
> Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
> (Stellv.)
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 06 Aug 2009 16:28:54 +0100
From: Paulo Mendes <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: U-NET'09 (User-provided networking) workshop, co-located with ACM CoNext

(Apologies if you get this twice)

ACM U-NET'09 — User-provided Networking: Challenges and Opportunities
Co-located with ACM CoNEXT 2009
Rome, Italy, December 1st, 2009
http://conferences.sigcomm.org/co-next/2009/workshops/unet/

*NEW SUBMISSION DEADLINE*: August 13th, 2009 (U-NET web page to be 
updated soon)

Submit at: http://edas.info/N7753

*Motivation*

This workshop is dedicated to the debate of concepts, challenges, and 
opportunities concerning user-provided networking, i.e., scenarios where 
users cooperate by sharing wireless resources as well as Internet services.
To provide a specific example that relates to Internet access 
(connectivity), the end-user (or a community of end-users) is a 
micro-operator in the sense that he/she shares his/her subscribed 
broadband Internet access based on some form of incentive scheme. In 
addition, the end-user may or may not provide other network 
functionality such as local mobility management, or persistent storage 
and forwarding services. This new role is disruptive in what concerns 
Internet service models, since there is no distinction between what is 
today known as end-user device and network device: in the future, 
end-user devices will actively participate as part of the network. In 
contrast, the Internet has been up to now mostly the means for end-users 
to obtain some form of network service, originally related to 
connectivity, person-to-person communication, or information retrieval. 
Such user-centric provider role is also disruptive given that the 
regular network boundaries of trust have to be extended in a way that 
should mimic social behavior: there is the need to form networks of 
trust in order to accommodate a robust network growth, given that the 
key to such growth is the willingness to cooperate.

Another disruptive aspect of user-provided networking is that due to the 
nature of the wireless media and the way that humans move, support for 
intermittent connectivity as well as fast and transparent roaming 
between micro-operators needs to be considered. Finally, and given that 
user-provided networking spreads dynamically having as network elements 
regular end-user devices, there is the need to consider cases where 
information is opportunistically relayed instead of routed based on 
topological information.

Due to the disruptive aspects mentioned, user-provided networking seem 
to have the potential to provide a paradigm shift in Internet 
communication models, given that such novel functionality allow wireless 
networks to operate in a completely autonomic way and also given that 
the end-user becomes a provider of Internet services (e.g. connectivity) 
based upon cooperation incentives or rewards and based upon his/her own 
mobility and social patterns. Services are established on the fly, and 
do not necessarily imply the use of multihop technology or routing. For 
instance, connectivity may be, in most cases, simply relayed.

The workshop program will include presentations of peer-reviewed papers 
and a discussion panel with guests from industry and academia. We 
envision U-NET as a forum aiming to ignite a debate concerning technical 
challenges and impact (negatively or positively) that user-provided 
networking may have on Internet communication models.

*Topics*

U-NET'09 solicits high quality technical contributions within the 
context of user-provided networking. Topics of interest include but are 
not limited to:

* Challenges and opportunities for access providers.
* Impact on Internet architectures.
* Internet connectivity.
* Trust models, incentives to share broadband access.
* Human behaviour and mobility patterns.
* Self-organization.
* Wireless cooperation.

Papers submitted are expected to be highly innovative and may 
incorporate early stage ideas; position papers (clearly identified as 
such) pointing to new directions and capable of generating discussion 
are also welcome. Submission must be original and not already published 
in any other conference proceeding or journal. Proceedings of the 
workshop will be published in the ACM Digital Library.

*Technical Panel Discussion*

U-NET'09 aims to be a forum to debate the technical challenges and 
impact of deploying user-provided networking technology. For this 
propose, this first edition of U-NET will host a technical discussion 
panel constituted by:

* Shivendra S. Panwar, Professor at Polytechnic Institute of New York 
University, USA
* James Kempf, Senior Architect at Ericsson Research, USA
* David Kennedy, Director at Eurescom GmbH, Germany
* Jordi Vallejo, CTO at FON Wireless Ltd, Spain
* Dirk Trossen, Chief Researcher at BT Design and Innovation, United 
Kingdom

*Submissions*

Submitted papers must be at most 6 (six) pages long (including figures, 
tables and references) in the standard ACM double column format. All 
text must use font sizes of 10 points or larger. Longer submissions will 
not be reviewed. The review process is single-blind. Submissions will be 
done via EDAS at http://edas.info/N7753.

*Important Dates*

Submissions due: August 13th, 2009
Notification of acceptance: September 14th, 2009
Camera ready version due: October 1st, 2009
Workshop date: December 1st, 2009

*Program Committee*

PC Chairs

Paulo Mendes, INESC Porto, Portugal
Olivier Marcé, Alcatel-Lucent Bell Labs, France

Technical Program Committee

Rute Sofia, INESC Porto, Portugal
André Zúquete, University of Aveiro, Portugal
Vassilis Kostakos, University of Madeira, Portugal
Jon Crowcroft, University of Cambridge, United Kingdom
Cecilia Mascolo, University of Cambridge, United Kingdom
Eiko Yoneki, University of Cambridge, United Kingdom
Dirk Trossen, British Telecom Innovate, United Kingdom
Prosper Chemouli, France Telecom, France
Martin May, Thomson Paris Research Laboratory, France
Karen Sollins, MIT, USA
Lixia Zhang, UCLA, USA
James Kempf, Ericsson Research, USA
Dipankar Raychaudhuri, Rutgders University, USA
Bernhard Plattner, ETH, Switzerland
George Polyzos, Athens University of Economics and Business, Greece
Maria Papadopouli, FORTH/University of Creete, Greece
Anand Prasand, NEC, Japan
Gunnar Karlsson, KTH, Sweden
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Marcus Brunner, NEC, Germany
Petri Mähönen, RWTH Aachen University, Germany

-- 
-----------------------------------------------------
Paulo Mendes, Ph.D
Area Leader, Internet Architectures and Networking
Telecommunication and Multimedia Unit
INESC Porto
Tel. +351 22 209 4264
Fax. +351 22 209 4050
http://ian.inescporto.pt

From: Henning Rogge <[email-masked]>
To: [email-masked]
Date: Thu, 6 Aug 2009 16:07:14 +0200
Subject: [dtn-interest] Delay tolerant networking and absolute timing

--nextPart35705645.NUpv8pYFVV
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I have visited the workinggroup meeting in Stockholm and would like to star=
t a=20
discussion about absolute timestamps in DTN (the last presentation mentione=
d=20
the possibility to adapt DTN to relative timestamps).

Absolute timing can be a real pain in large networks with autonomous nodes.=
=20
Many embedded devices lack a GPS receiver and manets/mesh networks cannot r=
ely=20
on a central time source like GSM or UMTS networks. Setting the time to a=20
"roughly synchronized" value doesn't really scale well with network size. I=
=20
just try to imagine an emergency response team after a tsunami which has so=
=20
sync 500 nodes before they can start, especially if they are coming from 10=
=20
different countries distributed over a few days.

I think it would be a good idea to switch to relative timestamps where it i=
s=20
possible. If some parts of the protocol cannot work without absolute timing=
,=20
each station could try to learn the time difference to all of it's neighbor=
s=20
(without sync the clocks), so it can translate incoming absolute timings in=
to=20
local time.

What do you think about this ?

Henning Rogge

*************************************************
Diplom-Informatiker Henning Rogge
=46orschungsgesellschaft f=FCr
Angewandte Naturwissenschaften e. V. (FGAN)=20
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
=46ax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender=20
(Stellv.)

--nextPart35705645.NUpv8pYFVV
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart35705645.NUpv8pYFVV--

Date: Mon, 03 Aug 2009 13:39:15 -0700
From: Doug Otis <[email-masked]>
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] delay tolerant (time independent) network that also avoids duplication

The XAM (eXtensible Access Method) Interface specification defines an
XUID to reference information objects. XAM includes metadata definitions
to accompany the object data to achieve application interoperability,
and storage transparency.

The XUID format is as follows:

byte 0      reserved
byte 1-3    OID (vendor id)
byte 4      reserved
byte 5      length
byte 6-7    crc-16
byte 8-79   opaque data

http://www.snia.org/forums/xam/technology/specs/

In essence, the XUID can act as error check and unique identifier within
80 bytes or less.

An absolute or relative time flag could select a 32 bit UTC epoch time,
or time-in-transit in conjunction with the XUID.  Expiry could be
expressed in the same manner.  The transmitter could drop all traffic
beyond expiry.

When used in OLPC (one laptop per child) type of environments, duplicate
items can automatically be detected.  There might be an advantage in
having transmitters advertise the available objects to different groups
and then depend upon receipt of a request.

The XUID could thereby serve as both a type of security token and error
check when combined with some group parameter.

-Doug

Date: Sun, 02 Aug 2009 17:46:12 +0200
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] Call for Submissions: ICNP 2009 PhD Forum

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly note that the ICNP'09 call for submissions to PhD forum as 
well as posters and demos are all due on August 7, 2009.

Best regards,
Xiaoming Fu (ICNP'09 Publicity Chair)

IEEE ICNP 2009 PhD Forum
========================
http://edas.info/W.php?page=113

The ICNP'09 PhD Forum provides an environment for doctoral students to 
present and discuss their dissertation research both with their peers 
and experienced researchers from academia and industry. In addition to 
providing feedback and advice, this forum shall provide an opportunity 
for students to network as well as to practice presenting their research 
clearly and concisely.

This forum is best suited to senior Ph.D. students who have developed a 
mature research dissertation topic and framework and are far enough into 
their PhD to have a concrete presentation outlining the key challenges 
they plan to solve as well as the strategies and methods that are 
applicable.

This forum is broadly for students graduating in the next several months 
to about a year. Certainly feedback will help them fine-tune their 
thesis. Graduate students also get a chance to get feedback that they 
can use to write their papers, and address additional items in their 
research.

Format
======
Each participant will have 15 minutes allotted for a presentation. We 
will limit the number of participants to no more than 5 presenters.

Submission
==========
    1. A summary of the student's dissertation research (up to 3 pages) 
including a brief discussion of motivation, challenges, related work and 
initial results. Applicants should clearly identify their contributions 
to the field of networking protocols design and analysis.
    2. A short biographical sketch (1 page max) describing the 
applicants affiliations and research activities. This should include the 
date that the student expects to complete his/her dissertation.

Please use the IEEE conference proceedings style (2-column) when 
preparing your abstract. If accepted, a student may be asked to provide 
explanations or clarification by the camera-ready deadline.

Important dates
===============
Submission deadline             August 7, 2009, (Fri 23:59 PDT)
Notification of decisions     August 28, 2009
Final version of abstracts     September 4, 2009

Where to submit?
================
By email to: [email-masked]
Use Subject Line: ICNP 2009 PhD forum submission

Registration
============
Students may register for the conference at the student rate for 
participation in PhD forum (if they are not presenting a full paper in 
the conference which requires a full registration).